MHz

Oh, you may need one of those. OEMPreInstall=YES depends on it to copy $OEM$ on to the %SYSTEMDRIVE% at text setup mode. Look here.

Thanks morland and peter, but I will add to the topic. To track changes in the registry, yes. These are technical tools so I hope not above your level of knowledge, morland. A good tool is RegShot. Click the green button here to download RegShot. Now I am not sure if it still exists but a Russian developer did his version of RegShot and it has more to offer but russian language etc. on webpage so is hard to find. These tools can export a difference file of registry changes. Numerous programs exist that can record registry differences but may have a cost. Another that may help is from Nirsoft. Nirsoft has many good portable utilities including RegFromApp and MyUninstaller. The 1st I have not used but it sounds of interest for your query. The 2nd is a informative uninstaller and it does have export capabilities (as with many of the NirSoft apps). If you just want a registry cleaner, then try CCleaner. It has been safe to use so far with registry entries that I have observed to this day. Get the slim version here (no toolbar)

Hi Geej, Sure, it is an extended style that is passed to GUICreate(). All the info is on the help page of GUICreate(). The items of interest are: and a little further down the page: So for the example above, add this to the top of the script: #include <WindowsConstants.au3> and replace this line: GUICreate('Enter your registration key', 350, 80) with: GUICreate('Enter your registration key', 350, 80, Default, Default, Default, $WS_EX_TOPMOST) @cyber77 I have noticed a mirror of your question at the AutoIt forum here. It appears you have a reply that seems like a solution. I do not want to double the effort if you have the solution already. BTW with your titling of the topic, it is "AutoIt" as one word, not "Auto It".

To get the text from a standard messagebox, type Ctrl + C to copy to clipboard. Open a text editor and type Ctrl + V to paste the contents of the clipboard into the text editor.

I have no idea what your issue is as I see no issue in front of me to correct. Generated au3recoder scripts are not easy to correct so I suggest you hand make an install script or try and use autoitmacrogenerator which will use control functions like for example ControlClick().

Those switches look like msiexec switches. The switches of msiexec can be accessed by typing msiexec /? into a run box or a command prompt window and press enter. A window will show up with the switches available for use. Although you may have no use for Start /Wait mentioned, you may need to run %comspec% alias CMD.exe (the command interpreter) to use Start /Wait. Example CMD /c start /wait path/to/app

