NppMenuSearch version 0.9.7 available

peter-frentrup

@Vitalii-Dovgan Thanks for reporting. I implemented a quick fix (using the already existing event ToolbarSearchForm.AfterCompleteInit) and updated the release binaries.
I did not change the version number, because I think that the issue can only occur if one bypasses the windows event loop and calls the internal function Main.MenuSearchFunction() directly instead of via the registered command.

Vitalii Dovgan

@peter-frentrup
Thank you, now it works via the loader.
Though, the C++ loader adds a strange new “feature” now: when the “Menu Search” function is called for the very first time, at first, when the “NppMenuSearch.dll” is loaded by the C++ loader, the search text box gets the focus as expected. However, then, when the MenuSearchFunction is actually called for the first time, the focus unexpectedly returns back to Scintilla. As far as I understand, this is somehow connected to the fact that SelectSearchField exits at that moment, posponing the execution of afterCompleteInit_SelectSearchField. Then, when the latter is being executed, I do see that

txtSearch.SelectAll();
txtSearch.Focus();
txtSearch_TextChanged(null, null);

are called, however the focus does not return to the search text box.
Sorry for bothering you with these details related to the C++ loader, I just thought maybe you could give me a hint what to do here?

peter-frentrup

@Vitalii-Dovgan In Main.PluginReady(), I explicitly send SCI_GRABFOCUS to explicitly set focus to the current Scintilla editor for some reason (probably the toolbar was otherwise stealing focus… I am not sure about the exact circumstances, that code is old):

internal static void PluginReady()
{
  ...
  ToolbarSearchForm.CheckToolbarVisiblity();
  Win32.SendMessage(PluginBase.GetCurrentScintilla(), SciMsg.SCI_GRABFOCUS, 0, 0);
  ...
}

Maybe this interferes with your code?

Vitalii Dovgan

@peter-frentrup

Hmm, looks close, but does not seem to be.
If I comment out the line with the SciMsg.SCI_GRABFOCUS, nothing changes.
So far, whatever I tried, the focus is stolen to Scintilla. I stopped to trust myself, so I reverted the “NppMenuSearch.dll” to its previous version 0.9.6. With the 0.9.6, the focus remains in the search text box.

Here is the C++ wrapper available in Git in case you or someone else would like to play with it:
https://github.com/d0vgan/npp-plugins-CppWrappers/tree/master/NppMenuSearchCpp

astewart77

@peter-frentrup Is it possible to show all Recently Used items, not just ones matching a search string? For those days when I forgot what I just did…

peter-frentrup

@astewart77 No, that is not possible with the plugin.

@Vitalii-Dovgan Another possiblity is the dummy dialog procedure I use when loading each page:

public static class DialogHelper {
...
public static IntPtr LoadNppDialog(IntPtr hwndParent, int dialogResoucreId)
{
    ...
    return CreateDialogParam(exeModule, (IntPtr)dialogResoucreId, hwndParent, DialogProcedureDelegate, IntPtr.Zero);
}

static IntPtr DialogProcedure(IntPtr hwndDlg, uint uMsg, IntPtr wParam, IntPtr lParam)
{
    switch (uMsg)
    {
        case (uint)Win32.WM_INITDIALOG:
            return (IntPtr)1;

        default:
            return IntPtr.Zero;
    }
}
...
}

Returning 1 for WM_INITDIALOG actually means direct the system to set the keyboard focus to the first possible control. Maybe 0 would be better here.

Vitalii Dovgan

@peter-frentrup said in NppMenuSearch version 0.9.7 available:

DialogProcedure

You are right!!! The usage of return IntPtr.Zero for WM_INITDIALOG did the trick!

Vitalii Dovgan

Here is a strange-looking double-lined item in the list, this is while searching for “delim”:

Here is the corresponding item in Preferences - Delimiter:

I think, we may just truncate such items to their first line.

Vitalii Dovgan

By the way, what is the reasoning behind clearing the Search text when Enter is pressed and not clearing it when Esc is pressed?
Since the Search text becomes fully selected when the “Menu Search” function is called, I’d rather expect to have the Search text preserved after Enter is pressed. Who knows, maybe I’ll want to do the very same search again?

peter-frentrup

@Vitalii-Dovgan It annoys me like hell when the search term lingers around after I found what I want. I find it “cleaner” to return to the default state that reminds me of the shortcut.
Regarding the ESC behaviour: maybe I should clear the field in that case too 🤔

About the visual glitch: I will slam everything into a single line.

So the dialog procedure could simplify 👍

There was also a problem when one attempts to navigate to a hidden preference item that has the same ID as some other control on a different page. E.g. the second line “bla bla ba bla …” on the “Delimiter” page. It seems that another update is due 🙄

Vitalii Dovgan

Here is a funny scenario:

type “menu” in the Search textbox;
select Plugins -> NppMenuSearch -> Menu Search…
press Enter.
As the result, the Search textbox does not have a focus!

Well, I know this is a strange use-case: call itself, but anyway :)