Notepad++ 7.6.1

Meta Chuh

I would prefer though to have
%PROGRAMFILES(x86)%\Notepad++\APIs
instead of
%PROGRAMFILES(x86)%\Notepad++\plugins\APIs

it would be a cleaner, more logical structure, but at the moment there are many scenarios where it can break a functionality if you update an older installation, if they are not considered prior to coding the path changes, and i guess this means a lot of coding work for a cleanup which few people will ever notice or appreciate.

BTW, SessionMgr-1.4.2-plugin.zip stays as zero-bytes file in my user’s Temp folder after the installation fail.

it installs fine for me, but it is missing the menu title on both windows and osx.
alt

@donho
thanks again for the wine path and installer mods, all works like a charm so far. 👍

pnedev

@Meta-Chuh said:

it installs fine for me, but it is missing the menu title on both windows and osx.

It is Session Manager’s known issue that is fixed but not officially merged.

graphixillusion

I’m trying the new version, the portable one, but i can’t see the plugin manager anywhere. Any clue?

Ketrel

I cannot install any plugins in 7.6.1.
I load plugin admin, select the plugin I want, and choose install.

It tells me the program will need to be restarted.
I select ok, and then it closes, and launches a UAP prompt.
I approve that, and then the updater tells me there’s an updated version of Notepad++

If I say yes, it tries to install 7.5.9.
If I say no, it closes and does nothing further.

Upon manually reopening, the plugin I selected is NOT installed.

SinghRajenM

@dinkumoil said:

@pnedev

I miss installation progress too and when a plugin installation/update failed I was facing error messages that stated the wrong reason for that.

I already requested user feedback some weeks ago (see here). And @SinghRajenM has put some effort in writing code that extends GUP.exe to do so (see here and here). But for what ever reasons these PRs have been closed.

Not only this, but are other flaws too -

npp instance should not closed till operation is successful.
plugin admin can have one more column in it which will guide about current state of action of a plugin (e.g. downloading plugin or restart npp to take effect so on).
As all demanded, plugin admin can have progress bar which should interact with gup.exe using IPC to get the current downloaded size. Or something similar mechanism to accomplish it.

Cases:

Add: If a plugin is being downloaded first time, there is not point to close npp instance. download the plugin, then extract it to plugin install directory. Later ask user to restart to take immediate effect. However, on next restart the plugin will be activated by default.
Remove: simply move (using move api) the plugin dll from the install dir to %temp% and once done, ask user to restart. If user does not restart to take immediate effect, otherwise on next restart it will be effected anyway.
Update: First follow “remove” case strategy and then follow “add” case. Once both the cases done, ask user to restart npp or anyway it will take effect on next restart.

Of-cource failures should be handled for all the cases. And all the cases, extra column can content current progress.

chcg

@donho See https://github.com/notepad-plus-plus/wingup/pull/8 for the unzip issue. It fixes at least some aspects of the problem, also still some files are empty.

dinkumoil

@SinghRajenM said:

npp instance should not closed till operation is successful.

Good point, currently there is taken no means to prevent the user from restarting Notepad++ manually in the middle of plugin installation/update.

Imagine a plugin download takes a long time because of slow responding servers and the plugin DLL file is only written as a half. The user gets unpatient and starts Notepad++ manually -> crash, user is unhappy, complains here in the forum and tells his friends that Notepad++ is garbage.

On the other hand I have no idea how to prevent the OS to run a new instance of Notepad++. In the moment a piece of software can detect that a new Notepad++ process is running it is already too late.

plugin admin can have one more column in it which will guide about current state of action of a plugin (e.g. downloading plugin or restart npp to take effect so on).

As all demanded, plugin admin can have progress bar which should interact with gup.exe using IPC to get the current downloaded size. Or something similar mechanism to accomplish it.

Would be really good to have, but I’m afraid that it violates the KISS approach of @donho and thus we will never get it.

Remove: simply move (using move api) the plugin dll from the install dir to %temp%

