SKlocke

Use a Sleep command after the call to _main to check every 10 seconds or so. If you do not, the While loop and WinExists calls will eat all the processing power they can get (one of two processors in your case I'd guess).

Do the key names really change with each installation of the program? I was thinking that these GUIDs are fixed for a given program (InstallShield calculating some hash value..? But then, what about the next patch of that program, still same GUID?) If they were fixed, you could read the key, and compare DisplayName against the program name you expect there to be.

Depends on details of what you want to do. Changing MS Windows settings for the other account - some things will work with editing registry for that user. Another possibility is the use of command line programs to make settings, and using RunAs/RunAsWait to execute them as the second user (if you have his name and password).

I've used the edb-psql executable to execute small SQL queries or some meta command that Postgres offers. But I'm sure that I'm not the only one who needs more information from you to be able to help. Like "I've tried the following approach, I got this part to work and now I am stuck with the following error..."

Use IsAdmin to ask if user has admin rights. If he has not, open an input box for administrator username and password and then use RunAsWait to execute everything that needs admin privileges. Or use these two steps in a little starter program that then runs the work program with admin privileges. On Win7 with UAC and artifical user context some extra steps might be needed.

1) You have to resolve the ProgramFiles variable. Either by telling Autoit to expand environment variables in strings: Opt("ExpandVarStrings") But I do not like it, as sometimes you might want to pass something without expanding and I find it easier to read if I build the string manually. Local $path= EnvGet("ProgramFiles") Local $programPath = $path & "\myProgramFolder\myProgram.exe" 2) Also, you have to give the filename with complete path to the executable as Parameter filename. Workingdir affects any file read/write and similar operations that might get called, but Autoit needs the path to the executable and does not look in workingdir. 3) With using a domain account or calling an AntiVir uninstaller with Windows 7 UAC there might be more challenges. If you run into problems with that, let us know the specifics if you need further help. 4) Whim is right about exit code as return value. Unfortunately, if e.g. you pass an invalid string to execute and Windows only gets a folder, not an executable that it shall run, you will get 0 as exit code. Hope I got all that right, I'll try to read results or further questions later today.

Have a look at the documentation of While <expression> statements ... WEnd and Sleep. And if you want more detailed help, people might want to know what you want to do this for. 5 seconds sound like a short time for many tasks, so just in case - asking about help to trick in a game is at least frowned upon, more likely forbidden on this site, depending on the game.

H: is a network folder, mapped to the drive letter? Try to give the network address, as in \\server\folder\. I think UAC introduces some kind of virtual user context, and if your folder mapping is executed on logon, it is not present when UAC switches user. Also, you could look at the FileInstall function. This will include a target file during compile time and allow you to put it at a location during run time.

The only occurence of $doscommand in your script that I can find is when you put it into the RunWait. Could it be that you pass a String with uninitialized content to RunWait to execute? I'd add a log message writing the content of the command you want to execute to debug.

I also use the approach zorphnog mentions, compiled scripts as this tells AutoItWrapper to modify the manifest of the resulting executable. When I tried using #RequireAdmin, there was a bug when UAC was turned off. But it worked fine with UAC turned on (this sounds like what you have). So what happens with your script, does the DirCreate work, the first DirCopy where you do not use the $user?

Thanks guys, my bad. Tested it with the beta and the current version from downloads page 2.0.1.24 and only one language. Apparently I've run an old installer, sorry to bother you.

Can you enter the user name of the windows user that is logged in? This way, you could verify that it is not because of some access rights restrictions that could apply.

For your script, I think you should use the RunAsWait to run the script as admin. This will pause your first instance while the second is running. RunAs will continue execution of the first instance without waiting. Also, you could have a look at the #RequireAdmin keyword, which will perform a similar function.

Hi all, recently I spent some time looking at resources that get embedded into the executable, using AutoItWrapper. One thing that I noticed by chance is that when you set a resource language (running AutoItWrapper under Windows 7), you end up with resources for two languages (used ResourceHacker to look at it). One default resource for the default language (UK english, code 2057), and one looking like what you want for your chosen language. E.g. #AutoIt3Wrapper_Res_Language=1033 #AutoIt3Wrapper_Res_requestedExecutionLevel=requireAdministrator will produce a manifest for the language 2057, containing default <requestedExecutionLevel level="asInvoker" uiAccess="false"/> and the manifest you asked for, for the language 1033, containing <requestedExecutionLevel level="requireAdministrator" uiAccess="false"/> If used this way, one might end up with MS choosing the wrong manifest when application is started. Looking at the source and at MSDN, I think that MS introduced a stricter check to its function UpdateResource starting with Windows Vista, which is used to delete the default language resource if the user wants to set another one. The data passed to delete it seems invalid to MS. Work around for me would be not to set another language, MS will pick the one and only resource independent of language. Fix could be to pass a null pointer to UpdateResource instead of an empty string, but I could as well be far off as I did only a quick test under Win7. The behavior does not seem correct, even if impact is very low, but I could imagine that authors of user defined functions might also have some interest in this. I could observe this behavior under Win 7, AutoItWrapper 2.0.0.1. I do not think that it happened under Windows XP, Vista I do not know. Is anyone able to test this under Windows Vista? Just use the two compiler directives I gave as an example, and one line of AutoIt code. Then look at the result with ResHAcker or in an editor like Notepad++. And maybe something to teach me a bit - a scenario where you have to change the language of resources? Maybe to tell Windows which character set to use for umlauts?

