This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Reading and writing to Registry DWORD values
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 29, 2011
06:13 AM
Reading and writing to Registry DWORD values
I have to install an application that uses a DWORD in the registry to hold the Port number for a server application. The default Port number is 80, but this can be changed by the user. Looking ahead to the first upgrade I needed a system search to read the old value and overwrite the default number if found. I told my boss "No problem, five minute job to add this functionality."
On one of the dialog boxes I have an edit box. On first install it defaults to 80 and the user can change this if he wants. Assume he doesn't. The installer runs and saves this value to the DWORD as a hex value 0x80 (128)
FAIL !! Is there an automatic way to save it as decimal, or convert to hex ie 0x50 (80), bearing in mind the actual number could be anything the user decides to change it to.
It gets worse when I look at the upgrade action.
The system search brings back the Hex number and appends a # to it, so my initial decimal 80, is saved as 128 and then read back as #80, if I don't do anything with this value and try to resave it back to the registry like that, it changes the DWORD to a String and saves it as "#80"
I have asked my developers if they could use a string value instead. They looked at me like I'm an idiot and say, "We just want you to save a number to the registry, how hard is that?"
Do I have to write a CA to convert decimal to hex before I save the value and another CA to strip off the # when I read it back?
Thanks in advance.
Basic MSI, IS2011
On one of the dialog boxes I have an edit box. On first install it defaults to 80 and the user can change this if he wants. Assume he doesn't. The installer runs and saves this value to the DWORD as a hex value 0x80 (128)
FAIL !! Is there an automatic way to save it as decimal, or convert to hex ie 0x50 (80), bearing in mind the actual number could be anything the user decides to change it to.
It gets worse when I look at the upgrade action.
The system search brings back the Hex number and appends a # to it, so my initial decimal 80, is saved as 128 and then read back as #80, if I don't do anything with this value and try to resave it back to the registry like that, it changes the DWORD to a String and saves it as "#80"
I have asked my developers if they could use a string value instead. They looked at me like I'm an idiot and say, "We just want you to save a number to the registry, how hard is that?"
Do I have to write a CA to convert decimal to hex before I save the value and another CA to strip off the # when I read it back?
Thanks in advance.
Basic MSI, IS2011
(3) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 29, 2011
07:12 AM
Huh, from reading Registry Table, specifically the parts under Value, that's not what I would have expected. A value of #80 should be the DWORD with value 80 (I had assumed decimal since nothing is mentioned and...) a value of #x80 is explicitly a hexadecimal value (but REG_BINARY).
Looks like I forgot something too. 😮
It sounds like you're best off setting the registry key to a property, e.g. [THEPORT] (no leading #) where THEPORT's value looks like #50. Then when you read in #50 or #80 it wll round trip correctly. Then have a companion property (e.g. DECPORT) for your users which translates to and back from decimal via two custom actions.
Looks like I forgot something too. 😮
It sounds like you're best off setting the registry key to a property, e.g. [THEPORT] (no leading #) where THEPORT's value looks like #50. Then when you read in #50 or #80 it wll round trip correctly. Then have a companion property (e.g. DECPORT) for your users which translates to and back from decimal via two custom actions.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 29, 2011
09:40 AM
Thanks for the reply MichaelU, I often see your posts and they are usually very helpful.
Well I've been chopping and changing things and now I've got a different behaviour to the point that I'm wondering if I misread my earlier observation. Now the installer is saving the figure as a decimal - ie I enter 80 and it saves as 0x50 (80) while the value returned is #80, thus all I've needed to do is write a simple VB Script CA to trim the # off which is run after CostInitialize. Here is the script for anyone who wants it.
WebServer_Port = Session.Property("WEBSERVER_PORT")
If (WebServer_Port="") Then
Else
Hash=Left(WebServer_Port,1)
If (Hash="#") Then
WebServer_Port=Right(WebServer_Port, Len(WebServer_Port)-1)
Session.Property("WEBSERVER_PORT") = WebServer_Port
End If
End If
Really confused how I got to the original conclusion?
Well I've been chopping and changing things and now I've got a different behaviour to the point that I'm wondering if I misread my earlier observation. Now the installer is saving the figure as a decimal - ie I enter 80 and it saves as 0x50 (80) while the value returned is #80, thus all I've needed to do is write a simple VB Script CA to trim the # off which is run after CostInitialize. Here is the script for anyone who wants it.
WebServer_Port = Session.Property("WEBSERVER_PORT")
If (WebServer_Port="") Then
Else
Hash=Left(WebServer_Port,1)
If (Hash="#") Then
WebServer_Port=Right(WebServer_Port, Len(WebServer_Port)-1)
Session.Property("WEBSERVER_PORT") = WebServer_Port
End If
End If
Really confused how I got to the original conclusion?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 29, 2011
10:49 AM
I tend to blame bad eyesight or grit on monitors. :cool:
Thinking about it more, I like your approach as well (aside from the use of VB, at least; I just wish MSI came with some builtin string munging capabilities). This normalizes the value at the one point you know it tends to be incorrect for its later use.
Thinking about it more, I like your approach as well (aside from the use of VB, at least; I just wish MSI came with some builtin string munging capabilities). This normalizes the value at the one point you know it tends to be incorrect for its later use.
![](/skins/images/8CE4FAD0DE6F3A6F9D0567434D2D2DAE/responsive_peak/images/icon_anonymous_message.png)