I don’t agree. I think it is not possible or at least not a good idea to move a plugin DLL file while it is in use.

I think it’s worth to rethink about the whole concept of the plugin update process.

The download of plugin ZIP packages should be done by Notepad++ itself. This way it would be easy to provide a progress bar, meaningful error messages which reflect the real cause of an error and it would prevent users from manually restart Notepad++ because they could see that it is still running and does something. The downloaded ZIP packages should be stored to a subdirectory of the %TEMP% directory.
After downloading the ZIP packages, Notepad++ should start a helper program, depending on the installation scenario of Notepad++ with or without elevated rights, and terminates itself. I recommend to write a new software for that, I will explain below why.
The helper has to be called with an information where to find the ZIP packages and where to unpack them. It waits until there is no more running Notepad++ process. Then it loops over all downloaded ZIP packages found in the source directory and unpacks them to the given location. During this phase it displays a progress bar to provide user feedback.
Finally the helper program restarts Notepad++ without elevation.

Why do I think we need a new helper program for that?

The whole thing is a specialized task for updating plugins. GUP.exe was designed to be used as an application updater and it should stay to be that. Currently every change to the plugin updating code bears the risk to break the updating functionality of Notepad++. That alone is a good point to separate these tasks into two programs.

Furthermore we have currently the problem that portable installations of Notepad++ can not be shipped with GUP.exe because it would download an installer version of Notepad++ when users click to (menu) ? -> Update Notepad++. With a separate program for plugin updates this would be no issue anymore.

BTW: It is really annoying to explain users her in the forum again and again why portable versions do not contain Plugin Admin, this should be fixed ASAP, it doesn’t matter in which way.

A Former User

@donho
Hello, the Plugins Admin is not supported on Windows XP. GUP.exe calls a function named GetTickCount64 which is implemented in the kernel dll starting from Windows Vista. There is a GetTickCount function which returns a double word, so the elapsed milliseconds are limited up to 49.7 days, but this is better than nothing. Or is there any other function that can “replace” what GetTickCount64 function for WinXP? A quick fix would be to use the dword function if notepad++ is running on XP or older Windows . . .

Meta Chuh

@graphixillusion

the portable version does not contain plugins admin.
you’ll have to install the full version to get the full functionality for now.

dinkumoil

@donho

I tested in a VM to install Notepad++ as a normal Windows user. I found that it is only possible to update the plugin list when logged in as an administrator. Furthermore the installer does not create the directory %UserProfile%\AppData\Roaming\Notepad++\plugins\Config which caused crashes of Notepad++ itself when terminating it and also various plugins caused crashes.

What I did

I created a standard user account and installed Notepad++ to %ProgramFiles(x86)% (OS: Windows 7 x64). I copied the plugin list under %ProgramData%\Notepad++\plugins\Config to the desktop. Then I tried to overwrite the file at its original location with this copy. This is equivalent to overwrite the plugin list with an updated version downloaded from the internet. An UAC dialog poped up and required me to input administrator credentials.

When I looked in Windows Explorer to the Security tab of the plugins\Config directory properties it showed access rights for normal Windows users as usual, no write access available. It’s the same with the nppPluginList.dll itself.

Furthermore I was faced with crashes of Notepad++ when terminating it. Also various plugins I installed via Plugin Admin caused a crash. It stops after I have installed the NppFTP plugin. The reason was that this plugin creates the directory %UserProfile%\AppData\Roaming\Notepad++\plugins\Config which did not exist after installation of Notepad++.

I would say: It’s time for a new release. :-(

Artur Harison

Plugins are not UNinstall from %ProgramData% only manual removal.
Or, when running as Administrator.

dinkumoil

@Artur-Hareson said:

Or, when running as Administrator.

That is the intended behaviour. As normal user you should not be able to install, uninstall or update plugins. And it is indeed not possible to do that using Plugin Admin because it causes to pop up an UAC prompt where you have to provide credentials of an admin user.

Artur Harison

I can use Admin mode. But then i can’t use Drag and Drop in field NP++.
I can’t get rid of it. )))

