Jump to content

UDF for detecting whether AutoIt can cut-paste from a window


Recommended Posts

Here's a short UDF that will, at least in most cases, detect whether a window can be copied from or pasted to programmatically--for example, by Send()ing ctl-c, ctl-v. This is often disabled when programs (like your AutoIt script) run at a lower UAC integrity level than the application they are trying to operate on.

#include <WinAPI.au3>

Func _WindowIsPasteable($handle) ;accepts window handle; returns true or false whether a window will accept Ctl-C, Ctl-V
    Local $bCanPaste = True
    Local $hTestWindowPID = 0
    Local $hTestWindowTID = _WinAPI_GetWindowThreadProcessId($handle, $hTestWindowPID)
    _WinAPI_AttachThreadInput(_WinAPI_GetCurrentThreadId(), $hTestWindowTID, True);attach to window we want to paste into
    $bCanPaste = _WinAPI_GetFocus() ;Test whether window is paste-able--returns False if it is not
    _WinAPI_AttachThreadInput(_WinAPI_GetCurrentThreadId, $hTestWindowTID, False);detach from window thread
    Return $bCanPaste
EndFunc

Pass it a window handle; it returns true or false whether a window will accept programmatic pasting. The function may not work on the CMD window, since it handles the clipboard uniquely.

This function works by attaching to the program thread of the window whose handle it receives, then attempting to perform a GetFocus on that thread. In most cases, the attempt will fail if the window will not accept programmatic copy-paste.

Edited by tcurran
Link to post
Share on other sites

Thanks for this.  I hadn't considered such a method.  But I do have a question:

Quote

the attempt will fail if the window will not accept programmatic copy-paste

Can you point to documentation that explains this in more detail?  Are there cases where a browser window, for example, would return False (='no paste')?

Link to post
Share on other sites
  • 3 weeks later...

qwert--

Those are excellent questions. This approach was suggested to me by "Joe" the developer of ArsClip. I adapted his approach to AutoIT, tested it in my particular application (it worked!!) and posted it here.

