MHz

This example may suit you. If Not Exist "not_here.exe" ( "msiexec.exe" ) or do it on one line If Not Exist "not_here.exe" "msiexec.exe" So if firefox.exe does not exist, then run the installation.

Agreed that doubt has been removed for you. I did a similar test long ago to remove doubt so I could make good use of the run points of execution. I certainly acknowledge your results as tabled. As you may have noticed with your testing is that the 1st 3 keys will in synchronous operation, 1 after the other while the system does wait in loading the desktop. These are keys you would use if you want to install something before desktop but in knowledge that only 1 install can take place at any given time. Both of the Run keys are for permanent entries that execute programs and some drivers...so have little benefit for installations in general. The startup folders are synchronous in operation which means thier startup time depends on the time that the desktop loads. Again little good use for installations but merely an easy method for a desktop user to quickly add a shortcut to start their favorite program at startup or whatever pleases. As you mention mazin about HKCU\...\RunOnce, this key is amazingly the last opportunity and as the system continues to finish loading so this key does give good use of a script to do your UA misc. tasks like shortcut cleanup, file and folder removal, window handling (using AutoIt)...and finally shutdown\reboot operation. I add a script into this key at T-12 which inserts it into the default user at the time. This means every account logged in the 1st time will run that key once and every new account will also. Your script should reside on the HDD so it is available for every account and future accounts. Adding a "z" to the start of the entry name can help it to be the very last entry to run. Hope my experiences and insight helps and thanks for sharing yours.

If you would like some help, then providing some information could give us an idea as to your problem. Script, Installer, Software deployment method...or any suitable information. Thanks

Oh really. Is the ref.chm incorrect with the key where GRO launches from then? HKLM\...\RunOnceEx (ROE) waits for executions to finish, then HKLM\...\RunOnce starts and waits for executions, then HKLM\...\Run starts it's executions, then the desktop loads with the start of HKCU\...\RunOnce (GRO) executions along with the startup folders.

Welcome, I'm not sure if your "requirement" is a portable application?. Using Inno Setup could be a better idea to use then a SFX. An installer is like a SFX, but has all the extra options that you may want. You can get Inno Setup at this link: http://www.jrsoftware.org/isinfo.php And ISTool a link which is a friendly Gui frontend for Inno Setup: http://www.istool.org/default.aspx/

Please download the latest AutoIt3 installer released. AutoIt version 3.2.0.1 is the latest that will support the syntax used. I'm sure that error will not happen when 3.2.0.1 is used as the previous version of AutoIt3 did not support the keyword Default. http://www.autoitscript.com/autoit3/

The Left Shift trick I use often. To make good use of it to hide least used context menu entries, look at the example reg file. Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\*\shell\Bulk Rename Here] "extended"="" As you can see, it is one of those programs that want to be shown in your context menu all the time, so rather then remove the entry, I add the "Extended" value which causes the entry to hide in the context menu unless I have the Left Shift key pressed while right clicking the target which then does shows the entry.

Amusing, but true. You can go to one of those sites that checks against all popular AV's (around 12 of them). And most, if not all of them will show false positves. Personally, I thnk they must do some act like sharing\selling false positives to each other to get a common result of getting it wrong. Anything that you or I use in everyday life (sfx's, cmdow, autoit3...............) is also used by virus makers, so AV companies most of the time cannot positively tell the difference between an evil virus or a file that you safely created yourself. If I had my way, I would not use an AV, but my OS would be infected as soon as connected to the internet.

Uniextract is a compiled AutoIt script. Antivirus companies in general are constantly creating false positives to AutoIt executables as they share common code (the interpreter). Submit the file to Avast so they can clear the definitions of the false positive. @cihatkarli As for the mention that "Avast sux", it absolutely does not. As being a major user of AutoIt3 and member or the AutoIt forum who constantly visits, It is other antivirus programs that do the false positives most of the time with AutoIt compiled scripts. Avast is very rarely mentioned for false positives. The facts speak for themselves so opinions mean nothing without a shred of evidence to suppot it.

Have you looked in the helpfile? I'm sure I have added enough information within it to help the user. I have looked into the installer and it is deceptive to get the correct ContolID's for the buttons, but I did get them. If it came to being too differcult to find for you, then the controls text could be used as the ControlID. This is the script code I finished with. _irfanex_v102.html

Extracted contents of the installer I downloaded and do have a gt.exe (Google Toolbar installer). %UNINSTALL_PATH% added.wav all_done.wav default1.GIF done.wav error.wav fgiebar.dll flashget.chm flashget.exe flashget.exe.manife gt.exe gtapi.dll ImageBk.ini jcbul.ini jccat.ini Jccatch.dll jcchs.ini jccht.ini jccze.ini jcdax.ini jcdeu.ini jcell.ini jceng.ini jcesp.ini jcfin.ini jcfra.ini jcheb.ini jchun.ini jcita.ini jcjpn.ini jckor.ini jclat.ini jcltu.ini jcnld.ini jcnor.ini jcpls.ini jcpob.ini jcptp.ini jcrom.ini jcrus.ini jcslo.ini jcsrl.ini jcsvk.ini jcswe.ini jcthi.ini jctur.ini jcukr.ini jc_all.htm jc_link.htm Leftback.jpg License.txt logo_bg.gif mirrors.lst mymirror.lst Normal.ini Normal.jcs Readme.txt Sky(Gradient).ini Table.jcs TestBk.jpg unreg.inf whatsnew.txt XP_Luna(Gradient).i XP_Luna.ini The Flashget.exe is 1.7.2.0 in the resources, version 1.7.2.128 in the about window so the later matches the version recommended on their download page.

