What am I doing wrong here.
I am trying to get a list of names in the clip that look like
I have tried
ClipPut("Bob" & @CRLF & "Greg" & @CRLF & "James" & @CRLF & "Kevin" & @CRLF & "Tim" & @CRLF & "Kelly" & @CRLF & _ "Susan"_& @CRLF & "Bill" & @CRLF & "Maggie" & @CRLF & "Amanda" & @CRLF & "Matt" & @CRLF & "Robert" & @CRLF & "Sara" & @CRLF & _ "Zach" & @CRLF) and
ClipPut("Bob" & @CRLF & "Greg" & @CRLF & "James" & @CRLF & "Kevin" & @CRLF & "Tim" & @CRLF & "Kelly" & @CRLF & _ & "Susan"_& @CRLF & "Bill" & @CRLF & "Maggie" & @CRLF & "Amanda" & @CRLF & "Matt" & @CRLF & "Robert" & @CRLF & "Sara" & @CRLF & _ & "Zach" & @CRLF)
hello autoit group
please i've a question
i had make a function that put some thing into the clipBoard and paste it
using the send function
when the keyboard is english all things work fine
but when the keyboard is arabic the send command write the ltr v insted of the text in clipboard
i was tryed to use
but the same
please can any one help me
Hello all! I'm stuck at a seemingly simple part of my script. Using IE, I'm filling out a web form that involves clicking a "Browse" button and selecting a file. Once the file explorer dialog opens, however, I am unable to control it.
I have a string, which is the name of the file I want, and I'm trying to insert it into the 'File name:' text box in the dialog (which already has focus), but it doesn't get inserted. I've tried ClipPut and Send.
What's even more concerning is, when I close the dialog, the string is then pasted into the very next window that has focus, which is often SciTE. It's like that Browse's file open dialog halts all processes. Once it's closed, the script continues.
;~ Open a IE window and navigate to the login page. Global $oIE = _IECreate($urlBBLogin) _IELoadWait($oIE) ;~ Recognize the form on this page (login input boxes). Local $oForm = _IEFormGetObjByName($oIE, "login") Local $oTextLogin = _IEFormElementGetObjByName($oForm, "user_id") Local $oTextPass = _IEFormElementGetObjByName($oForm, "password") ;~ Enter the Automation user credentials into the form. _IEFormElementSetValue($oTextLogin, $bbUsername) _IEFormElementSetValue($oTextPass, $bbPassword) ;~ Click the Login button. _IEFormSubmit($oForm) _IELoadWait($oIE) ;~ Navigate to the feedfile upload page. _IENavigate($oIE, $urlUpload) _IELoadWait($oIE) ;~ Click the Browse button Local $Browse = _IEGetObjById($oIE, "feedFile_chooseLocalFile") _IEAction($Browse, "Click") Local $Browse = WinWait("Choose File to Upload") ;~ Open the file we created. WinActivate($Browse) Send($finalFile) Has anyone else experienced this problem? Any ideas to get around it? Am I approaching this the wrong way?
Any support is greatly appreciated.
Programs like Ditto are a great augmentation to the Windows clipboard where it keeps a list of items you copy and paste and you can go back to days, weeks, months later. It also comes in handy for multiple copied items you need to paste over and over again.
Windows 10 also now has a clipboard history capability (though not as robust, I think, as Ditto).
I would like to simulate this type of clipboard history into my own apps independent of Windows' clipboard, but I haven't a clue as to where to begin.
Thank you in advance for any suggestions, examples, shelved codes. ☺
I'm creating a tool which automatically saves screenshots. I've found that some images appear corrupt after saving. I've narrowed the source down to screenshots taken from within an RDP session via the Ctrl+Alt+Plus (PrtScn equivalent) and Ctrl+Alt+Minus (Alt+PrtScn equivalent) key combos.
Here is the example code:
#include <ClipBoard.au3> #include <GDIPlus.au3> If _ClipBoard_IsFormatAvailable($CF_BITMAP) Then ConsoleWrite("+Bitmap found on Clipboard" & @CRLF) If Not _ClipBoard_Open(0) Then MsgBox(16, "Error", "_ClipBoard_Open failed") Exit EndIf $hClipboardImage = _ClipBoard_GetDataEx($CF_BITMAP) _ClipBoard_Close() _GDIPlus_Startup() $hBitmap = _GDIPlus_BitmapCreateFromHBITMAP($hClipboardImage) $sCLSID = _GDIPlus_EncodersGetCLSID("JPG") _GDIPlus_ImageSaveToFileEx($hBitmap, @ScriptDir & "\" & TimerInit() & "_Clipboard_Image.jpg", $sCLSID, 0) _GDIPlus_BitmapDispose($hBitmap) _GDIPlus_Shutdown() Else MsgBox(48, @ScriptName, "No Bitmap found on Clipboard") EndIf If you copy a local window to the clipboard via Alt+PrtScn the above works fine. If you copy a window in an RDP session via Ctrl+Alt+Minus it saves the image, but the left-hand edge appears to contain a few pixels sliced off the right-hand side of the bitmap (see two attached images for examples; one good, one bad). If you paste directly into MSPaint, the image appears correctly, so the clipboard contents is good. It seems to be the process of converting the bitmap handle to an image file via GDIPlus which corrupts it (though I may be wrong about this).
I've tried inspecting the contents of the clipboard via the _ClipBoard_EnumFormats example and I've noticed the clipboard from the RDP session contains a couple more formats;
Clipboard formats ..: 3 Clipboard format 1 .: Bitmap Clipboard format 2 .: DIB Clipboard format 3 .: DIB V5 RDP:
Clipboard formats ..: 5 Clipboard format 1 .: DataObject Clipboard format 2 .: DIB Clipboard format 3 .: DIB V5 Clipboard format 4 .: Ole Private Data Clipboard format 5 .: Bitmap However the _ClipBoard_GetDataEx function is specifying the $CF_BITMAP constant for the format, which both instances contain, so I'm not sure the extra formats have any impact?
I've tried using a combination of _ClipBoard_GetDataEx($CF_DIB) and _GDIPlus_BitmapCreateFromMemory in an effort to write the binary directly to a file, instead of using a bitmap handle, however this doesn't appear to work and just returns a zero and doesn't set @error to anything, which isn't covered in the help file (a failure should return a zero and set the @error level to something).
I've hunted around the forums and tried everything I can think of. I can normally figure most things out without posting but I've been dipping in and out of this script for a few months now and have finally thrown in the towel and must ask you guys for help, which isn't a decision I take lightly. Your help is, as always, greatly appreciated.