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:
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].