FarNet - .NET Far API and .NET plugin manager (English)

Here you can discuss about your favorite plug-in.
User avatar
NightRoman
Posts: 6184
Joined: Fri 18 Aug, 2006 13:52
Location: Cambridge, UK
Has thanked: 32 times
Been thanked: 62 times
Contact:

FarNet - .NET Far API and .NET plugin manager (English)

Post by NightRoman »

Latest post of the previous page:

> I will try 4162 tomorrow, very doubt it will fix the twice Invoke() issue.
It will not fix the issue. But using the latest is the rule here on bug reports.

> So Far.Api.Message() somehow changes the focus and this causes double Invoke()? Or even without Far.Api.Message() one will get twice Invoke()?
Not exactly... I provided the brief explanation. If it is not clear then just ignore it. There is no reason to explain all the details unless you are really interested.

The fix will be provided. But it is not straightforward, please be patient.
elize
Posts: 6
Joined: Tue 28 Oct, 2014 19:21

FarNet - .NET Far API and .NET plugin manager (English)

Post by elize »

I checked today with 4162 x64 see image below, the double Invoke() issue is still there.
Thanks a lot for your answers and great library, will wait for the fix.
TwoMessageBoxes_4162.PNG
TwoMessageBoxes_4162.PNG (28.54 KiB) Viewed 17081 times
User avatar
NightRoman
Posts: 6184
Joined: Fri 18 Aug, 2006 13:52
Location: Cambridge, UK
Has thanked: 32 times
Been thanked: 62 times
Contact:

FarNet - .NET Far API and .NET plugin manager (English)

Post by NightRoman »

Try FarNet 5.0.60. It is a "quick fix" but it should solve the described problem.
elize
Posts: 6
Joined: Tue 28 Oct, 2014 19:21

FarNet - .NET Far API and .NET plugin manager (English)

Post by elize »

Thanks a lot for the quick fix, indeed it solves the problem. Works just fine with 4162 x64.

Two other low priority issues:
1) Ctrl+F10 = "Go to File" is not working in FarNet based editors (it used to work in previous versions of FarNet, like 5.0.32).
2) The new behavior (when the method called) of Editor.Invoke() is little bit different compare how it was in older versions of Far\FarNet.
New: User sees the content of unconverted file and on top of it Far.Api.Message()
Before like with v5.0.32 the prompt was on top of panels (not editor).

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

FarNet - .NET Far API and .NET plugin manager (English)

Post by NightRoman »

Thanks a lot for the quick fix, indeed it solves the problem. Works just fine with 4162 x64.
You are very welcome. It was actually a nasty bug, thanks for reporting.
1) Ctrl+F10 = "Go to File" is not working in FarNet based editors
Ctrl+F10 is the feature of Far. If it is not working you may try to discuss it
in another thread. If it is a bug then it may be fixed (does not depend on me).
Your scenario can be described as the following steps:

- On [F4] a plugin on the first event EE_GOTFOCUS opens a message box.
- On closing the dialog the plugin closes the editor and opens another file in the editor.
- [CtrlF10] does not work as expected in this new editor, i.e. does not go to this file in panels.
2) The new behavior (when the method called) of Editor.Invoke() is little bit different
That is how Far works now and how FarNet is adapted for this. EE_REDRAW now is
the very first event. It used to be different in earlier Far versions, EE_READ was the
first event and your scenario worked differently (say, better for some cases, maybe
worse in others, imagine, it is exactly needed that a dialog is shown in the already
visible editor). This is Far design, its developers know why it is done this way.

See some details (Russian) -- http://forum.farmanager.com/viewtopic.php?f=54&t=8779
In particular, in it is by design that in EE_READ the editor is already shown.
(Why? I do not know.)

I recommend you to change your approach because its design is somewhat dangerous.
In fact you close an editor from an event handler. There may be other plugins that
should process this event for this editor, too. But you close it. The result
depends on how Far or plugins are implemented to handle this, even if they
handle this fine now this may change later.

I will explain how you can solve your problems and implement a safer way a bit
later, now I have to go. This way is not more difficult than the current.
User avatar
NightRoman
Posts: 6184
Joined: Fri 18 Aug, 2006 13:52
Location: Cambridge, UK
Has thanked: 32 times
Been thanked: 62 times
Contact:

FarNet - .NET Far API and .NET plugin manager (English)

Post by NightRoman »

elize

Instead of ModuleEditor you can implement ModuleCommand in order to open Base64 files either directly from the Far command line via prefix (e.g. "base64:") or indirectly from Far file associations. (Actually transform your ModuleEditor to ModuleCommand with some relevant changes).

Example ModuleCommand
https://code.google.com/p/farnet/source ... Command.cs

What Invoke() in your derived ModuleCommand should do:
- get the current file path from the current panel (see DoResources() in the above example)
- show your usual dialog for this file
- depending on the answer cancel or open the original file in the editor or convert the file and open the converted instead

Now you can just make the file current and type "base64:" (nothing else is needed in the command but you also can add some arguments and logic if needed) and the command gets called.

Or you still can use [F4] in order to trigger your code for Base64 files. In F9 \ Commands \ File associations create an entry for your files, specify their mask, e.g. *.Base64* and on [F4] action enter the following command:
base64:

Save Far settings ([ShiftF9]) if they are not saved automatically in your Far. After that on [F4] on *.Base64* files your ModuleCommand is called.

This approach should solve your current problems and potential future (I think it is not safe to close an editor from its event). It is also somewhat more flexible. E.g. you can call base64: any time from the command line for Base64 file with any name, not necessarily matching the defined mask. Or you can use some other keys for this operation in file association, [Enter] (or some others) and keep [F4] for opening in the editor as usual.
elize
Posts: 6
Joined: Tue 28 Oct, 2014 19:21

FarNet - .NET Far API and .NET plugin manager (English)

Post by elize »

Actually I already have ModuleCommand in my plugin, for other purpose.
Did not thought (i guess just missed it) about File Association and my existing (or new prefix, as you wrote base64:)
Great idea, definitely much better and more flexible! Will try to switch to this mode in my next release of plugin.
My only question now how can I implement this new file associations with my plugin deployment story.
Basically automate the process: F9\Commands\File Assoc.\.base64\... Shift+F9
Currently my setup story is XCOPY - basically batch file (.cmd) which detects where Far is, elevates if needed, robocopy /MIR, etc.
Currently what comes to my mind is LUA macro, is there any better way to do it?
User avatar
NightRoman
Posts: 6184
Joined: Fri 18 Aug, 2006 13:52
Location: Cambridge, UK
Has thanked: 32 times
Been thanked: 62 times
Contact:

FarNet - .NET Far API and .NET plugin manager (English)

Post by NightRoman »

I knew this question was coming. For the very first deployment there is a good option.

-- Add your file association locally then do:

Code: Select all

Far.exe /export my.farconfig
-- In my.farconfig find relevant data and copy to a separate file deploy.farconfig. Something like this (assoc to [Enter]):

Code: Select all

<?xml version="1.0" encoding="UTF-8" ?>
<farconfig version="3.0.4165">
    <associations>
        <filetype mask="*.Base64*" description="Convert and edit Base64 files">
            <command type="0" enabled="1" command="base64:" />
            <command type="1" enabled="1" command="" />
            <command type="2" enabled="1" command="" />
            <command type="3" enabled="1" command="" />
            <command type="4" enabled="1" command="" />
            <command type="5" enabled="1" command="" />
        </filetype>
    </associations>
</farconfig>
-- In your deployment batch script call

Code: Select all

Far.exe /import ...\deploy.farconfig
As a result, the file association gets imported and ready to use. You can deploy other predefined settings in this way, too.

Unfortunately, this is not suitable for updates (if this is needed) because on importing associations override existing completely, unlike some other settings which are merged. Thus, associations added by a user later can be lost. I'll ask if this limitation can be solved gracefully -- http://forum.farmanager.com/viewtopic.php?f=4&t=9121
elize
Posts: 6
Joined: Tue 28 Oct, 2014 19:21

FarNet - .NET Far API and .NET plugin manager (English)

Post by elize »

Thanks, will update my deployment script accordingly.
Post Reply

Return to “General Plug-In Discussions”