Foxit Reader Portable 5.4.4 leaves the following entry in the registry:
HKCU\Software\Foxit Software\Foxit Updater
Accordingly the following code must be added to the section [RegistryKeys]:
[RegistryKeys] FoxitUpdater=HKCU\Software\Foxit Software\Foxit Updater
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
Since that key relates to the updater, and we don't need it saved, using -=HKCU/Software/Foxit Software/Foxit Updater would suffice
Of course is the proposed code by you the better and proper solution. Thank you for this tip.
The default configuration for FoxitReaderPortable is "do not check for updates". When run in this manner, it does NOT create the HKCU entry you mention.
That registry key is created when you have checked "Automatically install updates".
neutron1132 (at) usa (dot) com
Apparently I have sometime accidentally activated in the settings the "Automatically Update". Indeed is that the cause for the appearence of that registry key on my computer. Accordingly I will change the supplement "Bug" into "Closed" in the subject of my original post.
I've thought once again about that topic. Suppose an user has enabled - for whatever reason - in the settings the "Automatically Update". I think it would be an appropriate precautionary measure, if we insert for this potential case the preventive code "-=HKCU/Software/Foxit Software/Foxit Updater" in the section [RegistryKeys].
I'm going to add in a check for this and have the launcher force it to turn automatic updates off on each start.
Sometimes, the impossible can become possible, if you're awesome!
Preventing the user from doing something wrong is a great ideal.
But how far do we go? For example, FoxitReaderPortable has the ability to permanently alter file associations for pdf files. Should we block that too? What about inserting itself into context-sensitive menus?
Another example would be plug-ins for various software packages that affect portability by one definition or another. How can they be identified? Should the user be prevented from installing them?
I wonder where the line is.
neutron1132 (at) usa (dot) com
I also have thought many times about this topic. And in fact, I found it already sometimes, that the portable version does not always provide all of the features compared to the non-portable version. However, the main idea should be realized, that a portable program leaves no traces.
Regarding file associations there exists the possibility to make them portable. As far as I know, should the file association be integrated into one of the next versions of the platform.
Regarding the integration of plugins the same applies. Basically we should also look for a solution to make the integration of plugins portable. For example I work for several months on a solution, that a lot of plugins for the programs PhotoFiltre and Irfanview can be involved. And I have detected, that there exists an amazing number of plugins, which can be integrated.
In principle should always be sought for a solution, that certain things can be made portable. And as long as this is not possible, you should refrain regarding using the appropriate features or use the non-portable version of the program.
As a further example I want remember, that also the option "Send to" can be made portable.
This is fixed in Foxit Portable 6.1.1
Sometimes, the impossible can become possible, if you're awesome!