Your question about browser windows is particularly trenchant, but--since I haven't tested it--I have no answer. Please post back here if you learn whether it does or doesn't work.

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Doniel
      Hi there! 😃
      I've 2 simple scripts:
      Script 1 starts script 2 Script 1 gets executed with normal user rights (un-elevated) Script 2 contains an #RequireAdmin and therefor can only start elevated I want to read the output of script 2 with script 1 AND have the UAC of script 2 being activated as fullscreen Script 1 (Scripts location is the same as script 2 that I'm running with Run()
      Local $iPID, $sOutput $iPID = Run(@ComSpec & " /c " & "C:\Entwicklung\Autoit\Test\Temp.exe", @ScriptDir, @SW_HIDE, 0x2) ProcessWaitClose($iPID) $sOutput = StdoutRead($iPID) StdioClose($iPID) ConsoleWrite($sOutput) MsgBox(1, 1, 1) Script 2 (compiled as Temp.exe)
      #RequireAdmin ConsoleWrite("Return") MsgBox(1,1,"ADMIN") Now my problems are the following:
      Without the #RequireAdmin I can read the output with no problem, but not with the #RequireAdmin ($sOutput is empty) Using @SW_HIDE in the Run() command makes the UAC always start minimized (see attached picture) and the admin has to always manually click on the icon to enter his credentials since the UAC doesn't start in fullscreen. Here and on a few other sites they explain that the program launching the elevated program NEEDS to be activated in order to directly show the UAC fullscreen and not minimized. Using @SW_SHOW would get rid of the problem, BUT that leaves me with an ugly cmd.exe floating the whole time while the elevated script ist running. And my questions to that I'm seeking an answer for are:
      Problem 1: Is it just not possible to read from an elevated program with an un-elevated user/script? I also get the Access Denied if I press No on the UAC as an Output in $sOutput (Guess since its's still un-elevated) Problem 2: Is there a way to either make the floating black and blank cmd.exe being moved to the background and be non visible to the user OR to somehow bring the minimized UAC to the foreground/fullscreen? What I already tried and what didn't help me:
      $iPID = Run(@ComSpec & " /c " & "C:\Entwicklung\Autoit\Test\Temp.exe", @ScriptDir, @SW_HIDE, 0x2) While Not WinExists("Temp.exe erfordert Ihre Berechtigung") ConsoleWrite(1) WEnd WinActivate("Temp.exe erfordert Ihre Berechtigung") WinSetState("Temp.exe erfordert Ihre Berechtigung", WinGetText("Temp.exe erfordert Ihre Berechtigung"), @SW_SHOW) WinSetState("Temp.exe erfordert Ihre Berechtigung", WinGetText("Temp.exe erfordert Ihre Berechtigung"), @SW_MAXIMIZE) WinSetState("Temp.exe erfordert Ihre Berechtigung", WinGetText("Temp.exe erfordert Ihre Berechtigung"), @SW_ENABLE) The While-Loops helps a lot and also stops after a second or so (► Stops to write ones (1)). That means that the actual "window" of the UAC is found, but all the WinXXX functions don't do anything and the UAC stays minimized. I also tried to minimized/move the cmd.exe to the background with WinActivate() and WinSetState() with no success.
      $iPID = ShellExecute("C:\Entwicklung\Autoit\Test\Temp.exe", "", @ScriptDir, "open", @SW_HIDE) Using ShellExecute() instead of Run() completely solves the UAC to fullscreen problem BUT I haven't found a consistent way to read the output of ShellExecute(). Neither here on the forum nor somewhere else. If I'd be possible to read the output from ShellExecute() then all my problems would be solved at once!
      Also tried a few more things and playing with some parameters but everything with no success.
      I'd really love some help and support here from you.
      Thanks in advance!
       

    • By Rskm
      Hi, I have 5 notepad files with lot of data in each of it. The data are arranged in lines and i wish to get it pasted/copied into excel.  Say, i need to read notepad1 and paste the contents into sheet1 of excel and notepad2 to sheet2 and so on.  If i read the notepad and paste it line by line, it is taking lot of time.  Is there a way by which i can paste the whole of notepad file into excel sheet(and get it pasted line by line as shown in the attached excel), instead of using code to write it line by line?.. I was using Filewriteline(data, line i) initially to write to excel.  The 'i' value was incremented with for loop and the excel was updated, but this takes lot of time.  The expected excel format is attached here.  any help is appreciated.  thanks
      Tmp.xls
    • By vinnyMS
      #Include <Array.au3> #include <Constants.au3> $s = FileRead("2.txt") Local $w = StringRegExp($s, '(?is)(\b\w+\b)(?!.*\b\1\b)', 3) _ArrayColInsert($w, 1) For $i = 0 to UBound($w)-1 StringRegExpReplace($s, '(?i)\b' & $w[$i][0] & '\b', $w[$i][0]) $w[$i][1] = @extended Next _ArraySort($w, 1, 0, 0, 1) _ArrayDisplay($w) i have this script that returns 3 columns  
       
      i need to copy the  Col 0 and Col 1 as text to paste on notepad or excel
      you will have to create a "copy" button if possible
      array.au3 2.txt
    • By rudi
      Hi,
      When a non compiled AU3 script is run with #RequireAdmin, then if the UAC prompt can be authorized due to the fact, that the currently loggedon user has local admin rights, then the macro @UserProfileDir correctly reflects the profile dir of the user of the windows logon session.
       
      When the script with #RequireAdmin is started by a "normal user" without local admin rights, and I use a domain admin account to authorize the UAC prompt, then @UserProfileDir reflects the profile dir belonging to the AD-Admin account.
      As the script originally was started using the "regular user" I'm wondering, if there is a chance to "pass" the original user's @UserProfileDir to the UAC elevated script?
       
      As playing around with this feature I realize, that I basically don't know the exact mechanism of the UAC elevation authorization process:
      The script is started by right mouse click, execute script This is invoking e.g. "C:\Program Files (x86)\AutoIt3\AutoIt3.exe" "C:\Users\Rudi\Desktop\test.au3" as by this registy value: Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\AutoIt3Script\Shell\Run\Command] @="\"C:\\Program Files (x86)\\AutoIt3\\AutoIt3.exe\" \"%1\" %*" But what I honestly don't know is, how does the UAC propt interact in the program startup? I guess, that Autoit3.exe is parsing the AU3 source, is seeing the #RequireAdmin and then "relaunches itself with the AU3 as %1" requesting UAC elevated rights "from windows"??? With Process Explorer I can see, that The commandline then is this one with a "!" before "%1"
      "C:\Program Files (x86)\AutoIt3\AutoIt3.exe" !"C:\Users\Rudi\Desktop\test.au3"  It it should be something like this, then it might be possible to pass the original @UserProfileDir to the second, UAC elevated "Startup"??? <edit>
      I just noticed:
      When I use "WIN+R" and then directly use the command line, I see in Process Explorer, ...
      "C:\Program Files (x86)\AutoIt3\AutoIt3.exe" !"C:\Users\Rudi\Desktop\test.au3"
      ... then this script with #RequireAdmin is started *WITHOUT* UAC elevation.
      Guessing, that this ! is just reverting #RequireAdmin I tried the "opposite" one as well:
      AU3 script without #RequireAdmin Starting with "C:\Program Files (x86)\AutoIt3\AutoIt3.exe" !"C:\Users\Rudi\Desktop\test.au3" does not invoke UAC elevation prompt. So to me it looks like, this ! is a "status flag from Autoit3.exe to Autoit3.exe", that the elevation process was done already? amazing...
      the topic Autoit on Windows Vista is telling no details of  this UAC process...
      </edit>
       
      Regards, Rudi.
×
×
  • Create New...