The advantage of using a directive to use one complete manifest file would be that the AutoItWrapper would not have to care about ordering the manifest entries. For all (the little) that I know of XML and Microsoft manifests, I could not blame anyone for giving the user responsibility of supplying a well formed manifest, as opposed to trying to build one himself. If AutoIt needs to make some entries itself, the user would have to take care of that too and put it into the manifest (not sure if this applies). Same would go for requestedExecutionLevel and resource language option that AUtoItWrapper offers. Mixing both approaches - AutoItWrapper reads a manifest file, and merges its entries looks more difficult to me. With only the requestedExecutionLevel and supportedOS entries in their respective sections, I'd consider ordering the manifest entries a feasable solution. If I understand the wrapper correctly, this would require if switches around the lines that build the temporary manifest file. If feasable, I'd consider this a more pretty solution as an AutoIt user would only have to give one directive and not work with a manifest himself. Well, a lot of if's..I'd consider..I am not sure that I know all implications of the two possibilities...

I'll continue to reply here if I got an idea, but I'm not sure when - or even if - I'll find the time to spend on this. That's why I used "personal use".

First running solution I got uses mt.exe and resource hacker. I did not get it to work just using mt.exe on the executable. Even on a small and simple script (without FileInstall and UPX), mt.exe did not perform completely and after the modified manifest, only padding values appear in the executable file. Maybe mt.exe expects a format for the executables that is used by Visual Studio, but not by AutoIt? Again, something I know very little about. So now what I do is ;Turn of compression for reshacker to work #AutoIt3Wrapper_UseUpx=n ;Switch that will tell AUtoIt wrapper to include ..requestedExecutionLevel level="requireAdministrator".. in the manifest #AutoIt3Wrapper_Res_requestedExecutionLevel=requireAdministrator ;extract manifest to a file. Probably works with these params only if there is only one resource language (could append 2057 for UK) #AutoIt3Wrapper_Run_After=""<path to reshacker>\ResHacker.exe"" -extract %out%, Installer.manifest, 24,1, ;use MS tool to merge a custom manifest with the one created by AutoIt #AutoIt3Wrapper_Run_After=""%VS80COMNTOOLS%\bin\mt.exe"" -manifest Custom.manifest Installer.manifest -out:Installer.manifest ;and use reshacker to put this merged manifest into the exe #AutoIt3Wrapper_Run_After=""<path to reshacker>\ResHacker.exe"" -addoverwrite %out%, %out%, Installer.manifest, 24,1, And I completely agree, a built-in solution (not having to worry about getting mt.exe, which is part of Visual Studio and Windows SDK, the version you use, turning off compression for resource hacker, maybe running into strange problems with resource language and whatever...) could be to the benefit of many. I am currently looking into AutoItWrapper.au3 if I can tweak it for my own use. Lines to create the manifest are straightforward, so I should be able to. For the feature request, I created Ticket #1595. If you have suggestions that I should add as comment or similar, maybe PM me, I'll try to check my box the next few days. (I am not a regular here, advise is welcome) Thanks for everyone's time!

First tests look promising. ResHacker has a command line mode to automate the task, UPX is not critical in my task I think, and the resulting exe seems to work. I'll have to work on it for a bit to extract the existing manifest and merge my changes into it, but this should be enjoyable work compared to not knowing what to do at all. Thanks! I'll post a description of my solution when I get it done.

Thanks for the answer, I'll use your authority to file my task under "can't be done at the moment" and look for a workaorund for the PCA. With Windows 7 getting used more often, this might be of interest for other users as well. So I'll take a bit of time to further look into it and indeed post a feature request once I do not find another way (and get the FR rules right).

Hi all, I come to you with a problem I can't solve on my own. What I want to do is to modify the manifest that is embedded in the executable created by AutoIt (target OS is Win7). More precisely, I want to add a compatibility section to get rid of the MS Program Compatibility Assistant (PCA) message telling me that the program did not install correctly (triggered by UAC turned on, executable with Setup or Installer in its name and not adding a program). Including Win7 in the supportedOS values prevents the message. The AutoIt wrapper directive #AutoIt3Wrapper_Res_requestedExecutionLevel=requireAdministrator already does modify the manifest, but it seems that the result is hard coded in the wrapper sources and no other fields can be added. The #AutoIt3Wrapper_Res_File_Add directive does not seem to be what I want - I do not want to include a resource file, but embed it in the executable (not to mention that I do not know if a manifest qualifies as resource). The manifest tool mt.exe corrupts the executable, the method of modifying a registry key to exclude my program from PCA works only if it is done before program start, changing the name of the exe is not an option... so I'm stuck. Help would be appreciated, regards

A small addition, as it took me a while to get the manifest based solution to work. Autoit embeds a manifest section into the executable. Its content can be controled with compiler directives (that can be inserted with SciTE AutoIt Wrapper). The directive to require admin rights is #AutoIt3Wrapper_Res_requestedExecutionLevel=requireAdministrator. Hope this reply is not out of place, but it took me *quite* some time to realize that I could not and did not have to bind another manifest but set an option.