Leaderboard

.. but you are not going to tell us what you are really using it for...

Hawlong, Stop being evasive, we all know what you want to do - what we need to know is what are the "three programs of the same type at a time" whose memory you want to read. M23 P.S. And just to be absolutely clear - this is the Mod team determining the legality of the thread, so everyone else please keep out.

Hello @odaylton, while I am not qualified to speak about the specifics about window GUI messages, I can offer you some general advice: Case 1: It would be most efficient as you are using AutoIt's native Bit operation functions Case 2: This would actually be more relevant since the NHMDR tag (structure) is designed to contain information about a message, but how efficient or safe it is depends on how the struct is populated... Case 3: I think this would be your safest option if you want to get the Hi and Low words, as it is a direct call to the Windows API Take my advice with a pinch of salt

The other day mikeytown2 posted one post in HTTP UDF's thread that got me thinking if there is better (different) method to send requests through the HTTP protocol to HTTP servers. There is Winhttp.dll that ships with windows and that is its main purpose. I couldn't find any examples of using this dll in AutoIt, so I came up with this. Microsoft about Windows HTTP Services: Microsoft Windows HTTP Services (WinHTTP) provides developers with an HTTP client application programming interface (API) to send requests through the HTTP protocol to other HTTP servers... .. blah, blah, and so on... This is an example of getting page header: #include "WinHttp.au3" Opt("MustDeclareVars", 1) ; Open needed handles Local $hOpen = _WinHttpOpen() Local $hConnect = _WinHttpConnect($hOpen, "msdn.microsoft.com") ; Specify the reguest: Local $hRequest = _WinHttpOpenRequest($hConnect, Default, "en-us/library/aa384101(VS.85).aspx") ; Send request _WinHttpSendRequest($hRequest) ; Wait for the response _WinHttpReceiveResponse($hRequest) Local $sHeader = _WinHttpQueryHeaders($hRequest) ; ...get full header ; Clean _WinHttpCloseHandle($hRequest) _WinHttpCloseHandle($hConnect) _WinHttpCloseHandle($hOpen) ; Display retrieved header MsgBox(0, "Header", $sHeader)Everything you need to be able to use this UDF can be found at WinHttp site. Remember, basic understanding of the HTTP protocol is important to use this interface. ProgAndy, trancexx WinHttp.au3 is completely free and no one has right to charge you for it. That's very important. If you feel WinHttp.au3 was helpful to you and you wish to support my further work you can donate to my personal account via PayPal address: trancexx at yahoo dot com I will appreciate that very much. Thank you in advance! :kiss:

Version 3: Ops, you may ask, where's the version 2? The answer is, you will never see it. I skipped it to jump to version 3 directly. Why? Actually, I didn't learn M$ about that versioning The reason is, I planed to write version 2, using the new window/control handle indexing technique to eliminate all the ugly and slow loop. But when nearly finish, I feel so tired, tired of using a lots of all workaround. And finally, I decided to rewrite entire the UDF, using the direct solution, the way all other languages used, and should use. I late some day, because of some machine code (it's actually not so necessary, but if the control is doing an expensive task, like heavy drawing then passing all the Window Message to AutoIt is not a so good idea because its slow speed may result in some annoying-small-but-easy-to-figure-out problems, (like tearing as example). So I use machine code directly to pass over it. Now you have not a Stupid but a Smart UDF And it's still simple. API change: Remove a parameter from _SSCtrlHover_Register. You nolonger can attach other controls to the registered control. Use another method to do it and when you delete the control be sure to delete all the attached controls yourself. This breaks your old script. Add double click event (last 2 parameters of _SSCtrlHover_Register) Remove the _SSCtrlHover_Delete. You must manually delete yourself. It's easy with GUICtrlDelete and I decide not to duplicate this function to my UDF (be sure to delete your attached control too) This version eliminate all the odd limit of old version, include: No:longer use timer/adlib to test the control is on mouse event. Now it directly use native WinAPI method to provide a truly event-driven way. Every click is detected, every mouse hover/left, is handled perfectly. Fast and very fast. All the loop is eliminated. Machine code. Execute speed is much much improved. (read as: nano seconds instead of milliseconds ) I documented it quite well so if you want you can easily browse it and change it the way you want. Now you can use in both GUIGetMsg() loop mode or event mode. No longer setting constants like before because it works perfectly in both mode. Cheer Remark: I don't include <WinAPI.au3> and <WinAPIShellEx.au3> in my UDF, because those UDF is very large and it will consume much more memory when you run (not matter you run the 'compiled' exe, the au3 file, or the .a3x file). In the CtrlHover UDF, i included a small subset of those UDF with the same name, so if you have already included <WinAPI.au3> or <WinAPIShell.au3>, be sure to edit the UDF and comment out the corresponding region. Edit 2: Reorganize script. Fix some issues when drag too fast. Add ability to handle "click" (work RIGHT as normal button, will not fire if you only release the mouse button upon the control as some UDF use MouseUp event) Add a helper method to check if MouseUp event is click event or not. Add compability function to call as normal UDF (with first letter is underscore). Edit 1: Add some function descriptions as JS's advice. Thank you I also changed script name (shorter) and modify the register function so it may be called with less parameter. From now on, the function name and calling syntax will be fixed. OK, I know there is the famous "GUICtrlOnHover" UDF already in this forum, and many people have used it and enjoyed it! But the UDF didn't work as I expected . So I wrote an UDF myself, as much simple as possible, and it works out of the box It has some advantages compare to the old GUICtrlOnHover.au3 It creates the normal button behavior. When you press primary mouse button in the control and begin to drag, it do not set other controls to "hover" state. Faster. I try to add 2k controls. When mouse change from one control to another, it only take about 25ms to handle. In idle state (mouse cursor is not over any control), the cost is ignorable with < 0.1ms. Compare with GUICtrlOnHover UDF takes about 3ms when mouse cursor is over the control, but in idle state, it takes about 35ms. (I do not know why) (That is, because I tested script with overlapped controls. GUICtrlOnHover rely on WinAPI function WindowFromPoint(), which return the first created control (the control with is overlapped any others), but my script rely on GUIGetCursorInfo() which return the last created control - which is the most nested control in Windows). So my script need to check entire 2k control, but GUICtrlOnHover return the first element. I will wait for information about GUIGetCursorInfo() to decide that my UDF should use WinAPI function instead of the native function. In the normal usecase and controls is not overlapped, my UDF is far faster. Edit: Add a setting constant, make you ability to choose use WindowFromPoint() or GUIGetCursorInfo(). Default to the WinAPI function) Faster time to create/ register control. Native AutoIt. No Callback. The only DllCall I use is to get parent window of a control. Wonder why AutoIt do not have a similar function. Found a new bug #2899. If someone can ad more functinal to WinGetHandle("[LAST]"), it should be great Edit: Use some other WinAPI call to provide workaround for issue with GUIGetCursorInfo. Smaller size, about 280 lines compare with about 400 lines of GUICtrlOnHover. More simple, more easy to use. No more than 120 characters in one line. No annoying jumping when scroll the UDF Support event mode to detect mouse down event. But it doesn't work with overlay control. So you cannot have a control (with event) over another control. (use $_BGUIGETCURSORINFOFIX const setting to get rid of this). It seems that it's a AutoIt bug, the GUIGetCursorInfo return a useless control id when controls overlapped. Its not the same with the control received with WindowFromPoint(), or the control which fire event (anyone can confirm it's a bug? Or it's a special feature? ) ( I open a new Trac Ticket here: #2900) Current limit: Mouse down Almost all mouse event is currently detected by timeout (this is why the script called Simple and Stupid, but every UDF I found in this forum also use this method). You can set a smaller timeout to catch the mouse, but sometimes its annoying. Edit: Default changed to 30ms timeout, it should be fast enough to detect any click! You can also change to use event mode to detect click better! Otherwise, it works like a charm. Try it and happy with it Example: Callback function #include "SSCtrlHover.au3" GUICreate(@AutoItVersion) $idLbl1 = GUICtrlCreateLabel("Label 1", 5, 5) SSCtrlHover_Register($idLbl1, "FnNormal", 0, "FnHover", 0, "FnActive", 0, "FnClick", 0) $idLbl2 =GUICtrlCreateLabel("Label 2", 5, 35) SSCtrlHover_Register($idLbl2, "FnNormal", 0, "FnHover", 0, "FnActive", 0, "FnClick", 5) GUISetState() While GUIGetMsg() <> -3 Sleep(10) WEnd Func FnNormal($idCtrl, $hWnd, $vData) ConsoleWrite(@CRLF & "Normal/Leave " & $idCtrl) EndFunc Func FnHover($idCtrl, $hWnd, $vData) ConsoleWrite(@CRLF & "Hover " & $idCtrl) EndFunc Func FnActive($idCtrl, $hWnd, $vData) ConsoleWrite(@CRLF & "Active " & $idCtrl) EndFunc Func FnClick($idCtrl, $hWnd, $vData) ConsoleWrite(@CRLF & "CLICK! " & $idCtrl & " - " & $hWnd & " - " & $vData) EndFunc You can use it with GUICtrlSetImage to provide a "hover button" effect Version 1: SSCtrlHover.au3 Version 3: SSCtrlHover.zip

