WPI 5.4 wishlist

[Francesco]

Look in the changelog that is supplied with the WPI download it has been done you just need to save different configs and call them.

* Added command line support to specify different config and user options

files:

WPI.hta options=useroptions_mritter.js config=config_mritter.js check=Work timer=30

If a path is not specified for the file, it will assume they are in

WPIScripts.

It will still check for:

WPI.hta Work 30

for backwards compatibility. But update your tags, please. They will probably

change in the future. Thanks to Dje again for the code and help.

NOTE: Paths can be full (starting with a drive letter) or relative to WPI.hta

(starting with '.\' or '..\') and must end in '.js'. Spaces are supported only

is a path is provided and properly quoted: (config="c:\space in\file path.js").

No I meant something more direct: now you're forced to show the interface because 0 value doesn't work for the timer. Opening the progress dialog without the wpi interface being shown would be great.

[mritter]

Not showing the interface could be done. I printed your idea so look for it in the next version.

[almulder]

zorphnog: I would like to see the Tips style integrated into the Themes either through wpi.css or a new theme file i.e. tips.css.

I have been working on this very idea for some time. Have it complete but not the way I want. I have many more things to add, It will still be some time before completed, as I dont have much free time after work. But glad to see someone else would like to see the same thing.

Thanks

[kev_147]

Can WPI 5.4 output all the available variables to the WPI Log file and what they are returned as. This would be useful for command line syntax.

[mritter]

@kev_147: Do you mean like what everything in useroptions.js is? Save a copy of that in the log file?

[kev_147]

@MRitter

Mark, I mean all the variables that WPI can determine, such as

%WPIPATH%

%SYSTEMDRIVE%

%WINDIR%

%CDROM% or %CDDRIVE%

%SYSTEMROOT%

%TEMP%

Can these be entered in the log file as:

Variables detected by WPI as:

%WPIPATH% = D:\$OEM$\WPI

%SYSTEMDRIVE% = C:

%WINDIR% = C:\Windows

%CDROM% or %CDDRIVE% = D:

%SYSTEMROOT% = C:\Windows

%TEMP% = C:\Documents and settings\Kevin\Local settings\Temp

Does anyone think this would be useful? I just think it will assist with the configuration of the cmd parameters within WPI

[sadicq]

Yep, I'd find that useful, so I totally support its developing.

[Francesco]

What about giving more space in the percent bar to bigger setup files? It's not that hard just sum all the file sizes of the commands and then start from 0 when the progress dialog starts and use (CURRENTSUMOFSIZES)/TOTALSUM to find out the current percentual of installation.

[Francesco]

I also have another suggestion however this surely takes too long to get implemented in a single version change. Pratically removing all the Command1 Command2 Command3 and replacing everything with a big list box that allows the user to insert every action they want to perform (for example integrate a registry file execute an application register a dll and so on) also it would be cool to have the same listbox for application requirements (for example MBs of ram CPU type or things like that). That would be really really cool and also easy to use because there won't be only commands anymore but the users could have wpi perform different tasks other than executing files.

[devilrunner]

It would be nice to have uninstall functionality...

Some adjustments to the gcond or cond statements which automaticaly scans which wpi items are installed.

Then if you uncheck them again items are uninstalled with the uninst[pn]= statement.

Just an idea.

Could this be done?

[mritter]

@kev_147: idea printed out so I don't forget. Should be no problem at all.

@Francesco: First idea, not sure if you mean to show the progress of the current installer or still over all. Clarify it a bit for me. Second idea, I already have a plan for the those lines similar to what you mentioned. The only thing holding me back is that it will affect the config.js file for EVERYONE. Will need to write porting script to update them. But still on my to-do list.

[kev_147]

nice one Mark, will make things easier for me and hopefully others as well.

[Francesco]

@kev_147: idea printed out so I don't forget. Should be no problem at all.

@Francesco: First idea, not sure if you mean to show the progress of the current installer or still over all. Clarify it a bit for me. Second idea, I already have a plan for the those lines similar to what you mentioned. The only thing holding me back is that it will affect the config.js file for EVERYONE. Will need to write porting script to update them. But still on my to-do list.

Application 1:

- Command1=path\setup1.exe (size=30mb)

- Command2=path\setup2.exe (size=40mb)

Application 2:

- Command1=path\setup1.exe (size=10mb)

- Command2=path\setup2.exe (size=20mb)

First of call calcolate the sum of all the sizes of the executable that the command points to:

TOTALSUM =30+40+10+20;

then create a new variable with a 0 value

CURRENTSUM = 0;

and after each command has been executed just sum to that variable the size of the last executed command

CURRENTSUM += LASTCOMMAND;

Then you will just need to make CURRENTSUM/TOTALSUM to find out the current percent of commands execution.

For example:

After command1 of application 1 has been executed the percent will be 30/100 = 30%

After command2 of application 1 has been executed the percent will be 70/100 = 70%

and so on.

Naturally you should make an if to find out if TOTALSUM = 0 before setting the percentbar value because in that case CURRENTSUM/TOTALSUM would cause a divide by zero exception.

[zorphnog]

Not a bad idea Francesco and it wouldn't be difficult to implement. However, the size of a file doesn't dictate how long it will take to execute. So I'm not sure if it would really be much different than what is already in place, as far as relaying the actual progress of the total install. I guess it wouldn't hurt though.

[mritter]

@Francesco: your idea has some merit, but not really necessary. If anything, get an actual of the number of command calls in all the configs (this one has 1, that one has 3, that has 2, etc....) and base it on that. Number of completed commands, not just number of completed entries. 6 of 1, half a dozen of another.......