Often (not always) this can be attributed to the fact that your target application is running elevated and your script is not. Or copying files to certain areas also requires the script to be run elevated.
Symptoms of this can be:An ordinary process (a process run as a standard user) can not interact with or exchange information with an admin process. So if your application is running with elevated privileges, your script cannot interact with it unless it is also elevated.
- Files refusing to copy to certain areas with no warning of the failure at all.
Keys not being received on the target application, again with no sign of a warning or error message.
SCRIPT 1 - Test a file write. Compile this as COPYTEST.EXE and run it. This will tell you if a file copy has been successful or not. Script Name:
Code: Select all
// Enter your path here
Let>path=C:\Program Files (x86)\Steinberg\Vstplugins
WriteLn>%path%\test.txt,rrr,Test file to see if we have permission to write
Wait>1
IfFileExists>%path%\test.txt
MDL>Write Succeeded
DeleteFile>%path%\test.txt
ELSE
MDL>Write Failed - Try setting run as admin.
ENDIF
SCRIPT 2 - Compile this as ADMINRUNNER.EXE and run it (make sure it is in the same folder as Script 1). It starts the above script elevated. If the problem you are having is related to permissions then running it elevated using Script 2 will solve the problem:
Code: Select all
Let>app_name
Let>RP_ADMIN=1
Let>RP_WAIT=1
Run>"%SCRIPT_DIR%\COPYTEST.EXE"
Obviously to test the key sending area you can write a similar script to Script 1 that sends some simple keys. Observe it and if it fails then run it with Script 2 to see if the keys get sent.
Then you can even include something like Script 2 in your packaged installer as a shortcut and call it:
MyApp (Run as Admin)
Users can simply launch your app using that shortcut rather than messing about finding the actual app and selecting "Run as Admin" etc.
There may be better ways to do this but this is my solution.
I hope some may find it useful.