mritter

Still in the works. Right in the middle of a "major" update for the commands. Hit a small snag. 7.2.0 will be released November 28th. With a parade, fireworks, super-models, hotdogs, beer. The whole works!

Themes and user options won't be affected, but your config will be. The first time running v7.2.0, WPI will detect the old config file, offer to convert it (also recommend that you back it up), then continue as usual. Themes will work as is, even though I have made some simple cosmetic changes that are optional. If you want them, just use the latest theme folder, else, keep yours as is. User options and config MIGHT get a major modernization update, but not sure just yet. Even then it will probably have a self-updating feature.

After some testing, it has to do with MSO07STD. Change the Vista to XP check and it works fine.

Relax....some of us have to work. FILECOPY c:\folder\file.ext w:\folder Don't put parenthesis' around the names and no comma. Just like you would do in a command line prompt.

It's not just IE6 that does it; IE7 does, also. Just not as often. I have fixed this in 7.2.0.....I hope. Works every time on my home computer, will test on some others at work.

If your 2 files are in WPIScripts, then they should work fine. If not, then you need to specify entire path: wpi.hta options=c:\test\useroptions_xp.js or even wpi.hta options=c:\wpi\useroptions_xp.js if in wpi's roor folder. Use quotes if have a space in the path!

Let me know if the version I sent you fixes this problem.

Nothing that would prevent just a program from being installed. No one else has said anything like your problem. In 7.2.0 I have added a FileExists() check when comes back failed. The undefined code tells me nothing. 0 for success, undefined for all errors. I will PM you some details.

I made it so the options and config files are remembered. This will only work when run from desktop, not from dvd.

When first go to Config Wizard, WPI runs USSF in the background to flush out that "first run problem" before you get the chance to use it on any command lines. johnhc has done some testing and believes it has fixed the problem.

getOSver()=="2K" || getOSver()=="XP" Don't forget the parenthesis'.

I have been updating the Config Wizard quite a bit recently. You will be pleasantly surprised by the next release. What I have come across is: config.js is always used, unless you specify a command line arg. Fine. But, if you go into Config Wizard, load a different config file, Exit back to main, it loads config.js again, not the file you just chose. I made it so that WPI remembers what you chose in Config Wizard. But when you totally quit WPI, it reverts back to config.js. I can make it not do that. What do you want it to do? Always default to config.js (unless changed with command line arg), or stay with the last file you opened in Config Wizard? Same for the Options Wizard.

Fixed the bugs not putting the path in the box for a new/blank config, the saving problems, and a few other issues that came about because of those problems.

When a condition, such as ConnectedToInternet(), is a true/false check, then don't do it like Kels said; do it like I posted. ConnectedToInternet() - if there is a connecton, item is grayed. !ConnectedToInternet() - if there is no connection, item is grayed. This is the more common one. Now, when checking a name of something, like OS, then yes, do a check. getOSver()=="XP" - if is on XP Windows then grayed. getOSver != "Vista" - if not on a Vista Window then not grayed.

It may be becuase of this: http://www.msfn.org/board/USSF-false-virus...ng-t124912.html

AVG and ESET, and probably other virus scanners, are now complaining that USSF is/has a virus. IT DOES NOT! I recompiled it without UPX compression and the problem has gone away. Download new USSF here

That %cdrom%\ bug has been cleaned up. It will now work either way: %cdrom%Install -or- %cdrom%\Install. It was a lingering path quirk like mentioned above. It never should have been allowed to be that way when the code was first written. Same goes for %root%. Let me know if any other path variable works like that.

ConnectedToInternet() -or- !ConnectedToInternet() Returns true or false. No, can't do deps/conds n Reg B/A. They will be eliminated in a near future release. But they will be converted over properly so don't worry about future compatibility.

The latest AVG and ESET virus defintions think USSF is/has a virus. It does not. I recompiled it and did not use UPX compression. How you got a newer version is beyond me. First off: you need to make your install list BEFORE you make an ISO. USSF does not recognize .rar or .zip files as installers. /S is not global. You seem to be doing everything backwards. Don't use nLite to make an ISO. Use another program, Nero or CdBurnerXP, to make the final ISO. You need to do some research on custom windows installations.

When are you not seeing the path? Are you running WPI from desktop or a cd/dvd? What you are saying makes no sense at all. The path will always be there, default or other. Obviously something is being loaded, so the path should be set. I need more CLEAR details.

That was a bug that snuck through in the last release. I have already fixed it. Sorry.

Problem is fixed. It never did do the path check (%wpipath%, %root%, etc). It does now and sets quotes properly.

Huh.....strange. I will get it fixed Wed. The entire process of %wpipath% and such and selecting files needs to re-worked. Especially for a network share. That can be worked around with Options -> General -> Default install path -> Custom...

I answered my own question: the output window is necessary. No change can be made..............yet. I still have ideas up my sleeves for DOS commands....... ;-)

Francesco, What do you have set for the Main Window resolution? If you have a size chosen, it will not maximize, it will be that size. If you use By System Default, then things should be "normal".