Leaderboard

I added functionality to enumerate the available devices on the system In doing so I discovered that you get in to a use after free situation if you try to create an interface more than once from the same device pointer. The device pointers are actually pointers to pointers (ptr**) so even though the underlying pointer is still valid you no longer have access to it. To remedy this The UDF now passes DeviceIds from the user facing functions and only converts to device pointers as they are ready to be used

Deye, I can "quick scroll" and click on any label without any problem. Is this the complete script you are actually running or is there something else that might interfere? Have you thought of using Opt("TrayIconDebug") to see where the script is hanging? That might offer a clue as to what is happening. As to writing debugging functions - you can always write your own: Use _GUIScrollBars_GetScrollPos($hWnd, $SB_VERT) to get the scrollbar position Use the $bRegisterMsg when generating the scrollbars to prevent the UDF from automatically registering the various messages and write your own handlers. which you can toggle as required M23

@nacerbaaziz Well... as it works fine on my PC, it seems to be a dead end. Here, Open goes to Open, Save goes to Save, Move goes to Move. No need to provide screen copies, that's the best I could do @Nine Hey buddy, thanks for the appreciation If you check the function _GUICtrlMenu_TrackPopupMenu() found in the include file <GuiMenu.au3>, you'll notice that there is also a call to the dll in the UDF : Local $aResult = DllCall("user32.dll", "bool", "TrackPopupMenu", "handle", $hMenu, "uint", $iFlags, "int", $iX, "int", $iY, "int", 0, "hwnd", $hWnd, "ptr", 0) In fact, there a 2 similar functions at MSDN and it's a bit puzzling : TrackPopupMenu and TrackPopupMenuEx . This is what I read at this adress : https://stackoverflow.com/questions/1546026/whats-the-difference-between-the-trackpopupmenuex-and-trackpopupmenu-windows-ap Question : ======== What's the difference between the TrackPopupMenuEx and TrackPopupMenu windows APIs? I tested TrackPopupMenuEx and TrackPopupMenu APIs and they do the same thing: displaying a menu at the cursor's position. The source codes are the same, you just have to add or erase the "Ex" at the end of the names of these APIs. Why two APIs for the same action? Note: TrackPopupMenu crashes my app in runtime when used on an image control, while TrackPopupMenuEx works ok. TrackPopUpMenu seems to have no sense. Answer 1 : ======== They are pretty similar functions but the big difference is that TrackPopupMenuEx allows you to specify a rectangle that the popup menu won't appear over (to have one that doesn't obscure what you need to see). Thats about it as far as i can see. Answer 2 : ======== According to the documentation, there are some subtle differences: TrackPopupMenu has a nReserved parameter TrackPopupMenuEx takes a LPTPMPARAMS for the last parameter, but TrackPopupMenu takes a CONST RECT* (which is ignored) So, they have a different number and type of parameters with different meanings - which would explain why your app is crashing when you change the call. So I don't know why the "TrackPopupMenu" call found in _GUICtrlMenu_TrackPopupMenu() ends with "ptr", 0) when it seems that this last parameter could be related to TrackPopupMenuEx (?) This is what MSDN says about the last parameter of the 2 functions : TrackPopupMenu : prcRect Type: const RECT* Ignored. TrackPopupMenuEx : lptpm Type: LPTPMPARAMS A pointer to a TPMPARAMS structure that specifies an area of the screen the menu should not overlap. This parameter can be NULL. Concerning the GUICtrlCreateDummy(), yes I knew it could work, but I always find it funny to create a control which size is 1 pixel, very funny to find it, like an Easter egg or a kind of pixel...search Nine, if you could be kind enough to run my 2nd script on your computer, does it work at your place ? It works for me but not at OP's. Thanks.

Many especially new and modern-style applications cannot be automated with classic code. You need UI Automation code that has been Microsoft's automation platform for the last 15 years. See Using UI Automation Code in AutoIt. Then use one of the spy tools to check if UIA-code can identify the controls in the window. Add a new post if you need more help.

@nacerbaaziz, Please Tidy your code and use AutoIt3 in stead of plain text in the CodeBox when posting sourcecode. Thanks Jos

Wrong format also...

... and SciTE doesn't run elevated? Do you compile the script as x64 or x86? To check at which statement it is waiting: Add the following statement in your script, compile, run and hover of the TrayIcon to see which statement it is "hanging". Opt("TrayIconDebug", 1) ;0=no info, 1=debug line info Let us know what you find. Jos

That doesn't make sense: it's like trying to convert hamburgers to oak trees. The Pascal (Pa) is a unit of pressure (N/m² or Newton per square meter) while a voltage is expressed in Volt (V equivalent to W/A [Watt per Ampère]), all in the SI system. Dimensional equation for Pa is L⁻¹ M T⁻² which is very different from the V which is L² M T⁻³ I⁻¹. The device often used to convert pressure to voltage is a strain jauge.

I reinvented the wheel This has already been described in the wiki

Quite easy #include <OutlookEX.au3> Global $oItem Global $oOutlook = _OL_Open() _OL_ErrorNotify(2) $oItem = _OL_ItemCreate($oOutlook, $olMailItem, "", "", "Subject=TestMail", "Body=TestBody") If @error <> 0 Then Exit MsgBox(16, "OutlookEX UDF: _OL_ItemCreate Example Script", "Error creating mail. @error = " & @error & ", @extended = " & @extended) $oItem = _OL_ItemRecipientAdd($oOutlook, $oItem, Default, $olTo, "John.Doe@gmx.com") ; Recipient For $oAccount In $oOutlook.Session.Accounts If $oAccount.SMTPAddress = "mail.address@company.com" Then ; SMTP address of the desired sender $oItem.SendUsingAccount = $oaccount ExitLoop EndIf Next _OL_ItemSend($oOutlook, $oItem) _OL_Close($oOutlook)

Probably a few ways but I would use a message. If a script starts and finds that a previous script is running then it sends a message to that script and quits. The first instance can then do whatever you want when it gets the message. #include <misc.au3> #include <sendmessage.au3> #include <winapi.au3> $RecoverGui = _WinAPI_RegisterWindowMessage("MySpecialRecoverThing");get an unallocated message number, or get the number previously allocated to that string by a previous instance If _Singleton("hgtfredsws_underoveranything", 1) = 0 Then ;MsgBox(262144, "already", "one running") $hw = WinGetHandle("nothing much here") If @error = 0 Then _SendMessage($hw, $RecoverGui, 1);tell the first script to wake up EndIf Exit EndIf traysetstate(2) $g = GUICreate("nothing much here") GUISetState() GUIRegisterMsg($RecoverGui, "Mywakeup") While 1 $msg2 = GUIGetMsg() Switch $msg2 Case -3 Exit case -4 traysetstate() EndSwitch WEnd Func Mywakeup($hG, $iMsg, $wPar, $lPar) If $wPar = 1 Then; we have been told to restore GUISetState(@SW_RESTORE, $g);now you can use your GuiSetState traysetstate(2); and you can use your TraySetState EndIf EndFunc ;==>Mywakeup