Hi, try to use some "old fashioned"-DOS-Software, i.e. from http://www.retroarchive.org/garbo/pc/keyboard/index.html I would try "AutoKey". It "sends" Keystrokes to a Program. Am I right, that the program starts via the Autoexec.bat? Then you could wait with the DOS-Command CHOICE /T timeinseconds https://en.wikipedia.org/wiki/Choice_(command) And then you could try to "send" an ESC via the AutoKey.com to terminate your configuration program...... Good old DOS-Day´s? 20 Years ago i would have said: "Yeahhhhhh", but now i like my Mouse, my WIN10 and last but not least...AutoIt ;-)

Using Send isn't ideal, since the script will fail if the window loses focus. But sometimes you have to make due with a less than optimal solution.

Hawlong, We are not stupid - we all know that Paint is not the program with which you want to interact. So last chance - what are you actually trying to do? M23

I think "Cheat engine" tells us what he tries to accomplish ...

Yeah what are you trying to accomplish ?

@Hawlong If you could be more precise on what are you trying to automate, then we can suggest you more (appropriate) solutions

You can use Run to execute mspaint.exe and it would return the PID of the process

I finally solved this, by using some kind of while loop with _BlockInputEx This at the start #include <BlockInputEx.au3> HotKeySet("{ESC}", "_Quit") _BlockInputEx: _BlockInputEx(1, "{ESC}") and this at the end While 1 Sleep(100) WEnd Func _Quit() Exit EndFunc Exit This keeps BlockInputEx running, which keeps inputs blocked, even if you use CTRL-ALT-DELETE. Absolutely amazing. Pressing ESC terminates the script! Thanks for the assistance in here, it gave me inspiration!

You could just use something like: StringFormat("%02i:%02i:%02i", @HOUR, @MIN, @SEC + 1)

Recommend you use the Microsoft Office Customization Tool for configuring Microsoft Office for silent installation, some good information can be found here: https://4sysops.com/archives/office-2016-installation-customize-and-deploy/ Or Google Search Microsoft Office Customization Tool Microsoft Office Setup.exe admin

