Focus is on the menu (and not text area) after NP++ activation

fml2

Hello,

I have a small but nasty problem which I hope you could help me with.

I extensively use the program Far Manager. It is an “orthodox file manager”. In Far, it’s possible to mark a file and then to press Alt+F4 to open it in an editor. The editor to use can be configured, and for me it’s Notepad++ (that’s why I’m here).

Usually, after I press Alt+F4 in Far, NP++ window is activated and I can immediately edit the file. But sometimes, after activation of the NP++ window, the focus in NP++ is not in the editing area, but in the menu. So I first have to press Esc and can only then edit the text.

The nasty about that is that this happens very sporadically. I made some experiments and still have not been able to find out how exactly I can reproduce this. It seems to depend on when I release the Alt button.

When I hold Alt depressed for a long time (e.g. five seconds) and release it long after NP++ has been activated, the problem does not occur. When I release it almost immediately, it does not occur. It seems that it must be the right number of tenths of a second to have it.

Does anybody have a hint how I can reliably have the focus in the editing area?

There was another issue reported that was also about the focus after activation, but it has been long fixed.
My problem occurs with the latest NP++ version but also happened with earlier versions.

Thank you for any hints!

Alan Kilborn

@fml2 said:

When I hold Alt depressed for a long time (e.g. five seconds) and release it long after NP++ has been activated, the problem does not occur. When I release it almost immediately, it does not occur. It seems that it must be the right number of tenths of a second to have it.

I think this is the key point. An Alt press/release in Notepad++ will activate the main menu and underline key letters in each of the top-level items, e.g. the “F” in “File”, etc. Once this is activated, it is “sticky” and requires the Esc press that you mentioned to get out of it. It does seem odd that if you hold Alt for a long time that the issue you are seeing doesn’t manifest, though.

Suggest maybe trying a different key assignment, not involving Alt, if you can do it in “Far”.

If it turns out this behavior of Alt is really the menu-invoking thing I’m talking about, I have a PythonScript I post that can avoid that behavior. EDIT: It’s actually part of the script I posted HERE.

mkupper

@fml2 said in Focus is on the menu (and not text area) after NP++ activation:

Does anybody have a hint how I can reliably have the focus in the editing area?

Does Far Manager allow you to configure the keyboard codes for its functions? For example, can you change the Alt+F4 keyboard combination used to launch a selected file to something like F11 or F12 without the Alt key being held down?

If you are stuck with using Alt+F4 then an idea is to insert a delay before starting Notepad++. For example:

timeout /t 1 && start "Notepad++" "c:\Program Files\Notepad++\Notepad++.exe"

I think that will cause a command prompt box to pop up. If that’s the case and it’s bothersome, but it fixed ths issue, then we can work out a better fix.

fml2

@mkupper said in Focus is on the menu (and not text area) after NP++ activation:

can you change the Alt+F4 keyboard combination used to launch a selected file to something like F11 or F12 without the Alt key being held down?

Yes, Far is very customizable. I’ve changed the key to F4 for now. It’s a challenge for my muscle memory :-), but it works.

Alan Kilborn

I didn’t say this in my earlier post, but…

So the root of @fml2 's problem is that having the Alt key down while running a program is actually a signal to the new program to do something special, often something visual.

Because a keycombo involving Alt is used in “Far Manager” (nice looks to that program BTW, had me longing for my DOS/TurboVision days…) to invoke Notepad++, the typical way to do this is to press and hold Alt while tapping and releasing the other key of the combo, and then finally releasing Alt. If you don’t “get off of” the Alt key soon enough, the program that is getting executed will see that as input for it.

I’ve actually encountered this issue in my own script writing. I have a script that allows me to click special “links”, much like url handling in Notepad++ itself, but links which open my file-manager of choice (XYplorer – the Notepad++ of file managers IMO) in a specific folder (the one specified in the “link”). For one reason or another, I decided to bind this functionality to Alt+click. This is a long-story-getting-longer, but I found that I (too) was lingering on Alt too long and XYplorer would see the Alt and do something special that was undesirable. What I ended up doing was adding more script code to wait until the user “gets off” Alt before even invoking Xyplorer.

fml2

The behaviour of the Alt key is weird and varies in different applications. I did the following experiments.

Basic setup: Have some programs open so that they are displayed in the task bar

Go to an application, i.e. have it as the “active” one
Press the Alt key
Point with the mouse to another application in the task bar and click. The application becomes the active one.
Release the Alt key

What I see is:

If the target app is Mozilla Firefox or Thunderbird or VLC, the menu is reliably activated upon releasing Alt.
If the target app is MS Excel, menu is never activated. Excel activates the menu (displays shortcuts) a second after pressing Alt, i.e. not upon releasing it.
If the target app is NP++ or LibreOffice the behaviour after releasing Alt is unpredictable. Sometimes the menu is activated, sometimes it’s not.

As I wrote, I remedy the situation by changing the key to one without Alt.