Background: I do know the standard approach to this and have it working for many apps, but wanted to run this by the experts here due to the concerns outlined in the benefits section below. (Just mentioning this so that I don't get referred to the manual or receive tips on how to make it work the conventional way.)
I have an application where the only setting I need dynamically update with [FileWriteN] is the path.
However, it stores it in two different keys.
So it is costing me two [FileWriteN]'s to get it ready.
If I read the source correctly [RegistryValueWrite] is done AFTER [RegistryKeys].
So, If I:
1) Retain [RegistryKeys] (including the keys that store the path)
2) Use [RegistryValueWrite] to write the path like this:
HKLM\SOFTWARE\Vendor\Subkey\Path=REG_SZ:%PAL:AppDir%\SubfolderofApp\
I am thinking it would have the following benefits:
1) Be faster (completely eliminates file substitutions requirement in this case)
2) Still accurately backup and restore the keys from a local instance of the app (because I also have a [RegistryKeys] line that covers the same keys)
3) Avoid pathing problems when the path, not just the drive, changes. (I replicate this configuration to multiple different paths from a standard config and have seen some (understandable) challenges for the launcher to handle this.)
However, since most of the [FileWriteN] examples I've seen are for handling the path, I am unsure if there is something I am missing about how this is all designed to work.
I am testing this now, but I am looking for a sanity check on whether there are other things in the platform that assume/prefer rewriting registry based paths be done via [FileWriteN].
Thanks.
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on BlueSky
Follow us on Facebook
Follow us on LinkedIn
Follow us on Mastodon
FileWrite happens before RegistryKeys and RegistryValueWrite happens afterwards. There's really very little between using an [FileWriteN] INI section (quoting the key -
Key='"RegistryKey"'- and the value when writing, not reading) and [RegistryValueWrite]. Provided that you double quote the key properly, you can treat a .reg file as an INI file. (That's the most important sentence in this comment - then it becomes not a fight between RegistryValueWrite and FileWriteN/Replace but RegistryValueWrite and FileWriteN/INI.)In general I use RegistryValueWrite because it's 2+n lines rather than 7n lines (including nice INI formatting). If it's used for the storing the language, [LanguageFile] needs to use an INI read in the former way (as the data isn't in the registry yet) but you can still use [RegistryValueWrite] for the actual writing.
RegistryValueWrite is designed to be used in conjunction with either a [RegistryKeys] or a [RegistryValueBackupDelete] line (generally the former).
Frankly, given this foundation:
Which of these would you prefer?
Or:
The [RegistryValueWrite] will be a tad more efficient, too.
When it comes to FileWriteN, though, do not be afraid to use it for non-drive-letter and non-language stuff. It can be used for other things as required - it is merely that those two are the most common.
(I hope these bits and pieces of information are helpful, it's not terribly contiguous.)
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1