Fingers in the nose guide to build javascript plugins. Does that mean its easy ?

[ewemoa]

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:

[Select]

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.

[mouser]

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.

[ewemoa]

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

[ecaradec]

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

[mouser]

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.

[ewemoa]

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?

[mouser]

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..

[ewemoa]

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

[phitsc]

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.

[mouser]

phitsc mail me the plugin and alias and i'll find whats wrong.

[ewemoa]

FarrOpenWith sounds interesting

May I see the implementation?

[phitsc]

FarrOpenWith sounds interesting

May I see the implementation?

-ewemoa (November 11, 2008, 02:57 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).

I'll zip up the FarrOpenWith source code and upload it for you sometime today.

[ewemoa]

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).

-phitsc (November 12, 2008, 02:59 AM)

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!

[phitsc]

I agree. Gui stuff always takes a lot of time, even if it's straight forward.