Interaction between a plugin and its editor

A place where plug-in developers can share their knowledge and experience.
Post Reply
pepak
Posts: 604
Joined: Sun 13 Jul, 2008 11:18
Has thanked: 17 times
Been thanked: 54 times

Interaction between a plugin and its editor

Post by pepak »

I am looking for the "do's and dont's" of interacting between a plugin and its associated editor: Imagine a plugin which creates a temporary file with some content, opens an editor for this file, lets user do what he likes with the editor, and when the editor is closed, performs some actions on what was left in the temporary file (e.g. the frename.dll plugin for FAR1). I would like to provide some functionality for that editor window (e.g. "F8 -> add '.bak' to the target filename"). I am looking for suggestions on how best implement this:

a) Don't do anything at all, a user who wants a functionality can write a macro for it. This is obviously the easiest for me, but lacks functionality that I would like - e.g. the ability to only provide that functionality for my plugin's editors, not other editors where the functionality wouldn't be relevant, ability to react to the current state of the plugin, or the ability to display proper keyboard shortcuts in FAR's keybar.

b) Provide various functions that can be called from a macro (via OpenW's OPEN_FROMMACRO and OPEN_LUAMACRO). It seems to me this pretty much shares the disadvantages of a), with the extra disadvantage that only those able to write programs in FAR's macrolanguage would be able to make use of this ability of my plugin.

c) Allow the plugin to be opened from the editor (via OpenW's OPEN_EDITOR), providing various menu options to cover the available functionality. It would check whether the current editor "belongs" to the plugin and if so, perform an action (e.g. it would show a manu item "Add '.bak' to the target filename"). This would be easy to use for most users, they would simply record a macro (CTRL+.) which would press F11, my plugin's shortcut, the desider action's shortcut. The keybar could be modified by using EditorControl with ECTL_SETKEYBAR, if I understand the Encyclopedia correctly. But I don't see how I could prevent the menu from showing in any editor other than mine.

d) Intercept ProcessEditorInputW and react according to the plugin's/editor's state. This would be even easier to use than c), and I could react to a key only in my editors. But it would seem to slow down editors which don't belong to my plugin, even if just a little (as much as it takes to look up the editor's ID in the list of my plugin's opened editors).

e) Something else?

At the moment, I am inclined to use either c) or d), or possibly both. But perhaps I am overlooking some preferred possibility or some significant drawback. I would appreciate input from FAR and/or plugin developers regarding this issue.

Thanks.
User avatar
NightRoman
Posts: 6184
Joined: Fri 18 Aug, 2006 13:52
Location: Cambridge, UK
Has thanked: 32 times
Been thanked: 62 times
Contact:

Re: Interaction between a plugin and its editor

Post by NightRoman »

c) ... But I don't see how I could prevent the menu from showing in any editor other than mine.
In GetPluginInfoW can you check the current editor? If it does not "belong" to the plugin then do not return info about the menu. Otherwise return info about the menu. Will this work?
pepak
Posts: 604
Joined: Sun 13 Jul, 2008 11:18
Has thanked: 17 times
Been thanked: 54 times

Re: Interaction between a plugin and its editor

Post by pepak »

As I understand GetPluginInfoW, it gets called once and that's it. The plugin has to decide whether it can be called from an editor (any editor) at that time. (Though apparently I don't understand everything about GetPluginInfoW, because I don't see how to get a different menu when called from Shell and a different menu when called from Editor, as RESearch does.)
User avatar
NightRoman
Posts: 6184
Joined: Fri 18 Aug, 2006 13:52
Location: Cambridge, UK
Has thanked: 32 times
Been thanked: 62 times
Contact:

Re: Interaction between a plugin and its editor

Post by NightRoman »

As I understand GetPluginInfoW, it gets called once and that's it.
No, it is called every time when a menu is needed.

Take a look at my AsGetPluginInfo (wrapper of GetPluginInfoW) here:
https://code.google.com/p/farnet/source ... n/Far0.cpp

It's C++/CLI and it contains some external method calls but it should give you an idea. It's from the plugin FarNet. Its menu depends on the current area and it is dynamic, i.e. also depends on (several) FarNet module menus.
User avatar
John Doe
Бюрократ
Posts: 13807
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 73 times
Been thanked: 426 times
Contact:

Re: Interaction between a plugin and its editor

Post by John Doe »

pepak wrote:a)...
b)...
User do not have to write macros, you can write it yourself.
There are 2 ways:
1) Put ready to use macrofile with your plugin
2) Make temporary macros in runtime (MCTL_ADDMACRO)
pepak wrote:The ability to only provide that functionality for my plugin's editors, not other editors where the functionality wouldn't be relevant, ability to react to the current state of the plugin
It is all possible with Plugin.Call and other macro functions.
pepak
Posts: 604
Joined: Sun 13 Jul, 2008 11:18
Has thanked: 17 times
Been thanked: 54 times

Re: Interaction between a plugin and its editor

Post by pepak »

NightRoman wrote:
As I understand GetPluginInfoW, it gets called once and that's it.
No, it is called every time when a menu is needed.
Take a look at my AsGetPluginInfo (wrapper of GetPluginInfoW) here:
https://code.google.com/p/farnet/source ... n/Far0.cpp[/quote]
Very nice. Thanks!!
pepak
Posts: 604
Joined: Sun 13 Jul, 2008 11:18
Has thanked: 17 times
Been thanked: 54 times

Re: Interaction between a plugin and its editor

Post by pepak »

John Doe wrote:User do not have to write macros, you can write it yourself.
There are 2 ways:
1) Put ready to use macrofile with your plugin
2) Make temporary macros in runtime (MCTL_ADDMACRO)
My concern is mostly whether the macro approach is preferred to the plugin approach, or the other way around.
pepak wrote:The ability to only provide that functionality for my plugin's editors, not other editors where the functionality wouldn't be relevant, ability to react to the current state of the plugin
It is all possible with Plugin.Call and other macro functions.
That's way over my head, me having no experience with macro scripts at all, but I will keep it in mind.
Post Reply

Return to “Plug-In Developers”