Compare plugin started from CMD: comparison won't start automatically since N++ 7.6.6

Ekopalypse

Thank you for fixing the missing part, very much appreciated.
One question, how do you know or why do you assume that it is a french UI?

dinkumoil

@Ekopalypse said:

One question, how do you know or why do you assume that it is a french UI?

I jumped over to the issue in Npp’s issue tracker @Joey79100 mentioned in his first posting and from there to his GitHub user profile. Looking at the ReadMe’s and commit messages of his repositories I noticed that he writes in french.

I did that explicitly to figure out which UI language he presumably uses in Notepad++ because I’m aware of the language dependency of npp_menucommand.

Ekopalypse

@dinkumoil

clever :-) - I see.
Can’t promise, but I hope I won’t forget mentioning the localization dependency next time :-D

guy038

Hello, @Joey79100, @meta-chuh, @ekopalypse, @dinkumoil, and All,

@Joey79100, may be, this post, below, could be of some interest for you :

https://notepad-plus-plus.org/community/topic/16056/how-to-get-an-external-diff-viewer-with-n-and-the-last-compare-plugin-v2-0-0-0/1

Best Regards,

guy038

Ekopalypse

@guy038

correct me if I’m wrong but I understood that this is what OP did in first place and
seems not to work in 7.6.6 (maybe since 7.6) anymore.

dinkumoil

@guy038

I tried your How-To but it didn’t work. Notepad++ starts up and the two files are loaded, but no comparison takes place.

I used the debug option of the settings file which makes it possible to view the debug output using DbgView by Sysinternals. It seems Compare.exe can not find the Plugins/Compare/Compare menu entry. It finds Plugins/Compare and then only finds the Detect Moves entry repeatedly.

I have tried it with german and english locale for Npp’s UI and also removed the keyboard shortcut for the Compare submenu entry - no success. My Npp version is 7.5.6.

If somebody is interested in a complete solution using the method @Ekopalypse found above - I wrote a Batch script and a VBS launcher for it (to avoid flickering console windows). The VBS launcher could be integrated into the Explorer context menu. It is able to process two files at once or it can be called twice with only one file each.

pnedev

Hello all,

@Joey79100 ,

Is another instance of Notepad++ running when you start the compare.exe launcher?
The compare launcher (compare.exe) starts Notepad++ in multi-instance mode.

I just looked at the compare launcher (compare.exe) source code and it should work with notepad versions above version 6.
The compare is triggered by searching for Compare plugins menu and Compare command which should both exist for Compare v2 and since the command ID is traced by name the menu ordering shouldn’t matter.

Since the problem is with Notepad v7.6.6 I wonder if there is some kind of regression in its version API message.

Can somebody who has installed Notepad++ 7.6.6 try sending NPPM_GETNPPVERSION (through PythonScript for example) and share what he/she gets from it?

This issue aside, I wonder if it is worth implementing another Notepad++ command line argument that specifies which command to run upon start. What do you guys think?
It might be gotten by name or menu and name and will be very useful for such batch invocations for any plugin or Npp command.
This will make the compare.exe launcher (or any other additional plugin launcher) unnecessary.
For example:

notepad++.exe -nosession -multiInst file1 file2 .... --run=Compare:Compare
(Compare Npp sub-menu, Compare command)

BR

dinkumoil

@pnedev said:

Can somebody who has installed Notepad++ 7.6.6 try sending NPPM_GETNPPVERSION … and share what he/she gets from it?

Did it using the NppExec plugin. The result is 0x00070042 - i.e. hi-word 7 and lo-word 66, the expected result.

Since the problem is with Notepad v7.6.6 …

The problem also exists with Notepad++ v7.5.6, see my posting above.

I wonder if it is worth implementing another Notepad++ command line argument that specifies which command to run upon start.

Would be nice to have, but I think people who need such a feature have no problem to install and use a plugin for that. A plugin provides more flexibility than simply simulating a mouse-click on a menu entry.

pnedev

@dinkumoil ,

Did it using the NppExec plugin. The result is 0x00070042 - i.e. hi-word 7 and lo-word 66, the expected result.

Thanks for testing that.

The problem also exists with Notepad++ v7.5.6, see my posting above.

OK, I must have missed that.

A plugin provides more flexibility than simply simulating a mouse-click on a menu entry.

I agree but for more simple use it would be easier if Notepad++ could “simulate a simple mouse-click” directly through the command line.

guy038

Hi, @joey79100, @meta-chuh, @ekopalypse, @dinkumoil, @pnedev, @dail and All,

Oh, stranger and stranger ! I found out something which seems off-topic but, eventually, allows the DOS program compare.exe to work nice ;-))

As you may know, I’m used to keep, numerous locale versions of Notepad++ for testing, on my laptop, in directories, like below :

