SibTiger

@prathapml: RE: Monitor turn-off... you misunderstood what I meant by "one size fits all". With most registry tweaks, we don't need to export the setting to apply to other machines. But for changing the monitor turn-off time, I was advised to set it and export the registry key. I'll repeat my question: Is there a registry tweak that is easily changable for setting the monitor turn-off time to a set number of minutes? Or is the only method to take your favorite three settings and for each of them export 4 different registry keys with 30 character long hex codes? And if someone has the desire: Why did Microsoft need to make this registry setting so complicated and cryptic?!

So there is no "one size fits all" tweak for monitor-off timing? Why is that?

I still can't figure out how to reduce monitor turn off from 20 min to 10 min through a reg tweak. Anyone got the key?

Update to 61 now released.

Here's a little trick that is useful for unattended installs. (I know, you VBS pros will laugh at me for posting this. This is for other newbies like me.) Situation: Program takes 20 seconds to install on a new computer, and a minute and a half on an old one. Not desirable to use "Sleep." While installing, the window "MyProg Installation" only has "Cancel" button. When it's finished, the button "Finish" appears. The following code sends ALT-F every second as long as "MyProg Installation" window exists. Alt-F has no effect while the program is installing, but when it's finished, ALT-F closes the final window. Do while WshShell.AppActivate ("MyProg Installation") WshShell.SendKeys "%{F}" WScript.Sleep 1000 Loop

Ah, now I found it. I did a search of MSFN for "ShowDriveLettersFirst" and only came up with one obscure hit. That's why I didn't think it appeared anywhere. Perhaps you could change the description for this tweak in your master list. "Display drives in longhorn mode" is not very clear! I had seen that before, but didn't understand what it did. Also, the description for setting 4 "All drive letters shown" doesn't explain that the drive letters are moved in front of the description (which is the reason most people would use this tweak!) One more idea: would it also make sense to post the tweaks as text so this thread is "hit" in site searches? Thanks for the exhaustive list you've put together!

I thought I had every possible useful tweak imaginable, and then I found this one. Isn't it annoying how in "My Computer" the drive description comes before the drive letter? This tweak puts the drive letter in front where it belongs. ; Show drive letters first [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer] "ShowDriveLettersFirst"=dword:00000004 All options: 0 = Default display (drive letters after description) 1 = Network drive letters first, Local drive letters after 2 = Descriptions only, no drive letters displayed 4 = Drive letters before description

Thanks, Bulldog!!! Exactly what I was looking for. Total time for answer to be posted: 6 hrs. I love this forum.

Someone posted code for watching for a particular window before sending keys. This was a suggested alternative to using "sleep." Seems like a great idea, but I'm not seeing install VBS's that employ this method! Can someone with some coding experience post a sample? Let's suppose this scenario: Run setup.exe to install program: "MyProg" Window pops up with title: "MyProg Installation". Need ALT-N to continue. Window pops up with title: "MyProg File Associations". Need ALT-N to continue. Program installs. Final window title: "MyProg install complete" Need ALT-C to close. I learn by trial and error and by seeing examples. If anyone could post this, I would be very thankful!

@RyanVM, maybe instead of giving us fish, you could teach us to fish. Would it be hard to write up some instructions for integrating updates the way you do? I could help maintain a Russian version update pack if you tell me how! I like the idea of including links to the foreign language versions. That would be a huge help.

Here's noob question. How do you include long file names in the script "run" command? Here's what I want to do: WshShell.run "C:\Program Files\My Program\run this file.exe" (I know the 8.3 file name will run this, but is there a way to use the long file names?)

Newbie here... I install apps from a USB HD. I had to read through all 29 pages to discover that WIN51 needed to be in the application install source path on my HD so %CDROM% would be set correctly. It's counter intuitive to use %CDROM% when you're installing from a HD! Would this be logical: Stop using the variable %CDROM% and use %SRCROOT% instead. If WIN51 is found on a CD drive, that becomes the source root for installations. If it isn't found, %SRCROOT% should default to the directory from which WPI was started. Also include an option to manually set %SRCROOT% in config.js. Second "wish" *.bat or *.cmd files started with WPI use C:\ as the working directory. Is it possible to make the default directory the path where the .bat or .cmd file is located? Or perhaps add a switch for setting the "working directory" for a given command? Thanks for a great, visually attractive app! -SibTiger

I had 1.02FULL. I downloaded 1.03 Update (to save some bandwidth.) Will nLite integrate these properly if I point to both "hotfixes"? (Or do I have to download the FULL 1.03 for nLite to work properly?) I'm sure more will have this question as new versions (and updates to older versions) continue to be added!

@Mazin... your amazing! I successfully slipstreamed the update, and it installs perfectly on a VM. Now, a slightly off-topic problem. On my physical computer, I no longer can open ACD Photo Editor 3.1. When I try to open it, I get a brief "hourglass" mouse pointer, then nothing. I've uninstalled ACDSee, deleted all "ACD" references from the registry, deleted all ACDSee folders in "Documents and Settings" and then reinstalled. But the problem continues. The problem can't be with my install source because it works fine on the VM. Any idea how to fix this?

Just to follow up... my problem indeed arose because I attempted to slipstream the update into the MSI install. A clean MSI resolved my problem. Anyone know how to properly slipstream the "build 47" MSP update into the "build 43" MSI install?