Here is an example of entering a serial key into a registration window. The GUI code is just for the example to receive the data sent so the only code of your interest is from the WinWait() function to the Exit keyword. The comments should help you understand as you stated you know the basics of making aa AutoIt3 script. _Show_Example_Registration_Window() ; wait for the window to appear WinWait('Enter your registration key') ; this is an array of 6 elements ($key[6]) ; the 1st element ([5,) in this example is used as a element count of the serial values ; the other 5 elements contain the serial Global $key[6] = [5, 'abcd', 'efgh', 'ijkl', 'mnop', 'qrst'] ; this loops 5 times and the value of $i will step from 1 to 5 (i.e 1,2,3,4,5) ; $key[0] returns the value of the 1st element which is 5 For $i = 1 To $key[0] ; this sends the X element of the array to EditX where X is the value of $i ControlSetText('Enter your registration key', '', 'Edit' & $i, $key[$i]) Next ; optional sleep just to show what has been achieved Sleep(3000) ; click the next button to proceed ControlClick('Enter your registration key', '', '&Next') Exit ; these functions are just for this example and not intended for other use Func _Show_Example_Registration_Window() Opt('GuiOnEventMode', True) GUICreate('Enter your registration key', 350, 80) GUICtrlCreateInput('', 50, 20, 45) GUICtrlCreateInput('', 100, 20, 45) GUICtrlCreateInput('', 150, 20, 45) GUICtrlCreateInput('', 200, 20, 45) GUICtrlCreateInput('', 250, 20, 45) GUICtrlCreateButton('&Next', 300, 45) GUICtrlSetOnEvent(Default, '_Next') GUISetState() EndFunc Func _Next() GUIDelete() EndFunc

An ordered response to your list of questions. The Task window displays after installation but before finishing. The banner (top graphic) can display a custom message like: "Support Us". Try making one with GIMP. Idea: Edit a copy of the default banner located in the Inno Setup installation directory. The Task window can show checkbox(es) Example Inno Setup script below: [Setup] ; basic safe options for test AppName=A_Test_Of_My_Appname AppVerName=A_Test_Of_My_Appname 1.0 CreateAppDir=false [Registry] ; this next item depends on the condition of the checkbox assigned to the task "task_name" Root: HKCU; SubKey: Software\a_test_key; ValueType: string; ValueName: key-value; ValueData: data-value; Flags: uninsdeletekeyifempty uninsdeletevalue; Tasks: task_name [Tasks] ; assign a task named "task_name" Name: task_name; Description: "Create a test registry key at ""HKCU\Software\a_test_key"""; Flags: unchecked Seems nice for a NSIS setup. ISTool is a good GUI to use for Inno Setup scripts which may help you.

I will take the "i don't know what to do" as flawed logic in your script and explanation. Thus we can only guess at what you may need? I am going to go with that statement but use Else after Exit. It seems more logical to me considering that the Appdata <program> settings folder should be removed at the start of installation if it is a requirement. ; get the install path from registry $PreviousInstallation = RegRead("HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\Registry Mechanic_is1", "InstallLocation") If StringRight($PreviousInstallation, 1) = '\' Then $PreviousInstallation = StringTrimRight($PreviousInstallation, 1) EndIf ; check if installed If $PreviousInstallation <> "" And FileExists($PreviousInstallation & "\RegMech.exe") Then ; show message and then Exit script as already installed MsgBox(0x40010, "Registry Mechanic 9", "Please uninstall previous version of Registry Mechanic before install the progarm..") Exit 1 Else ; remove old settings (and start installation below) DirRemove(@AppdataDir & "\Registry Mechanic 9", 1) EndIf ; start installation @sahra Attempt to comment your code and it may help you to interpret the logic of your script. It may help others also.

In your AutoIt3 help file, you should have a page for History and another link from that page for Script Breaking Changes in Recent Versions. As of 15th January, 2010 - AutoIt3 v3.3.4.0: AdlibEnable() is now AdlibRegister(). AdlibDisable() is now AdlibUnRegister(). AdlibEnable() and AdlibDisable() allowed for only one function to be registered and unregistered at a time. AdlibRegister() and AdlibUnRegister() can allow multiple functions to be registered and unregistered at the same time. The Adlib* function rename was to suit the change in behavior. Use search and replace in your editor to change the following: AdlibEnable to AdlibRegister. AdlibDisable to AdlibUnRegister. Please read the History page in the AutoIt3 help file to keep up to date with any changes.

Odd. Perhaps passing just "install.log" with my attempt may help but I would expect UnWise.exe to imply "install.log" by default. Try these attempts then ; try full path $path_MyShampoo = @ProgramFilesDir & '\MyAshampoo' RunWait('"' & $path_MyShampoo & '\UNWISE.exe" /S "' & $path_MyShampoo & '\install.log"') Notice the single/double quoting used above. ; try 8.3 path $path_MyShampoo = FileGetShortName(@ProgramFilesDir & '\MyAshampoo') RunWait('"' & $path_MyShampoo & '\UNWISE.exe" /S ' & $path_MyShampoo & '\install.log') @iamtheky I hope that I am not being overly intrusive.

Perhaps sahra will also gain some knowledge from your similar question. I usually give an answer as good as the question as I may not know how to respond in a correct manner if the question is not well explained of the issue. Learn by example: (Note: The example is not a working example as the FileInstall() parameters are invalid filenames. The example would need valid filenames to work correct and the same for the previous example I posted above). ; UAC Prompt if this script is executed without admin rights. Use this ; directive if setup.exe depends on admin rights to install correct. #RequireAdmin ; Store the extraction path into a variable named $path_setup. $path_setup = @TempDir & '\extract_folder_name' ; The code inside the _Extract() function will execute and will return ; a True value if the extraction path was created. If _Extract($path_setup) Then ; Run the setup.exe file within the extraction folder ; and use @TempDir as a valid working directory. ; Note: I used a silent install switch (presume /S) for this example. RunWait('"' & $path_setup & '\setup.exe" /S', @TempDir) ; Remove the extraction path to finish task DirRemove($path_setup, 1) EndIf Exit Func _Extract($path) ; Create a valid folder path to FileInstall() the setup files. If DirCreate($path) Then ; FileInstall() the setup files to the extraction path. ; Note: Change the first parmeters to match your setup files names. ; Note: Add or remove FileInstall() lines as needed. FileInstall('setup.exe', $path & '\', 1) FileInstall('file2', $path & '\', 1) FileInstall('file3', $path & '\', 1) FileInstall('file4', $path & '\', 1) FileInstall('file5', $path & '\', 1) FileInstall('file6', $path & '\', 1) FileInstall('file7', $path & '\', 1) ; Return True value if above condition (DirCreate()) is successful. Return True EndIf ; Return False value if above condition (DirCreate()) fails. Return False EndFunc #cs ; Script summary The $path_setup variable is assigned the string value of the path to extract the setup files to. The _Extract() function will then execute the code within it with the $path variable parameter passed to it. The $path parameter has the value of the extraction path. The _Extract() function will return True on successful creation of the extraction path. If the _Extract() function returns True then the RunWait() function will run the path to the setup.exe. The @TempDir working directory parameter used in the RunWait() function helps to ensure a suitable working directory is initially set. The DirRemove() function will then recursefully remove the extraction path previously created by the script. #ce Hopefully enough comments have been added to the script to help with understanding. It is an example to learn from. The example may help with some ideas to assist you. cluberti offers some good advice of looking at the AutoIt3 documentation to help you learn. Thanks for the reminder as I left out the DirCreate() in my first example above which would make FileInstall() fail with a invalid path to extract to.

Unwise.exe usually uses the install.log in the current working directory so I would pass the working directory of install.log to Unwise.exe like shown below. RunWait('"' & @ProgramFilesDir & '\MyAshampoo\UNWISE.exe" /S', @ProgramFilesDir & '\MyAshampoo') You may find older versions of Unwise.exe (as some devs may still use an older version of WISE to make their installers) may not accept a command line argument of the install.log path unless it is in 8.3 filename format thus the above example will avoid the issue.

FileInstall() may suit your need to store the setup.exe within your compiled executable. Example below: ; fileinstall will extract to this path $tempdir = @TempDir & '\MySetup' If FileInstall('setup.exe', $tempdir, 1) Then $pid = Run('"' & $tempdir & '\setup.exe"') ; perhaps some more code here ; wait for window to appear WinWait('Setup Window Title') ; write your name into setup ControlSetText('Setup Window Title', '', 'Edit1', 'My Name') ; perhaps some more code here ; wait for process to finish (added timeout) ProcessWaitClose($pid, 60) ; cleanup DirRemove($tempdir, 1) EndIf Compile with setup.exe in same directory as the au3 script.

64 bit is not supported with the CMenu context menu extension AFAIK. SendToA3X may work fine on 64 bit as a 32 bit executable alone may function OK, though I have not tested myself.

Duplicate Cleaner has many features including hardlink support which I find useful.

Hi iamtheky, I tested your script by changing _FindCD() to search for autorun.inf on a CD for my convenience. I also added a small message loop to get the signal from a button press and show a msgbox with some details. I do not see an issue with button operation using my added message loop. (The variable $drvs should be made Local to _FindCD() as well just in case the variable is used Globally by mistake.) This is the change to the _FindCD() I changed $CD1 = _FindCD("autorun.inf", 0) and this is the message loop that I added to the bottom of your script. Button "12.05 WS" is tested. Do $msg = GUIGetMsg() If $msg = $btnSamsE1205 Then; 12.05 WS button signal MsgBox(0, @ScriptName, _ 'I am "' & @ScriptName & '"' & @CRLF & _ 'I am located in "' & @ScriptDir & '"' & @CRLF & _ 'My working directory is "' & @WorkingDir & '"' & @CRLF & _ 'The full path to me is "' & @ScriptFullPath & '"' & @CRLF & _ 'The drive that I am in is "' & StringLeft(@ScriptDir, 2) & '"' & @CRLF & @CRLF & _ 'The value of $CD1 is "' & $CD1 & '"' _ , 0, $Form1_1 _ ) EndIf Until $msg = -3; window close signal I noticed that your script searches for "STAMIS_Rollup.exe" and the title of the GUI is "STAMIS Rollup". If the script resides on the CD that you want to access and the file structure to access is on the CD then you can just use the @Script* macros to complete the full paths around the file structure on the CD or just use relative paths from the location of your script. If you are going to open a text file then you could build the full path by using @ScriptDir as shown below. ShellExecute(@ScriptDir & '\readme.txt') If the script file is one directory level up then you can do this by using "..". ShellExecute(@ScriptDir & '\..\readme.txt') To use relative paths, ensure the script has a known working directory such as @ScriptDir. To set the working directory is done with FileChangeDir() as shown below. If @WorkingDir <> @ScriptDir Then FileChangeDir(@ScriptDir) EndIf Comparing @WorkingDir to @ScriptDir is optional as you could just use FileChangeDir(@ScriptDir) only. These are just simple examples. You could do use FileChangeDir() at the top of your script to set the working directory for the rest of your script to use. With the working directory set, then you can use relative paths from your script directory as shown below. ShellExecute('readme.txt') If the script file is one directory level up then you can do this by using "..". ShellExecute('..\readme.txt') Hopefully enough information for you to decide on possibly fixing/improving your script.

You are using "Linear+" display mode. To change display mode, look at the top of you post and select the "Options" button and select either "Outline", "Standard" or "Linear+" from the drop down list of items. You probably had "Standard" display mode previously.

Welcome to the MSFN forums. Opt() supports the settings to change the interpreters behavior and the method that you use is incorrect. Instead use Send(), ControlClick() or ControlCommand() to act with the radio button. You may need to debug to know what is the issue and I would advise that you add the line below at the top of your script. Opt("TrayIconDebug", 1) Now you can hover the mouse cursor over the AutoIt icon in the system tray next to the clock while the script is running. When the script seems to have failed/stalled, then you can see a tray tip window which shows the line of code that the script is at. If it stalled at the line with WinWaitActive(), then you may have a bad parameter text or perhaps inactive window. If the window fails to activate on it's own, then you can make it activate bu using WinWait() to wait for the window, then WinActivate to force the window to activate, and then use WinWaitActive() to wait for the window to become active. For ease, Control*() functions do not normally require active windows to interact with so using only WinWait() prior to Control*() is usually sufficient. SAV may support silent install switches and I would suggest searching for those for your convenience.

Googles Chrome is the browser interface that uses the Webkit rendering engine. I would suspect the concept of the I.E. plugin is to use the I.E. interface with the Webkit rendering engine. Webkit (rendering engine) is open source and was forked from the KHTML rendering engine by Apple so ownership by Google of Webkit is not accurate. Google is merely an active contributer and user of Webkit along with Apple, KDE, Nokia, Google, RIM, Palm and others as mentioned on the Webkit Wiki page. Perhaps you should be judging Webkit rather then judging Google because though Webkit may help with Googles Wave and anything else is based on the evidence that Webkit supports HTML5 and prior HTML standards extremely well. Other notable browsers that use Webkit are Android (Linux based), Safari (Windows/MacOSX based), Epiphany (Linux based) and others listed here. Acid tests are available on the Acid Wiki page for the good results of Webkit based browsers. I am failing to see down side to Webkit. The responses from Microsoft appear hyped possibly because Microsoft want to keep control with closed proprietary extensions (think of ActiveX and other objects). The responses from Mozilla appear hyped because maybe they want the Gecko rendering engine to be successful, though their reasons are differcult to know. One thing for certain is that competition is good to keep them all honest and the better choice will hopefully gain recognition.

Hi Alloro. Welcome to the forum. You command looks incorrect to me how you specify a folder path and then use start /wait following the folder path in the data parameter. The folder path may invoke explorer to open that folder path as a result. The start /wait are parameters which you normally pass to Comspec (the command interpreter). You also do not specify a path to openofficeorg30.msi to msiexec so msiexec may not find openofficeorg30.msi if it is not in the current working directory or in the systems path. Try this: REG ADD %KEY%\001 /V 1 /D "msiexec /qn /norestart /i %PP%\UTILITY\OPENOFFICE31\openofficeorg30.msi SELECT_WORD=1 SELECT_EXCEL=1 SELECT_POWERPOINT=1 ADDLOCAL=ALL REMOVE=gm_p_Math,gm_p_Impress,gm_p_Draw,gm_p_Base,gm_o_Quickstart,gm_o_Testtool" If %PP% has spaces in the path then you may need to add escaped double quotes to ensure the full path is passed. I have assumed that is not the case. I am not sure about the wizard first run disabling. Perhaps a value stored in registry sets it to run? The parameters you show are possibly used on running Open Office rather then installing it.

An example CMD script to show changing of an environmental variable which the program will normally inherit. setlocal set appdata=%userprofile%\desktop start notepad.exe endlocal rem Use save in notepad and save as %appdata%\test.txt rem You will then notice the file test.txt saved on your desktop rem Programs will normally inherit the environment passed to them rem Use admin privilages to start the script if needed

In the news, it is stated that researchers found the bug mentioned, Right? Linus' Law has been proved as correct as another set of eyeballs made yet another bug shallow (discovered and to be fixed). To invalidate the Linus' Law, you need to prove that undiscovered bugs exist and are not shallow. How can you make that absolute claim without checking the source code and finding the bugs, and if found, then you are just confirming the law as valid with your own eyeballs.

The same window being checked for makes me consider using AdlibEnable() to constantly check and act as needed if the window is found. Some If conditions are in the function but Else conditions are not needed that you requested. ; execute the _adlib_check() function every second to check for the window adlibenable ("_adlib_check", 1000) run ("d:\Tier1\Hotfix\KB933854.exe /quiet /norestart") sleep (15000) run ("d:\Tier1\Hotfix\KB944653.exe /quiet /norestart") sleep (15000) run ("d:\Tier1\Hotfix\KB956572.exe /quiet /norestart") sleep (15000) run ("d:\Tier1\Hotfix\KB956803.exe /quiet /norestart") sleep (15000) adlibdisable () exit func _adlib_check() local $wintitle = "Microsoft Certificate Services" ; activate the window if it exists if winexists ($wintitle) and not winactive ($wintitle) then winactivate ($wintitle) sleep (500) endif ; send enter if the window is active if winactive ($wintitle) then send ("{enter}") sleep (1000) endif endfunc Hopefully no syntax errors as I am unable to check them with au3check atm.

Here is a test example of using Else. Tested with Windows XP. @echo off title Hello color b REM Greeting code section echo Script: Hello set /p Hello="User: " if "%Hello%"=="Hello" ( call :sub_2 %Hello% ) else if "%Hello%"=="Hi" ( call :sub_2 %Hello% ) else ( set Hello=Hello echo Script: Incorrect greeting received. ) set Hello= REM Feeling code section echo Script: How are you feeling? set /p Hello="User: " if "%Hello%"=="Fine" ( call :sub_4 %Hello% ) else if "%Hello%"=="Good" ( call :sub_4 %Hello% ) else if "%Hello%"=="Great" ( call :sub_4 %Hello% ) else if "%Hello%"=="Cool" ( call :sub_4 %Hello% ) else if "%Hello%"=="Bad" ( call :sub_4 %Hello% ) else if "%Hello%"=="Cold" ( call :sub_4 %Hello% ) else if "%Hello%"=="Hot" ( call :sub_4 %Hello% ) else if "%Hello%"=="Weird" ( call :sub_4 %Hello% ) else if "%Hello%"=="I dunno you tell me" ( call :sub_4 %Hello% ) else ( echo Script: Feeling is not registered. ) set Hello= REM User name code section echo Script: What is your name? set /p Hello="User: " if "%Hello%"=="" ( echo Script: Invalid Name!!! ) else ( call :sub_5 %Hello% ) set Hello= pause exit REM Subroutine code section :sub_2 echo Script: Thankyou for typing %1 goto :eof :sub_4 echo Script: Oh so you're feeling %Hello%. goto :eof :sub_5 title Hello %1! echo Script: Hi, %1! My name is Command Prompt pause echo. echo Script: Bye %1! goto :eof Note: Excess echos removed for this test. Using Call (using labels) as a subroutine execution then returning to called line is IMO easier to trace then using Goto a label. Ask if you need help understanding any part of the test script though it would be nice for you to try and figure it out yourself.