mritter

It looks like you are modifying IE. Try an install without that last entry and see if it still causes an error.

Added the above variables. Thus creating new function {JSCRIPT}=removeEnvVar(Variable) They are removed when WPI exits.

And how do you suppose that would be done, Kel? Actually, yes, it could very easily be done. Consider it done. Just to ask: should it be an option or just do them all? (%root%, %wpipath%, etc.). Or just certain ones? hdd, cddrv, root, wpipath, oslang, oslocale, would be the whole list. Delete them when WPI exits?

Do a search on the forum for the reg key issue.

I moved them because you could have multiple config.js files, but you are then limited to one options file (unless specify a different one). By moving those options each config file will be 100% independant of the options file. This will also bear more importance with the next version.

Like I said before: if you specify the entire path to mshta it will use the 32/64 bit version accordingly. start "" /wait "%windir%\system32\mshta.exe" "%wpipath%\WPI\WPI.hta"

Actually, it is a problem........right now. I am already working on a major update to the Config wizard that will take me a little time. Don't "waste" your time doing anything yet; the code will be changed quite a bit. I'm not against your ideas, but we need to coordinate what is done. Give me a few weeks and we will talk about this in emails. I am looking to make a HUGE release for next version, so it COULD be part of it.

If that is the exact text from the log file, then you didn't put a space after {MAKEDIR}. It works fine for me.

My first guess is you took IE out with nLite. Or some compenent of it. ActiveX is needed for file operations. Post your log file.

There is an AND function. All the operators are in the manual. getOSver()=="Win7" && getbits()==32 (getOSver()=="Win7" || getOSver()=="Vista") && getbits()==64 You will want the second example.

If you are using 7.6.0 that is no longer an issue. The Office check is now not done by default. Make sure "Load desktop before installation starts" is not checked. Updated in 7.7.0. Look at my cmd files in the main post for more ideas on starting WPI.

Francesco, Look at this thread, 64bit has been covered already. Also, if you specify the complete path to mshta in your cmd scripts when starting WPI, it will run the appropriate 32 or 64bit mshta. start "" /wait "%windir%\system32\mshta.exe" "%wpipath%\WPI\WPI.hta" As far as an uninstaller, I see your point in wanting it, but could be really hard to work out. Like, what if the uninstaller wants to reboot before new version could be installed? You would have to know that ahead of time. Lots of little things need to be accounted for. Will take some serious thought and planning.

You are welcome! I already have v7.7.0 going strong. Will be out in a few weeks or so.

From a quick Google search, the strings must be NULL terminated and double NULL terminated at the end. Don't put quotes around numbers.

I am looking to start some packages that can be downloaded and added to your WPI directory quickly and easily. Tool tip images Custom set up and clean up scripts Sound samples Themes Please post/upload them here or email them to me. I will then make packages that anyone can download and customize their WPI with.

Francesco came up with an idea for a new option: Reboot before installation starts. I like it, but thought some more about it: is it necessary? I don't have a current XP/Vista disc with WPI on it. So I am drawing a blank: When XP and Vista finish installing don't they reboot anyway before WPI is started? Or do they finish, close, WPI runs, desktop loaded? Francesco: Explain in detail how you want to use it.

The one I have is like that; nowhere near as complete.....next version maybe.

I am debating on adding a web style text editor for the description. It will have basic html buttons like here on MSFN. It will help eliminate errors like above from happening. I just to find a better one than I have.

@cloferba: The picture path can now be anything. If no path is specified, as all images are now, it will be assumed the Graphics folder. Else, whatever path you choose. Note to everyone: For some reason PNG images gets their dimensions read and updated every time. Other formats don't always work the first time. It is not WPI's fault, it's the JavaScript new Image() function.

I have thought about converting to XML, dropped that, now still thinking about JSON. But, it will be a major update to either.

Francesco: Yes, please email the program. Then we can talk in email so this topic doesn't drag on here on the forum. We will tweak it via email.

@Cloferba: The images have always been in the Graphics folder from the day the tooltips were first introduced. I am not a big fan of that, either. I will look into making it possible for any location.

Francesco: You probably have seen the previous posts about this. Checking is the desktop is already loaded via JavaScript is next to impossible. And this option was never meant to be used the way you are using/wanting it. It's meant to be used from DVD after Windows finishes installing and WPI is started, items picked, hit Install, desktop loads, then WPI installs apps. It is not meant to be used from the desktop. Correct, getDesktopLoaded() is not working. I can't find a 100% "flag" to check. If you can provide and app that can do an accurate desktop loaded check, then yes, please send it over. Let me do some thinking on your other ideas. I do like the Reboot before install starts. The main reason to load the desktop first is for registry tweaks. The user's account/desktop must be up for most to take affect.

@freeAppz: Thanks. Fixed.

Huh......don't know how I missed that. I have it now.