D:\@@\692\..., D:\@@\733\..., D:\@@\742\..., D:\@@\756\..., and of course all versions from N++ v.7.6.0 so the directories D:\@@\76x\...

And, generally, I don’t have the same plugins installed, in each configuration, as I installed a few for testing only !
Of course, for each tested version, I needed to install, first, the last Compareplugin v2.0.0.0 and its comparePlugin directory :
- Along, with the others plugins, for tested N++ versions under v7.6.0
- In a new Compareplugin folder, for tested versions, from v 7.6.0 and above
At the upper level, in the directory D:\@@, I placed the two files compare.exe and compare.ini, that I had previously extracted from the folder ComparePlugin of the archive ComparePlugin v1.5.6.6.bin.zip
In this same folder, I also placed two small working files z1.txt and z2.txt, slightly different, to see the results when comparing

Remark :

As all my N++ installations are portable ones, so not locatable via registry, the compare.ini file must contain, for instance, the line :

path=D:\@@\760\notepad++.exe

Finally, in a DOS console window, I ran the command :

D:\@@\compare.exe z1.txt z2.txt

And I was very intrigued to see that this same DOS command worked with my version 7.6.0 and not with my version 7.5.6 ( of course, I changed the path line, accordingly, in the compare.ini file ! ). More precisely, I mean :
- With the 7.6.0 version, Notepad++ started with z1.txt in the main view and z2.txt in the secondary view and the compare process already done : the expected behavior :-))
- With the 7.5.6 version, Notepad++ started with the two files, simply opened in the main view, without any compare process : the wrong behavior
Contrary to what you might think, this is not the consequence of the new way of installing plugins ! After one day of numerous tests ( Pfeeew ! ) I have come to the conclusion that if you include the BetterMultiSelection ( v1.3.0.0 ) plugin of Justin Dailey ( aka @dail ) , in your N++ configuration, it allows the compare.exe program, via the DOS command D:\@@\compare.exe z1.txt z2.txt, to get the right behavior ;-))
I cannot explain this fact and the logic of it ! I verified this assertion, with numerous versions of N++ and, of course, with any version above N++ v7.5.9 . During each test, I pressed the F1 key to make sure the expected Notepad++ version was used !
The tested versions of N++ were : v6.8.1, v6.8.8, v6.9.2, v7.2.0, v7.3.3, v7.4.2, v7.5.6, v7.5.8, v7.6.0, v7.6.1, v7.6.2, v7.6.3, v7.6.4, v7.6.6,

However, be aware that some plugins break the right behavior of the compare.exe program ! Here is the ( non-exhaustive ) list of these plugins :

AnalysePlugin.dll, AutoCompletion.dll, AutoEolFormat.dll, AutoSaveU.dll, Binhex.dll, Ccc.dll, Color_Picker.dll, ColorPicker.dll

Up to now, after all my tests, it seems that everything is fine with all the plugins of the list, below :

    CustomizeToolbar.dll
    CutNCopyLine.dll
    DB_RegExp.dll
    DSpellCheck.dll
    ElasticTabstops.dll
    Explorer.dll
    FileSwitcher.dll
    FingerText.dll
    GhNppExec.dll
    GmodLua.dll
    HexEditor.dll
    HTMLTag.dll
    IndentByFold.dll
    LanguageHelp.dll
    LightExplorer.dll
    LineFilter.dll
    LineFilter2.dll
    LocationNavigate.dll
    LuaScript.dll
    MarkdownViewerPlusPlus.dll
    ModelineParser.dll
    MultiClipboard.dll
    NativeLang.dll
    NavigateTo.dll
    NppAStyle.dll
    NppAutoIndent.dll
    NppCalc.dll
    NppColdFusion.dll
    NppColumnSort.dll
    Nppcrypt.dll
    NppExec.dll
    NppFTP.dll
    NppHasher.dll
    NppHorizontalRuler_Eng_0.1.5.dll
    NPPJSONViewer.dll
    NppMarkdown.dll
    NppMenuSearch_0.8.0.0.dll
    NppPlugin_ChangeMarker.dll
    Nppplugin_ofis2.dll
    NppPlugin_PluginMargin.dll
    NppPlugin_SciMarkerSymbol.dll
    nppplugin_solutionhub.dll
    nppplugin_solutionhub_ui.dll
    nppplugin_solutiontools.dll
    NppQCP.dll
    NppRegEx.dll
    NppSnippets.dll
    NppTaskList.dll
    NppTextFX.dll
    OpenFileInFolders.dll
    Pork2Sausage.dll
    PreviewHTML
    PythonScript.dll
    QuickText.dll
    RunMe.dll
    Scintillua++.dll
    SearchPlus.dll
    SecurePad.dll
    SelectNLaunch.dll
    SessionMgr.dll
    SourceCookifier.dll
    SpellChecker.dll
    SurroundSelection.dll
    Tidy2.dll
    Translate.dll
    VIsimulator.dll
    XBrackets.dll
    XmlNavigator.dll
    XMLTools.dll
    XPatherizerNPP.dll
    ZenCoding-Python.dll
    ZoomDisabler.dll

