WIHU Suggestion

[BenjaminKalytta]

@presende:

Thx for suggestion, some things sounds really good. But I think I've to make a little development break because I've to learn something for my next study semester which continues in october.

I'll repeat: everyone is welcome to modify my source, I'll provide this on my web site in next days.

Benjamin

[kalavera]

Just a quick note:

- I have tested version 2.1.9.1 and the "hint" didn't appear, i tried on deleting the user logged on or disabling it, both should show a message when leaving the user dialog not letting the user continue or when entering the user dialog (maybe better)

- Only appeared in the installation log a warning about not being able to copy the new profile.

- One minor thing, when you click cancel the messagebox isn't modal, so you can continue clicking in the application, for example cliking various times on the cancel button

Thanks

[BenjaminKalytta]

It's fixed now.

Benjamin

[presende]

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

[kalavera]

Sorry to tell you ... but i have tried the newest version and i still don't get the warning when disabling or deleting the currently logged user. It just let's me do it.

But i have found the error ... you are just making the warning when you select a user account in the GUI to disable or delete. You don't do the check from the operations loaded from the install.ini.

Maybe when entering the users list and loading the users you can do that check and giving the option to removing that "bad" entry (maybe a yes or no messagebox to do this automatically).

- One last suggestion ... maybe the cancel button in the finish dialog should be disabled or hidden if you want to force restart.

Many thanks for your time, and good luck for your exams!

[BenjaminKalytta]

@presende: Just try developer build 2.1.10.0.

locked.x is possible.

locked.0=1, inherit causes subitems to inherits locked.x settings from it's parent.

Comparison interface will be entirely rewritten later.

condition.x=<expression>

whereby <expression> could be

file.version("path\filename")<operator>"<data>"

file.date("path\filename")<operator>"<data>"

file.exists("path\filename")

file.size("path\filename")<operator>"<data>"

reg.value("HKLM|HKCU:Key")<operator>"<data>"

reg.value.exists("HKLM|HKCU:Key")

reg.key("HKLM|HKCU:Key")<operator>"<data>"

reg.key.exists("HKLM|HKCU:Key")

whereby each expression can be combined by & or | which means AND comparison and OR comparison respectively.

<operator> can be either =, !, > or <

Usage example could be:

• condition.0=file.version("%systemroot%\system32\wmp.dll")>"1.2.3.4" & file.date("%systemroot%\system32\wmp.dll")="01.12.2004"
  if.0=lock, unselect ? unlock, select
  

if.0=<if true> ? <if false>

BUT I don't know if I am able to do such complicated expressions because I've no experience in such script specific things. may be some one could help me here

@kalavera: Please forget [users.operation], this will be removed on future version.

You are right, it will only be checked if this is changed in WIHU UI.

- One last suggestion ... maybe the cancel button in the finish dialog should be disabled or hidden if you want to force restart.

No, because you can also set /Nocancel switch.

benjamin

[kalavera]

- I didn't mean [users.operations] i even have deleted that section from my install.ini.

What i mean is operations like delete or disable in the [users] section, they aren't checked. And this was my primary problem ... because i want to have some default user commands (the ones i posted some posts above), but if someone don't create a user then kapput!

If possible and don't give much trouble can you put the check also on the loading of install.ini or something?

- About the /NoCancel ... the problem is that then the cancel will be always disabled ... and maybe if someone just don't want to run wihu at the end of the installation just press cancel. But if it continues and we instruct wihu to force restart doesn't make sense to let it cancel at that stage.

[BenjaminKalytta]

@kalavera: Ok I'll see what I can do

Btw. I can only show a hint when loading install.ini if /autoinstall is not 0 because WIHU then must not be interrupted in any way.

(Or I'll use auto closing message boxes which closes it selfs after particular timeout )

Benjamin

[BenjaminKalytta]

@kalavera: There is btw. no switch which forces reboot. There is only a switch /NoRestartChange which disables "[x] Restart" Checkbox. So I wont change behaviour here.

Other thing is fixed now. Default timeout is 10 seconds if /AutoInstall or /AutoExit is specified.

Benjamin

[kalavera]

Once again ... THANKS!

But that place to make the warning maybe isn't the better (right at the start of the program), because that warning just makes sense if the user selects "use currently logged user". Maybe the best place to make the warning is when entering the users settings list (when i refered to check in the loading i thought it would be at this time the loading).

Another possible check ...

- You are logged as "Administrator"

- You have in [users] instruction to edit/disable/etc the user "Administrator"

- And you type as new user name: "Administrator" and fill the other fields

- Result: You will have 2 "equal" user accounts. This may give problems.

[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

[BenjaminKalytta]

- Result: You will have 2 "equal" user accounts. This may give problems.

Is intended and wont be changed.

...because that warning just makes sense if the user selects "use currently logged user

Of course, it will only be showed if this is selected. Just try it out.

In group options shoudn't be allowed to select more than 1 option.

Selection isn't possible from UI, but in ini file it should be possible. It's the user responsibility.

benjamin

[kalavera]

But the problem is that the "hint" message appears at the very beginning of the program, even before the first dialog (create primary user account dialog)!

It should only appear after that dialog and only if the user chooses to use the current logged user instead of creating a new one.

Showing the warning at the very beginning of the applications doesn't make sense.

Sorry for all this trouble.

Thanks for your time.

[BenjaminKalytta]

@kalavera: No sorry, you're wrong. It is only showed if "[x] use currently logged on user" is selected and when 2th dialog is loaded.

Benjamin

[kalavera]

Yes it works, sorry for the trouble.

My only explanation is that i had a bit older version. I redownloaded the last version and this one works right.

Edit: Exactly! I had the .1 and the latest is .2 version

Thanks for all.