Just by checking MSDN (https://docs.microsoft.com/en-us/office/vba/api/excel.iconsetcondition) and following the examples I found there

I see there is a thread where you can set the text, I bet you can get the text in such a way? _UIA_action("204022.mainwindow","setvalue using keys","hello world") maybe _UIA_action("YourApp","getValue") YES, i looked in the UIWrappers.au3, there is an 'getValue' you should be able to use!

I'm trying to save the current active tab to an ini, then later when the gui is redrawn, set the active tab to what was saved in the ini but I can't seem to figure it out. #include <GUIConstantsEx.au3> Global $htab, $curtab $1 = InputBox("Enter Tab 1 Name", "Enter a Name for Tab 1", "Tab1") $2 = InputBox("Enter Tab 2 Name", "Enter a Name for Tab 2", "Tab2") $3 = InputBox("Enter Tab 3 Name", "Enter a Name for Tab 3", "Tab3") IniWrite(@WorkingDir & "\pldata.ini", "Tab", 1, $1) IniWrite(@WorkingDir & "\pldata.ini", "Tab", 2, $2) IniWrite(@WorkingDir & "\pldata.ini", "Tab", 3, $3) $tab1 = IniRead(@WorkingDir & "\pldata.ini", "Tab", 1, "Tab1") $tab2 = IniRead(@WorkingDir & "\pldata.ini", "Tab", 2, "Tab2") $tab3 = IniRead(@WorkingDir & "\pldata.ini", "Tab", 3, "Tab3") $curtab=IniRead(@WorkingDir & "\pldata.ini","curtab",1,$tab1) $main = GUICreate("Program Launcher", 350, 446, -1, -1) $htab=GUICtrlCreateTab(2, 2, 346, 426) $win = GUICtrlCreateTabItem($tab1) $win2 = GUICtrlCreateTabItem($tab2) $win3 = GUICtrlCreateTabItem($tab3) GUICtrlCreateTabItem("") GUISwitch ($main, $curtab) GUISetState(@SW_SHOW) While 1 $msg=GUIGetMsg() If $msg=$GUI_EVENT_CLOSE Then $curtab=GUICtrlRead($htab) IniWrite(@WorkingDir & "\pldata.ini","curtab",1,$curtab) GUIDelete() Exit (1) EndIf WEnd

Thank you much! I figured there was an easy way, I was so busy looking for a function, I missed the additional parameters.

1. Your current way doesn't even work in theory. GUISwitch() needs a control id, and you give it the index. You should have set the advanced parameter of GUICtrlRead(). See GUISwitch(), GUICtrlCreateTabItem() and GUICtrlRead() in the helpfile. 2. Read the page for GUICtrlCreateTabItem() in the helpfile again. Notice the second remark? So to fix you script, change to: GUICtrlCreateTabItem("") GUICtrlSetState($curtab, $GUI_SHOW) GUISetState(@SW_SHOW) And voila!

I wrote some functions including UTF-8 conversion Func _URIEncode($sData) ; Prog@ndy Local $aData = StringSplit(BinaryToString(StringToBinary($sData,4),1),"") Local $nChar $sData="" For $i = 1 To $aData[0] ; ConsoleWrite($aData[$i] & @CRLF) $nChar = Asc($aData[$i]) Switch $nChar Case 45, 46, 48 To 57, 65 To 90, 95, 97 To 122, 126 $sData &= $aData[$i] Case 32 $sData &= "+" Case Else $sData &= "%" & Hex($nChar,2) EndSwitch Next Return $sData EndFunc Func _URIDecode($sData) ; Prog@ndy Local $aData = StringSplit(StringReplace($sData,"+"," ",0,1),"%") $sData = "" For $i = 2 To $aData[0] $aData[1] &= Chr(Dec(StringLeft($aData[$i],2))) & StringTrimLeft($aData[$i],2) Next Return BinaryToString(StringToBinary($aData[1],1),4) EndFunc MsgBox(0, '', _URIDecode(_URIEncode("testäöü fv"))) Edit 2012: Fixed bug in _URIEncode, removed debug output

I swear anyone who understands this stuff is clinically insane.

Welcome to the forums! Try this: Send('+{F10}')