So, guys, could you test my assumption ? ( the fact of adding the BetterMultiSelection plugin is the key !? ) Many thanks for that !

https://github.com/dail8859/BetterMultiSelection/releases

Best Regards,

guy038

P.S. :

May be, all this story is related with my Win XP SP3 laptop configuration ! Here is my debug info for the last v7.6.6 N++ version :

Notepad++ v7.6.6   (32-bit)
Build time : Apr  3 2019 - 23:49:50
Path : D:\@@\766\notepad++.exe
Admin mode : OFF
Local Conf mode : ON
OS : Windows XP (32-bit)
Plugins : BetterMultiSelection.dll ComparePlugin.dll DSpellCheck.dll mimeTools.dll NppConverter.dll NppExport.dll

dail

@guy038

I would like to take credit for purposely enabling the functionality with the BetterMultiSelection plugin…but I haven’t the slightest idea to why it does. The only “odd” thing it might do is hook the keyboard, but my SurroundSelection works the same way. So not sure what the root cause is.

guy038

Hi, @Dail and All,

I also tested your other SurroundSelection plugin to verify if it could act as a catalyst ! Unfortunately, it cannot take on this role:-(

On the other hand, even if your BetterMultiSelection is not enabled, it does not prevent the compare.exe program for acting just as expected ;-)) So, people may install it, without using it, if preferred !

Tested on two configurations v7.5.6 and v7.6.6. Very very strange, indeed !!

Cheers,

guy038

dinkumoil

@guy038

Indeed, some of the plugins you found preventing compare.exe from working correctly are installed at my testing environment with Notepad++ v7.6.6 (a VM ), e.g. AnalysePlugin, AutoEolFormat and ColorPicker.

But I don’t think that these plugins directly prevent compare.exe from doing its job nor do I believe that the BetterMultiSelection plugin is directly responsible for allowing compare.exe to work properly.

When compare.exe starts up Notepad++, it performs a (I would like to call it) “remote search” in the menu structure of Notepad++ to find the correct menu entry (menu Plugins\Compare\Compare) to simulate a mouse-click on. Unfortunately the Plugins menu gets build up dynamically by Notepad++ during its startup. The time needed for that process depends on the number of installed plugins and how many submenu entries they want to install.

That means compare.exe can not exactly know when the Plugins menu is completely built up. Instead it has to use guessing to try to get the right point of time to start its search. I think it waits for a certain time before searching or it tries to find the menu entry a certain number of times and gives up if it was not able to find it or it uses a combination of both methods. If I look to the debug output (see my posting above) I tend to say it uses at least the second approach.

For what ever reason the presence of the BetterMultiSelection plugin helps compare.exe (maybe only on your system!) to get the right point of time for starting its search (but I have no clue how this could work) and the presence of other plugins prevent it from that.

guy038

Hi @dinkumoil and All,

You said :

That means compare.exe can not exactly know when the Plugins menu is completely built up. Instead it has to use guessing to try to get the right point of time to start its search. I think it waits for a certain time before searching or it tries to find the menu entry a certain number of times and gives up if it was not able to find it or it uses a combination of both methods.

I do think that it’s the main point ! Thinking again about this matter, I realize that the list of the 8 plugins, that I gave in my previous post, and which prevents the compare.exe from working as expected, have a name with the first letter between A and C, only. And, as if by chance, the BetterMultiSelection name begins with letter B… …

Not difficult to understand that, if any of these 8 plugins are not present, the BetterMultiSelection plugin becomes, generally, the first plugin of the alphabetic list of the plugins, … and, a priori, right before the Compare plugin ;-)) ;-)) This should mean a lot !?

Best Regards,

guy038

pnedev

Hi all,

The problem was in the code of the compare loader itself.

for (int i = 0; i < iMenuItems; i++)
{
...
GetMenuItemInfo(hPluginMenu, i, TRUE, &mii);
if (!lstrcmp(buffer, L"Compare"))
{
...
int iSubMenuItems = GetMenuItemCount(mii.hSubMenu);
for (int j = 0; j < iSubMenuItems; j++)
{
...
GetMenuItemInfo(mii.hSubMenu, i, TRUE, &smii);

The second GetMenuItemInfo should use the second forcycle index:

GetMenuItemInfo(mii.hSubMenu, j, TRUE, &smii);

BR