NppMenuSearch version 0.9.7 available

peter-frentrup

I just released version 0.9.7 of my NppMenuSearch plugin. As always, binaries are available on SourceForge.
This version fixes some bugs and implements a few new features:

NEW: changed default shortcut to Ctrl+F1, because Notepad++ uses Ctrl+M for “Mark”
NEW: search for open files (thanks to Alireza Delavari)
NEW: translations of the user interface to Italian (thanks to Matteo Concato) and German
NEW: Ctrl+Backspace in the search field deletes the previous word (thanks to Vitaliy Dovgan)
NEW: dark mode support
NEW: allow to lock search widget size via new ⁞ button on the right
FIX: recognize “Indentation” page of the preferences dialog (thanks to Vitaliy Dovgan)
FIX: faster startup
FIX: several stability issues

Peter

Vitalii Dovgan

@peter-frentrup
I’ve seemed to find a potential issue in this new version.
Here is some background: I have a C++ loader named “NppMenuSearchCpp.dll” that does lazy-calls to the actual “NppMenuSearch.dll”. This C++ loader just saves time before the very first call to any function of “NppMenuSearch.dll” is made: at the moment of the very first call, it loads the C# “NppMenuSearch.dll” and then invokes a function within that .dll.
Everything has been working until the official release of NppMenuSearch 0.9.7.
With 0.9.7, here is what I am getting:

public partial class ToolbarSearchForm : Form
    public void SelectSearchField()
    {
        if (ResultsPopup.Visible)  // <-- ResultsPopup is null here, leading to Access Violation
        ...
    }

I believe this is the direct consequence of the following:

public partial class ToolbarSearchForm : Form
    private void ToolbarSearchForm_HandleCreated(object sender, EventArgs e)
    {
        HandleCreated -= ToolbarSearchForm_HandleCreated;
        BeginInvoke((Action)DoDelayedInit);
    }

    private void DoDelayedInit()
    {
        ResultsPopup = new ResultsPopup();
        ...
    }

In case of my C++ loader, the delayed method does not seem to have enough to be executed before ToolbarSearchForm.SelectSearchField() is called by MenuSearchFunction().
And even though this does not seem to be reproduced when “NppMenuSearch.dll” is loaded by itself (without my C++ loader), I believe you anyway need to introduce some event object that will be signaled when DoDelayedInit has been finished - and SelectSearchField should wait for this event object to be absolutely sure that all the initialization has been finished in advance.

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 🙄