presende

Hi again! I think that its advisable to folow some standard windows controls rules. Locked works. But it shouldn't be grayed, because sometimes we want force to select an option and grayed is normally associated with a disabled option. In group options shoudn't be allowed to select more than 1 option. If by mistake in all or several options/items in a group selected.x=1 is defined, it should be the last option/item with selected.x=1 defined activated. If by mistake in all options/items in a group selected.x=0 is defined, it should be the first not disabled (I'm counting that you implement Disabled attribute ) option/item selected by default. I think that's also better for consistency that all child objects inherit parent attribute values by default. That rule could be broked if in child objects we explicitly changed an attribute value. This adds some complexity I know. Also if attributes are omitted they should be considered with 0 values if they not inherit from parent objects (as for Root attributes if they are ommited they allways should be considered 0). As result ,inherit shouldn't be necessary. When WHIU do comparisons it automatically grays or in this developer version 2.1.10.0 uses Strikethrough, I prefer that sould be given flexibility to us explicitly set these attributes values after WHIU evaluates conditions (if.x=...). I liked very much your ideas in conditions and file and reg checks. Sometimes I have to do several file and registry checks in one condition. The problem is that in your proposal the expression would be very long for one line. Also, in if.x= command I think that maybe would better to continue to use selected=1|0, hidden=1|0, locked=1|0, ... instead of introducing new commands. My suggestion (perhaps I'm asking to much): condition.0= { file.version("%systemroot%\system32\file1.dll")>"1.2.3.4" & file.version("%systemroot%\system32\file2.dll")>"1.2.3.4" & file.version("%systemroot%\system32\file2.dll")>"1.2.3.4" & file.date("%systemroot%\system32\file1.dll")="01.12.2004" ! reg.key.exists("HKLM|HKCU:Key") } if.0=1 { locked=1 selected=0 } ? { locked=0 selected=1 } Thanks for all your efforts Benjamin, Paulo

I wish you luck with your studies and hope that you can retake programming WIHU soon. Also I see that your recent work has been centered in user settings and its logical to finish it and erradicate small glitches and bugs. I will use mostly WIHU for hotfixes, updates and feature packs installation for several softwares (Windows, Office,...) and it's important to me that I can check (file versions and registry keys/values checks combined) for previous updates installations, possible language conflicts and instabilities with updates and making harder or even impossible that an update that is not applicable to a system can be installed (Locked & Disabled attributes). For me, from my last suggestions, these are the most important (in my preference order): 1. New items attributes: Locked = 1|0 and Disabled = 1|0 2. Opportunity to take different actions from global comparison result (changing initial default attributes) 3. Evaluating in conjunction file and registry key/values 4. Adjust a little the meaning of comparison operators As for modifying your source code, I leaved software development long time ago, and I've no knowleged for that. Sorry I can't help more. Thanks again, Paulo

First of all: Congratulations Benjamin, what a great program! I would like to make some suggestions for future releases: 1. New items attributes: Locked = 1|0 and Disabled = 1|0 ------------------------------------------------------------------ Locked: Don't allow changing the Selected value. Disabled: Grayed + Locked. 2. Adjust a little the meaning of comparison operators -------------------------------------------------------------- I have some dificulties to completly understand the existing rules. My suggestion: ? True if file or registry key or value exist. ?! True if file or registry key or value doesn't exist. ?= True if file exist but as no version information or if registry key (registry values don't apply) exist but is empty (has no values). ?= <file version> True if file exist and has version equal to. ?= <dec|hex number> or <string> True if registry value has data equal to. ?!= <file version> True if file exist and has version different from. ?!= <dec|hex number> or <string> True if registry value has data different from. ?> <file version> True if file have version info greater than <file version>. ?< <file version> True if file have version info lesser than <file version>. ?>= <file version> True if file have version info greater or equal to <file version>. ?<= <file version> True if file have version info lesser or equal to <file version>. (I think that ?!<= and ?!>= have no need to be used because there are alternatives) 3. New attribute: CaseSensitive = 1|0 ------------------------------------------- Just for helping when comparing strings. 4. Explicit [Root] section for setting default values ----------------------------------------------------- This section has a fixed name [Root] and could have these attributes: [Root] Group = 1|0 Selected = 1|0 Collapsed = 1|0 Locked = 1|0 Disabled = 1|0 Hidden = 1|0 Some of them, apparently have no use or just don't make sense, but I think that their use is for setting defaults that apply to the hierarchy. The defaults could be after changed explicitly by sub-items/trees/branches. 5. Adjusting the name for file and registry commands ------------------------------------------------------------- file -> filever Making room for future filename filedate filesize key -> regkey and regvalue 6. Evaluating in conjunction file and registry key/values ---------------------------------------------------------------- comparison.x = AND|OR regkey.x = <path\registry key name>?<comparison operators)><string or number> regvalue.x = <path\registry value name>?<comparison operators><string or number> filever.x = <path\file name>?<comparison operators><file version> 7. Sublevels in comparisons -------------------------------- Example: comparison.x = AND|OR comparison.x.y1 = AND|OR regkey.x = <path\regkey>?<comparison operators)><string or number> regvalue.x = <path\registry value name>?<comparison operators><string or number> comparison.x.y2 = AND|OR regvalue.x = <path\registry value name>?<comparison operators><string or number> filever.x = <path\file name>?<comparison operators><file version> comparison.x.y1.z1 = AND|OR regkey.x = <path\regkey>?<comparison operators)><string or number> regvalue.x = <path\registry value name>?<comparison operators><string or number> comparison.x.y1.z2 = AND|OR regvalue.x = <path\registry value name>?<comparison operators><string or number> filever.x = <path\file name>?<comparison operators><file version> 7. Opportunity to take different actions (from initial default attributes) from global comparison result -------------------------------------------------------------------------------------------------------- Example: description.x = Description x command.x = cmd.exe /c @echo Command x ;Default attribute values Selected.x = 0 Collapsed.x = 0 Locked.x = 0 Disabled.x = 0 Hidden.x = 0 comparison.x = AND|OR regkey.x = <path\registry key name>?<comparison operators)><string or number> regvalue.x = <path\registry value name>?<comparison operators><string or number> filever.x = <path\file name>?<comparison operators><file version> ifresult.x = 1 (attributes to change if comparison result is true) Selected.x = 1 Collapsed.x = 1 Locked.x = 1 Disabled.x = 1 Hidden.x = 1 ;If comparison result is false the default attribute values are not changed. ;Also this is for example, it does not make sense using all attributes together. Thanks for your wonderful work and keep going! Paulo