dinkumoil

@Artur-Hareson said:

I can use Admin mode. But then i can’t use Drag and Drop in field NP++.

I have not meant to run Notepad++ as an admin user. When you try to install, uninstall or update a plugin, a so called Windows User Account Control (UAC) dialog pops up, where you have to provide username and password of an admin user to allow these actions. All these actions can be initiated from within Plugin Admin. No need to manually fiddle around in the plugins directory.

dinkumoil

@donho

I want to add some further information to my posting above.

The reason why the directory %UserProfile%\AppData\Roaming\Notepad++\plugins\Config didn’t exist was, that I started the installation of Notepad++ under a normal Windows user account without admin rights. Thus I had to confirm an UAC dialog and there I provided username and password of an admin user.

This, in turn, caused that during installation there have not been written any files to the user profile of the normal user. When I started Notepad++ for the first time as the normal user, it created its own config files under %UserProfile%\AppData\Roaming\Notepad++ but the directories plugins\config were still missing. When plugins tried to read their config files they caused crashes.

A solution for that issue would be that Notepad++ itself checks the existence of plugins\config and creates them if they are missing.

SinghRajenM

@dinkumoil

I don’t agree. I think it is not possible or at least not a good idea to move a plugin DLL file while it is in use.

It is possible and widely used specially for shell extensions. As you know shell extension dlls are locked in explorer.exe. So during uninstall process, those dlls are moved (MoveFile is the api) to somewhere else (mostly %temp%) and handed over to OS to take care of those temp files on reboot. Unfortunately, that is not followed by npp for its shell. That is the reason, NppShell_06.dll is left even after complete uninstall.

I think it’s worth to rethink about the whole concept of the plugin update process.

I second this.

dinkumoil

@SinghRajenM

Thank you for your explanation, I didn’t know that.

But the documentation of MoveFile states:

The one caveat is that the MoveFile function will fail on directory moves when the destination is on a different volume.

Thus it would fail on my system. My system disk is an SSD with a size of 256 GB. I’ve splitted it into 2 partitions, one for Windows 7 and one for a (future) Windows 10 Installation. To prevent exhaustive write access to my SSD and to save some space I relocated the %TEMP% directory (and some others) to drive E: which is an additional conventional hard disk.

So I can say, I like it that Notepad++ doesn’t use this method to deinstall the shell extension, I would only facing errors.

donho

@pnedev said:

Perhaps the APIs sub-folder needs to be located also in %PROGRAMDATA% :
%PROGRAMDATA%\Notepad++\APIs
instead of
%PROGRAMFILES%\Notepad++\plugins\APIs
because of what @dinkumoil just pointed above - some lexer plugins might want to add some files to APIs as well.

Good point. It will be in the next release.

donho

@Ketrel said:

I cannot install any plugins in 7.6.1.
I load plugin admin, select the plugin I want, and choose install.

It tells me the program will need to be restarted.
I select ok, and then it closes, and launches a UAP prompt.
I approve that, and then the updater tells me there’s an updated version of Notepad++

If I say yes, it tries to install 7.5.9.
If I say no, it closes and does nothing further.

Upon manually reopening, the plugin I selected is NOT installed.

Your Gup.exe is the old version. Update it from the installer will remedy your problem.

donho

@dinkumoil said:

I tested in a VM to install Notepad++ as a normal Windows user. I found that it is only possible to update the plugin list when logged in as an administrator.

It’s not been done yet. I’ll modify NTFS folder’s right for %PROGRAMDATA%\Notepad++\plugins\Config\ in order to be able to update nppPluginList.dll in the future release.

Furthermore I was faced with crashes of Notepad++ when terminating it. Also various plugins I installed via Plugin Admin caused a crash. It stops after I have installed the NppFTP plugin. The reason was that this plugin creates the directory %UserProfile%\AppData\Roaming\Notepad++\plugins\Config which did not exist after installation of Notepad++.

I would say: It’s time for a new release. :-(

That’s for sure. However, any suggestion for the remedy of crash?