muiz, Simple question, as presetup runs the command before extraction, where is the registry file to run it? Edit: Rephased question.

This topic is going like a dog chasing it's tail, but I will say this. On the FlashGet site, they mention to explicity use the new build 138 (I'm not a FlashGet user, so get me biased here). That is a minor version change, so is still v1.72 with bug fixes. Now, strange thing is that I just downloaded with a fresh browser cache, a version 1.0.0.0 but the additional properties has v1.7.2.0. This is totally wrong build number and is...well, you figure it out. Edit: More clarification

Wraith, You can only put warning on your product. Those who choose to use component stripping software like nLite to remove vital elements, choose thier own path and thus choose to be void of general support. If atleast the requirements are not met, then why should you lose sleep over it. I prefer and recommend a full OS, as being involved in the programming arena makes me frown over what happens. But what can one do? People make thier owns choices and need to deal with the results of doing so. Sleep well.

@Daedlus Your relative addressing can fail as you show that you do not check the working directory and change it if needed. To ensure you concept will indeed work, check as the example below shows before using it. If @WorkingDir <> @ScriptDir Then FileChangeDir(@ScriptDir) EndIf Changing Working Directory within a script is a powerful thing to use, so I praise it's good use, but the script should always know it before relative use. @oneless Your in the system32 folder? Using a macro is a good idea also, though using @ScriptDir maybe better to use. @Pete I thought we covered this in the other topic? If your script is in the same directory as for example "RegCleaner.exe", then just do Like Daedlus shows, but check Working Directory first If @WorkingDir <> @ScriptDir Then FileChangeDir(@ScriptDir) EndIf Run("RegCleaner.exe") Or as oneless is refering to as in using an absolute address with a macro Run(@ScriptDir & "\RegCleaner.exe") Else, if you want to expand environmental variables in your string, then like this Opt('ExpandEnvStrings', 1) Run("%systemdrive%\install\Applications\RegCleaner.exe") The top 2 methods are considered better IMHO, as you are not hardcoding the path. You can also expand variables or even use EnvGet() for getting envronmental variables, but you already have good choice to select from to get it right.

In the comment, for example: Setup=regedit.exe /s regtweaks.reg Setup=application.exe Using the WinRar Gui, you should see the comment on the last tab when creating an SFX.

I did notice an uninstall issue with 2.5. It is corrected hopefully in v2.6. Working fine for me. The dll cannot be unloaded and removed unless explorer is restarted, but that should be fine for a reinstall as the dll is always same version. CMenu.exe is set to run for a further 10 seconds to monitor for issues after you open the editor, so if you uninstall after using the editor and during that 10 seconds then you may get an in use issue with replacing CMenu.exe. Simply checking task manager and killing CMenu.exe if you do notice an issue may save the reboot. Other then that, I am unaware of further issues that can happen that you may have. I would consider the error you may have seen was generated by code in CMenu as a warning. The installation is handled internally, so the need for an external application is not used for the install routine. It would be a major change within the code to allow an external use of Inno Setup, but maybe in future I maybe able to change the current setup.

Would you be able to show your RunOnceEx that shows it as entering this information for the script.exe's. Also show me the Run() functions used in the Au3 scripts.

Finally found some spare time to release an update. Please see 1st post for information and download details for v2.6.

WinRar supports more than 1 "Run after extraction" command. Add further commands in the comment.

I do not understand you method os software deployment i.e. RunOnceEx, GuiRunOnce... and when you are deploying the software. I do not know where your AutoIt scripts are i.e. perhaps in $OEM$ folder somewhere? If your scripts are in the same directory as the installers, are you using @ScriptDir to path to the files? For all I know, it could be that you are hardcoding the paths? But a wild guess as I have not enough information to help you .

You run script.exe and then script.exe will run the installer.exe. Your Au3 script may have for example Run(@ScriptDir & '\installer.exe') So the script.exe will run installer.exe within the same directory. Only need to run script.exe from your cmd file.

Yurek3, That RunOnceEx.cmd only executes WPI.exe. Your problem is after WPI selection is complete and how the installations are handled. The installations are perhaps executed directly from WPI and the config files or are using the registry. The WPI forum may have some idea of method of operation used.

Perhaps my FindCD() UDF here may help you with the message box warnings.

1. Try using the /sms switch to alert the installer to wait while the spawned process runs. 2. Try manually doing the recording and see how it goes.