|
ewemoa
|
 |
« Reply #25 on: November 08, 2008, 09:57:07 PM » |
|
Hmm...no other responses...May be it's not a good idea to keep posting further questions in this thread. Well, I will give it another try anyway. I'm trying to use onProcessTrigger() to handle launching of things via a plugin, but for some items it didn't create [1] -- is it correct that this is currently a futile endeavor? The following FScript source snippet gives me the sense that that might be the case: [ copy or print] PREFUNCDEF BOOL EFuncName_Allow_ProcessTrigger(const char* destbuf_path, const char* destbuf_caption, const char* destbuf_groupname, int pluginid,int thispluginid, int score, E_EntryTypeT entrytype, void* tagvoidp, BOOL *closeafterp) { // does this plugin want to take over launching of this result? if (thispluginid!=pluginid) { // if we didnt create it, let default handler do it return FALSE; } I don't think I have an environment to make this change myself -- any chances of takers or perhaps producing a version of FScript that will compile under Code::Blocks?  [1] I'm investigating the idea of implementing FARR-specific file associations. |
|
|
|
|
Logged
|
|
|
|
|
mouser
|
|
« Reply #26 on: November 09, 2008, 03:12:11 AM » |
|
im not sure i understand your question about onprocesstrigger..
it's fine for a plugin (that has a reason to) to handle the launching of items it didn't create.
|
|
|
|
|
Logged
|
|
|
|
|
ewemoa
|
|
« Reply #27 on: November 09, 2008, 03:46:17 AM » |
|
Well, I thought so too, but AFAICT, onProcessTrigger() doesn't appear to get called for a test plugin of mine -- I placed statements to produce debugging output (as well as invoke the debugger) in onProcessTrigger(), but neither seemed to have any effect. So I started wondering if it was being called at all...I looked at the GooglePlus plugin as it seems to make use of onProcessTrigger(), but I didn't manage to figure out whether it's doing something that my plugin isn't. I looked in the FScript source and found something [1] that looked to me like FScript decides that if your plugin hasn't created an item, it doesn't get to handle it -- the quoted code in my previous post was what I came across. I don't know if I'm interpreting what I'm seeing correctly though [1] The code is from FScript's JrPlugin_MyPlugin.cpp |
|
|
|
|
Logged
|
|
|
|
|
|
ecaradec
|
|
« Reply #28 on: November 09, 2008, 06:28:24 AM » |
|
Yes, you are right, I made some choices when I wrote the FScript plugin. It does not handle all possibilities of the farr plugin api. At the time I didn't see a lot of use for plugins to handle outputs of others plugins.
What were the uses you think about this fonctionnality mouser ?
Writing this I think it could be possible to use this with modal plugins. Ex a zip plugins could work that way :
* type : zip -> switch the plugin in a kind of select file mode and clear the input
* select a file : any file selected after this with enter would be added to the queue. (use of the onProcessTrigger )
* type : to filename -> zip all the files in the queue into the filename given
|
|
|
|
|
Logged
|
|
|
|
|
mouser
|
|
« Reply #29 on: November 09, 2008, 06:59:05 AM » |
|
What were the uses you think about this fonctionnality mouser ? some plugins would be creating entries that aren't real files, and so they would hande their own launches to decide what to do when user clicks. But as for handling a result that the plugin did not itself create, it would be useful for a plugin that worked like a modifier and didn't create results of its own. For example, imagine a plugin that was designed to run a program under a different users permissions (like admin), so you type your search and then type +runas:admin then when you hit enter to launch a program, that plugin would see the +runas: modifier and take over the launching. |
|
|
|
|
Logged
|
|
|
|
|
ewemoa
|
|
« Reply #30 on: November 09, 2008, 08:23:59 AM » |
|
What I'm experimenting with is the idea of having file associations which are specific to FARR -- I've been trying out a "portable" set up -- so many of my applications don't establish file associations (writing to the registry is a no-no). However, it's a pain not being able to double-click on files and have them launch w/ reasonable applications -- but I thought may be I could encourage myself to open files using FARR almost all of the time if I could make a plugin which could manage "pseudo" file associations and take over opening the files by applying those associations appropriately.
Am I making sense?
|
|
|
|
« Last Edit: November 09, 2008, 08:25:34 AM by ewemoa »
|
Logged
|
|
|
|
|
mouser
|
|
« Reply #31 on: November 09, 2008, 08:40:46 AM » |
|
but I thought may be I could encourage myself to open files using FARR almost all of the time if I could make a plugin which could manage "pseudo" file associations and take over opening the files by applying those associations appropriately. thats kind of a cool idea.. |
|
|
|
|
Logged
|
|
|
|
|
ewemoa
|
|
« Reply #32 on: November 09, 2008, 08:48:31 AM » |
|
May be it can be more easily done as a non-FScript plugin...hmm, who can we convince? taichimaster? Bonus points for reading and working with the file associations maintained by apps like XYplorer |
|
|
|
|
Logged
|
|
|
|
|
phitsc
|
|
« Reply #33 on: November 10, 2008, 03:03:32 AM » |
|
I've made a plugin (FarrOpenWith) that handles all onProcessTrigger events to open a result item (a file) with an application other than the default. I needed this because I wanted to open .xml files in a text editor instead of in a web browser (which is the default on my system).
The way I used it was that I had an alias as follows:
dosearch D:\MyProject\ConfigFiles\$$1*.xml +OPENWITH=%PROGRAM_FILES%\Notepad++\Notepad++.exe
Note the +OPENWITH=. The plugin looks for this on onSearchBegins and if it finds it it takes over launching by handling onProcessTrigger. I'm using the native plugin interface though.
I can remember that this once worked, it's not any more now though. The problem is that $$1*.xml doesn't seem to work any more.
|
|
|
|
|
Logged
|
|
|
|
|
mouser
|
|
« Reply #34 on: November 10, 2008, 06:54:42 AM » |
|
phitsc mail me the plugin and alias and i'll find whats wrong.
|
|
|
|
|
Logged
|
|
|
|
|
ewemoa
|
|
« Reply #35 on: November 11, 2008, 02:57:14 AM » |
|
FarrOpenWith sounds interesting May I see the implementation?  |
|
|
|
|
Logged
|
|
|
|
|
phitsc
|
|
« Reply #36 on: November 12, 2008, 02:59:24 AM » |
|
FarrOpenWith sounds interesting May I see the implementation? I would expect that what you want to do is even simpler than what OpenWith currently does. I would think you'd just have to implement onProcessTrigger, check the file extension of the file being triggered and select the appropriate application to launch the file (if I understood correctly what you want to do). I'll zip up the FarrOpenWith source code and upload it for you sometime today. |
|
|
|
|
Logged
|
|
|
|
|
ewemoa
|
|
« Reply #37 on: November 12, 2008, 05:48:47 AM » |
|
I would expect that what you want to do is even simpler than what OpenWith currently does. I would think you'd just have to implement onProcessTrigger, check the file extension of the file being triggered and select the appropriate application to launch the file (if I understood correctly what you want to do).
Yes, that's pretty much it -- I believe some "harder" parts of this are: building a UI to manage the extensions and coming with an icon I'll zip up the FarrOpenWith source code and upload it for you sometime today.
Thanks! |
|
|
|
|
Logged
|
|
|
|
|
phitsc
|
|
« Reply #38 on: November 12, 2008, 11:32:34 AM » |
|
I agree. Gui stuff always takes a lot of time, even if it's straight forward.
|
|
|
|
|
Logged
|
|
|
|
|
