Jump to content

kornboy82

Member
  • Posts

    10
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    Canada

About kornboy82

kornboy82's Achievements

0

Reputation

  1. Now I just want to ask something. I work as a computer tech for 52 first school. The secretary of each schools once used an application that was connected to a server named CAPEDPRG. Now they don't use this software again. The server was deleted but every secretary computer remains with all the registry entries that points to this server. The computer can have like 5 registry to that server or 30 registry to that server. These registry keys slows down the computer because it search for the deleted server. Do you know a method I can use in AutoIt to search the registry and delete all the keys containing the CAPEDPRG word as an other account (without closing the secretary session) and without writing each possible keys in a registry file or on a single line ? I know it's a little out of the topic but help is really appreciated. Thanks
  2. Okay nevermind... I did a better search and found the ShellExecute command. So, $Directory = StringTrimRight(@ScriptDir,14) ShellExecute ( $Directory & "\BIOS\BIOSTool.exe", "" ,$Directory & "\BIOS\", "open" ) this command works as the BIOSTool.exe file needs to be in it's own shell. When you click on it, it's done by itself because you're not in the AutoIt Shell. Well thanks anyway, that's the solution for my 2 problems. I'll post agin if I run in a problem again.
  3. Okay, here is the thing i'm having problems with. I want to run a little application that only popup computer BIOS information to the user. $Directory = StringTrimRight(@ScriptDir,14) Run($Directory & "\BIOSTool\BIOS.exe") This line popup an error that says "Could not locate BIOS.inf in current directory. Aborting..." The file BIOS.inf is stored in the same directory as BIOS.exe I also tryed doing this : $Directory = StringTrimRight(@ScriptDir,14) FileCopy($Directory & "\BIOS\BIOSTool.exe", @HomeDrive, 1) FileCopy($Directory & "\BIOS\2.dat", @HomeDrive, 1) FileCopy($Directory & "\BIOS\3.dat", @HomeDrive, 1) FileCopy($Directory & "\BIOS\BIOS.dll", @HomeDrive, 1) FileCopy($Directory & "\BIOS\BIOS.inf", @HomeDrive, 1) Run(@HomeDrive & "BIOSTool.exe") The same error happend "Could not locate BIOS.inf in current directory. Aborting..." and the files are copied at the root of my c:\ with all the rights to read and write them. If I launch the app manually, it runs file but if I launch the AutoIt script alone or combined with WPI, the error is there. What could be the problem ? I want to know what could be the problem source for this if I run into that kind of problem in the future. Eventually, I will delete all the file after they are runned from the HomeDrive. Oh ! And it's the same type of error i'm having with the .CMD file I talked about before. So the solution for this problem will certainly be the same for the other one.
  4. Okay ! Thanks a lot ! As for now, all of my setups are working perfectly in every folders and conditions too. I've embeded the Do and While commands for having a better clicking result with many different computers configurations. Later on, I will ask about using an external .CMD file that calls .dll i'm having problems with too after I finish updating all my other scripts. Also, I found another bug like when in a setup, you have to reboot the computer and continue with the next command. I know that we can use : {REBOOT} 5 To restart the computer like in 5 seconds. But when WPI resumes after the reboot and explorer.exe is not yet launched, the path seems to have changed. But this bug was only with my old scripts not modified. I didn't tried it yet with the new method. An example is I launch a .cmd script done by someone else who uses files in the same folder. If i do it with WPI without reboot, the script finds all the needed files but after a reboot, when WPI resumes, the script can't find the files. I'll post this example like tomorow.
  5. And for regedit you suggest me to add the /s parameter as the script is loaded without user action right ?
  6. At first, it was only for testing purpose because I used all my scripts without WPI and I wanted to have something more "portable" that I can travel around in a USB key or a burned DVD so I wanted to start my already done AutoIt scripts with WPI.
  7. Thanks for the reply. Okay I don't clearly understand right so i'll put a directory structure with an image done with Microsoft Office Visio 2003 to show what I want to mean. And i'm not yet advanced as you in AutoIt scripting. My knowledge is limited in starting apps and clicking on buttons for now on. My workaround way : I place batchfiles in the Install folder and the batch file launch the AutoItScript and setup. Here is the code of one of my batch files : @ECHO OFF start install\AutoItScripts\ScriptGoogleStartup.exe install\RegTweaks\IEHomePage.reg exit And here is the code I use for the ScriptGoogleStartup.exe WinWaitActive("Éditeur du Registre", "Oui") ControlClick("Éditeur du Registre", "Oui", "Button1") Sleep(1000) WinWaitActive("Éditeur du Registre", "OK") ControlClick("Éditeur du Registre", "OK", "Button1") And here is the line that launch this in WPI. "%wpipath%\Install\StartScriptGoogle.bat" I know there are better ways like you explained. My problem was when I was trying to launch the reg file within AutoIt like this : RunWait("regedit " & @ScriptDir & "\RegTweaks\IEHomePage.reg") WinWaitActive("Éditeur du Registre", "Oui") ControlClick("Éditeur du Registre", "Oui", "Button1") Sleep(1000) WinWaitActive("Éditeur du Registre", "OK") ControlClick("Éditeur du Registre", "OK", "Button1") This code don't work. Note that when I was trying launching apps with AUtoIt, I placed all the exe in the Install folder at the same place as the batch files i'm using now. And I tryed to do what you said an it don't work too. My UAC si disabled, I used this reg to diable it and I checked if it was diabled manually too. [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System] "EnableLUA"=dword:00000000 And it's called LUA not UAC
  8. Okay, thank you for your reply. I will make it clear. WPI.hta Install --- AutoItScripts (Where I launch the scripts) ----------- Office ----------- Other Setup Folders (Each setup are sorted in a different folder) ----------- RegFiles I tried different things like placing the AutoIt scripts in each setup folder or placing them at the Install root... Each of them gave different types of errors especially when it's related to registry modifications or patching something. Some setup launched by AutoIt are working too when they do not have to interact with extern files like the setup of Office. By exemple, if the AutoIt is placed on the Install root, I would use the following command to launch a setup : Run(@ScriptDir & "\Office\Setup.exe") But for registry, Run("REGEDIT \RegFiles\Reg.reg") will start the reg file but give right or file corrupt error when automating clicking. Same thing using REGEDIT /S parameter. So, basically, if I understand well, WPI takes all files and assumes that the PATH si always the same folder as WPI.hta, so I should change my AutoIt lines from Run("REGEDIT \RegFiles\Reg.reg") to Run("REGEDIT \install\RegFiles\Reg.reg") right ? But again, if I start the AutoIt script by clicking on it, the setup starts and everything goes well. When I start it with WPI, here comes all the problems.
  9. Okay I figured out something. In WPI, it assumes that %wpipath% equals to the place where wpi.hta is. So, in a command, "%wpipath%\WPI\Install\something.bat" is not the correct form to use. You should remove manually the WPI written there and use "%wpipath%\Install\something.bat" instead. Also, in AutoIt, there is a function that you can use to start files. So, I placed Run("something.exe") in each of my AutoIt script to run the setup and start simulating clicks on the questions of the program. This way is not good to use because AutoIt assumes that the "something.exe" file is placed in the same folder as the script itself so the PATH is set to the same folder. WPI assumes that the PATH is where the wpi.hta file is. So, AutoIt and WPI where confused about where to take the default PATH. One correct way to use WPI helped with AutoIt is to forget starting apps from AutoIt and always start files with a batch file. So, in my WPI config, I placed the line "%wpipath%\Install\StartScriptGoogle.bat" to start my main batch file. And, in my batch file, I use the lines : start install\ScriptGoogleStartup.exe start install\WindowsTweaks\IEHomePage.reg Remember that WPI assumes the folder where is wpi.hta to be the PATH. The setups are in the install folder so we must point to the right folder from where WPI.hta is. And using start before each in a batch file means that you want to start the two apps at the same time instead of file by file like it is without the start command. So my first line starts the automated click exe generated with AutoIt who waits for the registry popup before clicking and my second line starts the registry file to start the popup AutoIt waited for. If it wasn't of the "start" command, my AutoIt would have waited forever and my batch file paused forever because the AutoIt script would never had completed. Sorry if it's not understandable, I answered my question myself and wanted to describes what kind of problem I had before.
  10. Hi there, I used WPI for a long time since the begin of it's developpement. Today, I started using it with some AutoIt scripts to automate my installations and settings. So I tried simple install, it works perfectly. I use WPI to launch my AutoIt scripts for simple installation like Office 2003 or an Antivirus software and my AutoIt script (converted into an exe) do the rest like launching all the setup.exe in each apps folders. Here comes my problem... I started to include Registry Tweaks into my AutoIt scripts. When I launch the script manually by double-clicking on the exe, the script goes perfectly. When I ask WPI to launch the script I see the registry tweak start and then... it says that I don't have administrator rights to install the reg file or it's corrupted... I don't understand a thing... Does Windows Vista detects if the script is launch manually or by an application ? Also, another problem I found is when I start a setup that needs other files in the same folder to advance, suddenly, an error popup and says that the setup can't find the other files. When I run manually the AutoIt script again, everything goes perfectly. It seems like the PATH or something is messed up. I tryed many things like asking my AutoIt script to launch a batch file, that didn't work. Asking WPI to launch a batch file that starts my AutoIt script too gets some errors. Is WPI started as an administrator when you launch it ? I disabled the user control and my account IS administrator of my computer... I don't understand why... And is there a known PATH problem with WPI and Vista ? Is some of you uses AutoIt combined with WPI and has runned into that type of error and found a solution, can you give me a clue ? Thanks.
×
×
  • Create New...