So that 64 bit not setting file associations issue...

[Phaewryn O'Guin]

Is easily fixed by uninstalling the 32 bit version (and the current 64 bit version too if you’ve already installed it), going into \Program Files (x86), deleting the files the uninstall misses (which it does), restarting, then installing the 64 bit version BUT don’t use the \Program Files\ folder it wants, but tell it to install into the \Program Files (x86)\ folder instead. Your file associations will now be configured/saved.

I tried a lot of things, this was the best solution.

[PeterJones]

++@Phaewryn-O-x27-Guin, I’m glad you found a workaround, which will hopefully be useful to other NPP users.

However, a 64-bit application should be able to properly install in %ProgramFiles%, not in %ProgramFiles(x86)%. If there isn’t one already, someone should put in a github issue that show the steps necessary to reproduce the problem, and that shows that this workaround “works”, but is not a good long-term “solution”. It would be interesting, if possible, to give snapshots of the changes that are made to the registry in each step along the way (there are plenty of apps that show “registry differences” – because that might show where the bug comes from).

I personally haven’t made the switch to the 64-bit version yet, mostly because the plugins I use most have not been updated to 64-bit, and some might even be abandonware, so might never make the switch.

(My initial guess is that the installer has some discrepancy in bit-ness compared to the installed program, so sometimes uses the wrong value of the environment variable. But since I haven’t used the 64-bit NPP’s installer, my guess would be a WAG, not an educated guess nor even a SWAG*.)