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
- :
- Re: System search question
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
‎Aug 26, 2009
04:55 PM
System search question
One of the requirements for my installer is that windows update has to be disabled. I did a System Search for:
Registry root: HKLM
Key: SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update
Value: AUOptions
This value is set to 1 is WU is disabled, and 2-5 depending on what enabled option you use. I store the result in property UPDATEDISABLED, and in the install condition table I test for UPDATEDISABLED<>1 and put a message saying you need to disable it before installing.
Problem is no matter what that value is set to, the condition doesn't trigger. I know it's reading it, because I put in another search looking for a non-existent file, with a message of "Updatedisabled is [UPDATEDISABLED]". When I ran it like that I got messages like "Updatedisabled is #1" or "Updatedisabled is #2" for registry values of 1 & 2 respectively. Not sure where the '#' came from, is that automatically put in front of numeric data ?
Any ideas why this isn't working ?
On a related note, there's IMHO a bug in the System Search UI. If you try to modify an existing entry that has been used in an install condition, it comes up with the 'just stick it in a property' radio button checked. If you select the 'install condition' radio button, the previous one is not used, and you add an additional line to the launch conditions table, even if you cancel at this point.
Registry root: HKLM
Key: SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update
Value: AUOptions
This value is set to 1 is WU is disabled, and 2-5 depending on what enabled option you use. I store the result in property UPDATEDISABLED, and in the install condition table I test for UPDATEDISABLED<>1 and put a message saying you need to disable it before installing.
Problem is no matter what that value is set to, the condition doesn't trigger. I know it's reading it, because I put in another search looking for a non-existent file, with a message of "Updatedisabled is [UPDATEDISABLED]". When I ran it like that I got messages like "Updatedisabled is #1" or "Updatedisabled is #2" for registry values of 1 & 2 respectively. Not sure where the '#' came from, is that automatically put in front of numeric data ?
Any ideas why this isn't working ?
On a related note, there's IMHO a bug in the System Search UI. If you try to modify an existing entry that has been used in an install condition, it comes up with the 'just stick it in a property' radio button checked. If you select the 'install condition' radio button, the previous one is not used, and you add an additional line to the launch conditions table, even if you cancel at this point.
(5) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 26, 2009
06:25 PM
Quite right, please see the bottom half of the "Registry Table" topic for information about what's going on with the # in front of the numeric (REG_DWORD) value.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 27, 2009
08:45 AM
RobertDickau wrote:
Quite right, please see the bottom half of the "Registry Table" topic for information about what's going on with the # in front of the numeric (REG_DWORD) value.
Is that in the help, or a thread here in the forums ? I searched around but didn't find one here.
Edit: Never mind, I found it in the help.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 27, 2009
09:29 AM
Ok that explains the #. So how do I test against it ? Using <>1 didn't work, nor did using <>"#1".
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 27, 2009
09:45 AM
Hmm, quick tests with conditions READ_FROM_REG="#1" and READ_FROM_REG<>"#1" seem to behave correctly...
As a sanity check, does AppSearch occur before LaunchConditions?
As a sanity check, does AppSearch occur before LaunchConditions?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 27, 2009
10:00 AM
Oops, operator error on that last one. I changed the condition to use "#1", and did a build, but failed to notice the build error, because I hadn't remapped the network drive I'm building to. Once I ran it actually using the new version it worked correctly.
Thanks!
Thanks!
![](/skins/images/8CE4FAD0DE6F3A6F9D0567434D2D2DAE/responsive_peak/images/icon_anonymous_message.png)