_Script runs fine when run under Winbatch Studio but not when compiled.

[pguild]

I run a program from Winbatch Studio that is supposed to send ( "^c" ) to another application with this code:

  TOSwin = "Main@thinkorswim"      ;LINE 1
  MousePlay("313 404", TOSWIN, "", @MPLAYLCLK, 1)  ;LINE 2
  Sendkeysto(Toswin, "^c") ; when line 2 above works, this should send some text to clipboard
; But clipboard does not have the proper text when program is run from .exe; it does work when run from Winbatch Stuido

[td]

There is no difference between WinBatch Studio and a compiled script in terms of the internal functioning of each function in a script.  The only difference that is a product of the differences between the two is that the WinBatch Studio scripts have a slight increase in execution time when executed using the debugger. 

This means your problem is very likely environmental.  It could be a timing issue, an input focus issue, an execution level problem, or something else.  You will have to spend some time thinking about those differences to determine what the cause of your script's failure is.

[pguild]

The program works up to move the cursor and apparently left click on a spot in the other program.
Then I try to try to activate this code:

Sendkeysto(Toswin, "^c")

But no new text is sent to the clipboard by my program.
However, if I stop the program right before that sendkeysto code
and press "^c" manually, it works.  So it is the  Sendkeysto(Toswin, "^c")
that is failing.

Putting a time delay before the Sendkeysto does not help.

What can I do to troubleshoot this?

[pguild]

 :'( Further testing shows that all though the mouse is moved to the proper position
with MousePlay the left click does not work with the compiled script.   >:(

This following code moves the mouse to the correct position, but the other application does not see the left mouse click.
MousePlay("313 404", TOSWIN, "", @MPLAYLCLK, 1)  ;LINE 2

But when run from Winbatch Studio it work fine.  :-\
There must be a simple solution to this?????????

[ChuckC]

What you describe sounds like a UAC-related elevation problem.

Verify that the compiled script running as a .exe file is running at the same elevation as WinBatch Studio.

Also, verify whether the application being controlled is running elevated.

In a nutshell, processes running with a restricted token [e.g. limited to normal user privileges] are unable to interact with the UI controls of any window belonging to a process running with an elevated token [e.g. administrator privileges].

[jmburton2001]

Just spitballing here... But if he's using MousePlay to get focus on the target window, couldn't he use ClipPut() instead of sending the ^C keystroke?

[td]

My first thought was the same as ChuckC's; an elevation issue.  The problem is that they can be tricky to predict. Microsoft seems to keep tweaking the rules in subtle ways with each new update of Windows 10.

[ChuckC]

The simplest way to test is to run the compiled script elevated [with administrator rights] and test with it to see if the scripted UI interaction is working properly.  If so, that's nails down the nature of the root-cause of the problem.

There is a manifest setting that exists which modifies the UI interaction regardless of the respective elevation levels; it is basically a statement to the operating system of what kind of behavior the application is going to be engaged in so that at process creation time the operating system can evaluate the criteria that permit the behavior and make a decision to flag the process as [not] allowed to perform the UI interaction operations..  However, Microsoft has some relatively tricky rules regarding this, as follows:

1)  The uiAccess flag MUST be set to True in the application's manifest.

2)  The application's binary must be digitally signed with a valid digital certificate.

3)  The application's binary must be located in a trusted location, such as "Program Files" or "Program Files (x86)"; otherwise, the uiAccess setting in the manifest is ignored.

AFAIK, the binary for WinBatch Studio meets all of these requirements.  A compiled WinBatch script isn't automatically going to meet requirement #2 even requirements #1 & #3 are met.


To be safe, I'd use a test VM where I could completely disable UAC or minimize it's level of interference to where unmanifested applications running from arbitrary locations can perform UI interaction to confirm that the compiled script is coded properly and is only being prevented from functioning as coded by the operating system itself.  Depending on the version of Windows, especially the various builds of Windows 10, UAC may not be able to be completely disabled.

There are a local security policy settings that can modify the requirements for elevation of an application, as follows:

"User Account Control: Only elevate UIAccess applications that are installed in secure locations" that can be toggled on/off to affect those requirements.

"User Account Control: Only elevate executables that are signed and validated".

If both of those security policy settings are disabled, then simply setting the uiAccess manifest setting to True and then running the compiled script elevated with administrator rights should get things working provided that the script is coded propertly.

[td]

Unfortunately, Windows 10 feature updates do not always follow the "official" rules as you have delineated them.  We have found cases where the "User Account Control: Only elevate UIAccess applications that are installed in secure locations" policy is sometimes ignored.  Ignored both in elevating applications not installed in a secure location and not elevating applications stored in a secure location.  This untoward behavior can appear with a standard user account but not an administrator account or the other way around. 

