Visual Studio resource file place-holder text substitution in Google Omaha
I'm trying to investigate a problem with resource files generated by Google Omaha. These resource files contain a place-holder token (%1!s!), which is substituted with branding details during the build process. There are numerous language resource files that contains string tables and this
Here is an example string: "%1!s! some arbitrary text"
Where %1!s! is a place-holder for some substitution text?
My question: is this place-holder substitution mechanism a standard part of the Windows resource file mechanism? If so, can someone please either explain how it works? Where does it get the text used to substitute the place holder? I'm assuming the place-holder works similar to place-holders in printf? If so, how does it know which text token to replace this with? If this is not a standard resource file mechanism, does anyone have a clue as to how Omaha does this during the build process?
Many thanks.
Note: I'm not looking for suggestions to use a different approach. This is how Omaha does it and I just need to understand how this works. Thank you.
Here is an example string: "%1!s! some arbitrary text"
Where %1!s! is a place-holder for some substitution text?
My question: is this place-holder substitution mechanism a standard part of the Windows resource file mechanism? If so, can someone please either explain how it works? Where does it get the text used to substitute the place holder? I'm assuming the place-holder works similar to place-holders in printf? If so, how does it know which text token to replace this with? If this is not a standard resource file mechanism, does anyone have a clue as to how Omaha does this during the build process?
Many thanks.
Note: I'm not looking for suggestions to use a different approach. This is how Omaha does it and I just need to understand how this works. Thank you.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
to add to the comments before:
yes, it is like sprintf. you even can specify non-string place holders for example an integer by %1!d!
i think formatting messages with placeholders %1, %2, ... is a deprecated and not recommendable method. if they would use place holders like <last_error> or <first_name> the resource management would be much better readable and less error-prone.
Sara
is this place-holder substitution mechanism a standard part of the Windows resource file mechanismnot really. it is a functionality in WINAPI and MFC (and Registry strings) where you can customize texts with current context data. a resource file itself cannot provide context data.
If so, can someone please either explain how it works?you always need an application which reads the resource strings with the place holders by ID and knows which placeholders should be replaced with which context data and then use a function like FormatMessage (or simply a string replace function) to build the final texts.
Where does it get the text used to substitute the place holder?they read text with place holders from a known resource id where they have context data to fill in.
I'm assuming the place-holder works similar to place-holders in printf?
yes, it is like sprintf. you even can specify non-string place holders for example an integer by %1!d!
how does it know which text token to replace this with?as told the application knows what the text is for and how many tokens it contains and what kind of data must be replaced. it is not easy to maintain such a system and even big companies may have bugs in their products resource management when using that method by not replacing all place holders. see the following MSDN remarks regarding the set of problems that might arise when using FormatMessage for replacing such placeholders.
Security Remarks
If this function is called without FORMAT_MESSAGE_IGNORE_INSERTS, the Arguments parameter must contain enough parameters to satisfy all insertion sequences in the message string, and they must be of the correct type. Therefore, do not use untrusted or unknown message strings with inserts enabled because they can contain more insertion sequences than Arguments provides, or those that may be of the wrong type. In particular, it is unsafe to take an arbitrary system error code returned from an API and use FORMAT_MESSAGE_FROM_SYSTEM without FORMAT_MESSAGE_IGNORE_INSE RTS.
i think formatting messages with placeholders %1, %2, ... is a deprecated and not recommendable method. if they would use place holders like <last_error> or <first_name> the resource management would be much better readable and less error-prone.
Sara
ASKER
You are indeed correct. I've subsequently discovered that Omaha loads the strings at runtime and then passes them into a CString and then uses FormatMessage on the string to fill in the place-holders.
Cheers