Another interesting aspect of this is that which Win32 APIs that require uiAccess set to TRUE varies from release to release.

One way to experiment with this is to install WinBatch to an "insecure" folder and see what happens when you run each of the versions of WinBatch with a unique manifest combination.  WinBatch.exe, WinBatch_IF.exe, e.t.c.  The results can be surprising depending on your current feature version and patches.

The best advice is always places compiled scripts that perform UI interactions with other processes in a directory that standard users cannot write to and make sure you have uiAccess set to TRUE; otherwise, set it to FALSE.   To be super safe you need to code sign your scripts but that cost $ and is not always necessary if your application has a narrow distribution or your compiled script does not perform ui interactions with other processes.

[pguild]

Thanks everyone!   :)  I have several questions about how verify things as you guys have suggested. For example,  "The uiAccess flag MUST be set to True in the application's manifest."

I am seeking to understand what is meant by the "application's manifest" or how to set the uiAccess flag in it.  ???

Thanks!

[ChuckC]

A "manifest" is a file containing meta-data that provides Windows with information regarding the expectations about the runtime environment, UAC elevation requirements and the intended behavior of the program as it relates to interacting with other programs on the user's desktop.

When you have the WinBatch Compiler dialog box displayed, click on the "Settings..." button and another dialog is displayed with a group box "UAC Settings" containing controls that are responsible for populating the manifest settings when you compile a script to a .EXE.

[kdmoyers]

((this thread is utterly fascinating and explains why many old techniques no longer work for me))

[ChuckC]

This issue has been going on since the initial release of Windows Vista, and has had, as Tony has stated, several counter intuitive twists & turns as Microsoft has enhanced, tweaked & tuned how UAC functions thru Windows 7, 8, 8.1 and all the builds of Windows 10.

It may well seem like quite a headache to deal with, enough so that you may feel inclined to attempt to disable or minimize UAC's level of intrusion into your "desktop" experience.  However, for those who logon with an account that has elevated privileges, UAC is very much a welcome presence when it comes to mitigating the negative effects of malware.  Although I typically operate under a continuously high level of paranoia about accessing sketch web sites and executing downloaded programs with questionable provenance, UAC has definitely stepped in and prevented a handful of intrusions that slipped past my high level of caution.  I can say with confidence that since UAC became available, I have discontinued making use of any 3rd party add-on software to combat malware, relying solely on the presence of UAC and Microsoft's built in firewall & anti-virus functionality in Windows, and I have had zero successful malware intrusions/infections in the 13+ years since I started running Windows Vista & newer.

As it relates to developing software [including WinBatch scripts] where an awareness & understanding of UAC is necessary to properly build, deploy & execute the software, it is well worth it to take the time to learn about it and understand it rather than fearing it and trying to bypass it.  Microsoft has expended significant effort to make it work as intended when it comes to increasing the level of security and limiting the ability of malware to function at all.

[td]

...
As it relates to developing software [including WinBatch scripts] where an awareness & understanding of UAC is necessary to properly build, deploy & execute the software, it is well worth it to take the time to learn about it and understand it rather than fearing it and trying to bypass it...

Couldn't agree more.

[td]

Here's a script form someone else that is useful for illustrating the differences between different Windows 10 feature update's handling of User Account Control.  The script's comments mention that the script fails when it is run directly (not from WinBatch Studio) from a file with the .wbt_if extension. (The .wbt_if causes the script to be executed by the version of WinBatch manifested with "asInvoker" and "FALSE".)  The script's comments are true for Windows 7 and Windows 10 1803.  However, on Windows 10 1903 the script does not fail and works just fine when the script file has the .wbt_if extension. 

Note that these observations are based on UAC being set to the default "Notify" level.

Code (winbatch) Select Expand

;; !!!Important: the result blow are bassed on UAC prompting being enable.
;WORKS: Logged in as Admin, Script with default .WBT extention (HighestAvilable)
;WORKS:  Logged in as Admin, Script with .WBT_AF extention (RequireAdministrator)
;FAIL:  Logged in as Admin, Script with .WBT_IF extention (AsInvoker)
uaclevel = "Error or unsupported platform.;Process is default (UAC is disabled or standard user).;Process is running elevated.;Process is not running elevated (user is in Administrators group)."
Pause('UacElevationLevel of Script',ItemExtract(UacElevationLevel()+1,uaclevel,";"))

;Launch an Elevated Process
ShellExecute("cmd.exe", "", "", @NORMAL, "RunAs")

parentwindowname = "Admin"
ret = WinWaitExist( parentwindowname, 5 )
if ret == 0
  Pause("Notice","Unable to access specified window")
  Exit
endif

;Attempt to sendkeys
SendKeysTo( parentwindowname, "Hello World." )