Leaderboard

Correct... So hence my whole answer! 😏

Well i mean these directives, but filled in correctly. the proper syntax is in the helpfile that comes with the full SciTE4Autoit3 installer/zip file. Those last 2 lines in the quoted part are wrong and should point to the proper full path&exe name for those programs. You also find the proper directive for the autoit directory in the helpfile, and that is really all you need. Check the console output in case there are still issues as that will explain what is going wrong.

It need the aut2exe in the directory one level up by default. Add the directive for the autoitdirecory to hardcode that and things should work.

I have found AutoIT to be very useful in automating some of the older programs that we use, but I am now trying to work out how to automate newer programs that use the Windows Forms - such as WindowsForms10.Window.8.app.0.2bf8098_r13_ad1 I have read through the manual, but do not find anything on this there. I have also done some reading on the forum and have found material that looks useful, but I am not familiar with this and some of the threads look a little old. Please could someone update me on what the latest status is on this? Are there any plans to provide wrappers to the UI Automation controls, similar to those already provided for ListView, ComboBox, etc? How would I go about making a menu selection with such a system? If people are not using AutoIT for this kind of automation, then what are they using instead? Similar threads: '?do=embed' frameborder='0' data-embedContent>> - 2011 '?do=embed' frameborder='0' data-embedContent>> - 2008 '?do=embed' frameborder='0' data-embedContent>> - 2012 Other questions if you have time... What is the difference between MSAA mode and UI Automation? If I am using "Inspect.exe", how do I identify what information that I need to send a command to the control? Sorry - lots of questions - I am very much finding my way around this.

Indeed, that's what I've been using as a workaround. The idea of this post was to let folks here know of the existing problem and who knows, maybe come up with a better solution for the Process.au3 code going forward. I'm just one user and I was lucky enough to rewrite the code more efficiently before finding out that the include file used the same (but restricted to where the function was used) code, but once more people are confronted with this, a faster alternative (if possible, of course) would probably be needed. The obvious one would be to include getting the associated process list in the implementation of WinList() itself, otherwise similar scenarios to mine would make the existing _ProcessGetName() unusable in terms of speed, depending on the sleep interval. Sure thing! Here is the .au3 code (uncommenting the existing comments as well as commenting out the ProcessList() line and the For loop would switch to the slow built in solution): #NoTrayIcon #include <WinAPI.au3> ; Slow Alternative: #include <Process.au3> #include <SendMessage.au3> AutoItSetOption("WinTitleMatchMode", -2) Func SendBang($szBang) Local Const $hWnd = WinGetHandle("[CLASS:RainmeterMeterWindow]") If $hWnd Then Local Const $iSize = StringLen($szBang) + 1 Local Const $pMem = DllStructCreate("wchar[" & $iSize & "]") Local Const $pCds = DllStructCreate("dword;dword;ptr") Local Const $WM_COPYDATA = 0x004A DllStructSetData($pMem, 1, $szBang) DllStructSetData($pCds, 1, 1) DllStructSetData($pCds, 2, ($iSize * 2)) DllStructSetData($pCds, 3, DllStructGetPtr($pMem)) _SendMessage($hWnd, $WM_COPYDATA, 0, DllStructGetPtr($pCds)) EndIf EndFunc Func GetResult() Local $Action = $CmdLine[1], $Separator = $CmdLine[2], $Interval = $CmdLine[3] Do Local $Output = "" Local $WList = WinList() Local $PList = ProcessList() Local $WTitle, $WHandle, $WClass, $WState, $WPosition, $WX, $WY, $WW, $WH, $PID, $PName For $i = 1 To $WList[0][0] $WTitle = $WList[$i][0] $WHandle = $WList[$i][1] If $WHandle Then $WClass = _WinAPI_GetClassName($WHandle) $WState = WinGetState($WHandle) $WPosition = WinGetPos($WHandle) $WX = $WPosition[0] $WY = $WPosition[1] $WW = $WPosition[2] $WH = $WPosition[3] $PID = WinGetProcess($WHandle) $PName = "" ; Slow Alternative: $PName = _ProcessGetName($PID) For $j = 1 to $PList[0][0] If $PList[$j][1] = $PID Then $PName = $PList[$j][0] Next $Output = $Output & $WTitle & @TAB & $WClass & @TAB & $WHandle & @TAB & $WState & @TAB & $WX & @TAB & $WY & @TAB & $WW & @TAB & $WH & @TAB & $PID & @TAB & $PName & $Separator EndIf Next SendBang(StringReplace($Action, "$Output", $Output)) Sleep($Interval) Until $Interval < 0 EndFunc GetResult() And here is the .ahk v.1 code, for comparison (I know it isn't needed here, but that's why I pursued both, to choose the one that fares better in as many aspects as possible): #NoTrayIcon #Requires AutoHotkey v1.0 DetectHiddenWindows, On SendBang(ByRef szBang) { TargetWindowClass := "RainmeterMeterWindow" iSize := (StrLen(szBang) + 1) * (A_IsUnicode ? 2 : 1) VarSetCapacity(Cds, 3 * A_PtrSize, 0) NumPut(1, Cds) NumPut(iSize, Cds, A_PtrSize) NumPut(&szBang, Cds, 2 * A_PtrSize) SendMessage, 0x4a, 0, &Cds,, ahk_class %TargetWindowClass% return ErrorLevel } GetResult() { Action := A_Args[1], Separator := A_Args[2], Interval := A_Args[3] Loop { Output := "" WinGet, windows, List Loop, % windows { WHandle := windows%A_Index% WinGetTitle, WTitle, % "ahk_id " WHandle WinGetClass, WClass, % "ahk_id " WHandle WinGetPos, WX, WY, WW, WH, % "ahk_id " WHandle WinGet, PID, PID, % "ahk_id " WHandle WinGet, PName, ProcessName, % "ahk_id " WHandle WinGet, WState, MinMax, % "ahk_id " WHandle Output := % Output WTitle "`t" WClass "`t" WHandle "`t" WState "`t" WX "`t" WY "`t" WW "`t" WH "`t" PID "`t" PName Separator } SendBang(StrReplace(Action, "$Output", Output)) Sleep Interval If (Interval < 0) Break } } GetResult() You can disregard the rest of the code if you want, it's just sending a message to another program (Rainmeter), where I can display these in a "skin" / "widget" and send various other messages to desired windows from this list via a WindowMessagePlugin in order to control some music player, some HWiNFO sensor window and other similar productive / entertainment apps in the system (yes, I know I can do this directly from an .au3 / .ahk script, but like this I don't have to bother with creating the interface anymore). The chosen script is run with 3 parameters from the said application, i.e. a specific action / "bang" / command to send data back to the skin, a separator that's usually the newline character, and the interval at which this list is sent to the skin in milliseconds (-1 if only one pass through the outer loop is desired).

Not sure why you like to use the commandline versus the available directives? is the info coming from an external process?

You have now been given 3 options to do what you want to do so your next post WILL contain the information about what you have tried and isn't working as we seem to be going around in circles.

It is pretty simple: When you like to ONLY use aut2exe you ONLY use Commandline options or #PRAGMA directives in your source ode. When you want to use AutoIt3Wrapper, you can use either #PRAGMA and/or #AutoIt3Wrapper directives in the source and run the same command line as generated by full version of the SciTE4AutoIt3 package. so simply run the compile one time from SciTE and copy&paste the shown command line in the outputpane. Using the INI for setting the AutoIt3Wrapper is something I would not recommend as that is only there for backwards compatibility and #AutoIt3Wrapper directives are so much clearer!

Like I already told you, if you have listen, you would have seen this :

Yes it does... the #pragma directive is read by aut2exe. The #Autoit3Wrapper directives makes the changes after the exe is created when done by AutoIt3Wrapper.

Not sure if this will help, but here is a similar question,

E4A Version 5.5 is released. This is a minor update, mainly providing more support for binary operations on matrices of integer type, notably in file I/O, bitwise & logical operations on a single matrix cell value, CwiseScalarOps with logical operators (+ parsed value), reversing the bit-order in all cells of a matrix (part) with new CwiseUnaryOp operator #37 ("reverseBits"), and Rowwise Pack/Unpack functions for converting integer cells to/from 32 individual bits, 4 bytes, or 2 words. A new test script (#32: BitAndByteOps.au3 in the .\EigenTest subdirectory) illustrates various features. Full details can be found in the History page of the online Help (note that as of this version, the .chm Helpfile is no longer supported/present; just download the latest online Help if you need an offline version). Hope it helps.

Single/double quotes in PowerShell have different rules, https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_quoting_rules?view=powershell-7.1 Cmd also has rules which can conflict with PowerShell command unless escaped, PowerShell commands that have a mix of double/single quotes can be more difficult, usually requires trial and error to get the correct syntax.

Well I guess I get to answer my own question. I found a hint in this thread regarding changing the double quotes to single and vice versa. This seems to work: $sPSCmd = "Get-ProvisionedAppxPackage -Online | Where-Object { $_.PackageName -match 'xbox' } | ForEach-Object { Remove-ProvisionedAppxPackage -Online -AllUsers -PackageName $_.PackageName }" RunWait(@comspec & ' /c powershell.exe -nologo -executionpolicy bypass -WindowStyle hidden -noprofile -command "&' & $sPSCmd & '"') No idea why flopping the quotes on the variable to double and the inner quotes to single fixes this... I swear I've been working for over an hour on this.

ToolTip is working in PowerShell so probably it is a limitation of VBScript ?

I mentioned before; already in a previous life I already created this example. Which I forgot about 🤥 The CLSID and TLBID you can find in the manifest file in the ZIP file included. Or you can use the TyoeLib Viewer created by the COM guru trancexx The rest you can find on the internet regarding the COM Free stuff. Microsoft.Windows.ActCtx object https://docs.microsoft.com/en-us/windows/win32/sbscs/microsoft-windows-actctx-object

Wow, that's amazing! 👍 I've read various things about "Registration-Free Activation of COM Components" here (Step 6 and 7) and here, but I haven't figured out what data to put in. For example, where did you get the CLSID and the TLBID? Or how do you get the data for: Set o = CreateObject("Microsoft.Windows.ActCtx") ? I have extended your code a little bit, so that you can use the VBScript file "Test 2.vbs" independent of the path. Attached is the file "2021-01-08 ptrex RegFree COM approach 2.zip", in it is 1 version for Win x32 and 1 version for Win x64. On Win x64 you can drag the "Test 2.vbs" in the x32 folder to the shortcut to wscript.exe x32 (in SysWOW64). Displaying a ToolTip does NOT work, but starting and closing Notepad does. So we are one step closer to the goal. 2021-01-08 ptrex RegFree COM approach 2.zip

@Professor_Bernd I got something running using the RegFree COM approach. At least is tested on my Win10 using VBScript and PowerShell This is how you can test it : 1. UNREGISTER the COM object first using regsvr32 /u AutoItX3_x64.dll 2. Create a MANIFEST file using this content, and save it using this EXACT name : AutoItX3.sxs.manifest 3. Create a Test.vbs using this content : 4. Copy the 3 files to the C:\Temp folder : - AutoItX3_x64.dll - AutoItX3.sxs.manifest - Test.vbs 5. Run this Test.vbs

I've tested the code here: #AutoIt3Wrapper_UseX64=Y ; Error if not AutoItX3_x64.dll is registered with regsvr32: The server threw an exception. Code: 80010105 ;#AutoIt3Wrapper_UseX64=N ; Error if not AutoItX3.dll is registered with regsvr32: The server threw an exception. Code: 80010105 #include "IRunningObjectTable.au3" Global $hActiveX ; Load the ActiveX Module If @AutoItX64 Then $hActiveX = DllOpen(@ScriptDir & "\AutoItX3_x64.dll") Else $hActiveX = DllOpen(@ScriptDir & "\AutoItX3.dll") EndIf ;MsgBox(0,"x64",@AutoItX64) ; Object identifiers Global Const $sCLSID = "{1A671297-FA74-4422-80FA-6C5D8CE4DE04}" Global Const $sIID = Default ; Or use keyword Default if you want to use the Default interface ID ; Error Monitoring Global $oError = ObjEvent("AutoIt.Error", "_ErrFunc") Func _ErrFunc() ConsoleWrite("! COM Error ! Number: 0x" & Hex($oError.number, 8) & " ScriptLine: " & $oError.scriptline & " - " & $oError.windescription & @CRLF) Exit EndFunc ;==>_ErrFunc ; Create the hActiveX Local $oAutoIt = ObjCreate($sCLSID, $sIID, $hActiveX) DllClose($hActiveX) If $oAutoIt = 0 Then MsgBox(16,"Error", "Could not create the object, Common problem ActiveX not registered.") ; ROT object ROT_RegisterObject( Default, "DictionaryData" ) ; Default => Object = Dictionary object $oROTobj = ObjGet( "DictionaryData" ) ; Get the ROT object, the Dictionary object $oROTobj( "oAutoIt" ) = $oAutoIt ; Key/item pair, Key = "oAutoIt", Item = $oAutoIt ; Run WBScriot code RunWait( 'wscript.exe "tst02.vbs"' ) ;RunWait( @AutoItExe & " /AutoIt3ExecuteScript " & '"tst02Cli.au3"' ) ; The error occurs in both VBScript and AutoIt client code $oAutoIt = "" with both a VBScript client: (tst02.vbs) Dim oROTobj, oAutoIt Set oROTobj = GetObject( "DictionaryData" ) 'Get the ROT object, the Dictionary object Set oAutoIt = oROTobj( "oAutoIt" ) 'Get oAutoIt object from the key/item pair in the Dictionary object through the key value 'This will create a tooltip oAutoIt.ToolTip "This is a tooltip", 450, 200 oAutoIt.Sleep 3000 'Sleep to give tooltip time to display and an AutoIt client: (tst02Cli.au3) $oROTobj = ObjGet( "DictionaryData" ) $oAutoIt = $oROTobj( "oAutoIt" ) $oAutoIt.ToolTip("This is a tooltip", 450, 200) $oAutoIt.Sleep(3000) It seems that the ROT object doesn't work properly unless the relevant AutoItX3 dll is registered with regsvr32.

@LarsJ Again, with your tip, I feel like this can work! 👍 I think I understand your planned approach. Actually, it should be quite simple: In AutoIt create a COM object from the AutoIt3.dll, then create a COM object with a dictionary and store the AutoIt3.dll object as a key value in the dictionary. Both objects are registered in the ROT. After that in PSPad's VBScript you only need to take the AutoIt3.dll object from the dictionary. At least that's how I imagine it. Ok, as I said in the other thread, because I want to finish my current work first, I can't really deal with this new topic until next month. I hope I may ask for help again then. In the meantime, if anyone wants to experiment with PSPad to execute instructions with the registration-free AutoIt3.dll object in PSPad's VBScript, they are welcome to use the test version in the first posting, which I'll leave online until then. Many thanks to you, LarsJ, for your valuable help!

Hello, I'm trying to use ui automation to control a 3rd party program called Ninja Trader. It's a stock charting program. It creates child charts that can be modified individually. Each chart has a popup window to enable modifications to the respective chart. I've nearly completed the automation project I've been working on for months (includes attempting to understand the ui automation process). The last challenge is to activate the popup window. It's accessed from the respective chart by right clicking on the chart. I've tried the combination of each Element Properties (has/is info), Control Patterns (element actions), and Control Pattern Properties with all the Control Pattern Methods. Most of those combinations give an error. I assumed the combination of $UIA_IsLegacyIAccessiblePatternAvailablePropertyId True (LegacyIAccessiblePattern) and DoDefaultAction() would do something. It doesn't get flagged as an error but it also doesn't do anything. I've done the same drill with both "Menu: ContextMenu" and " Pane:ScrollIViewer" as the base for ObjCreateInterface. I've included screen shots of the UIASpy results and a screen shot of the window with popup. I assumed that I could modify code that worked with menus activated by right clicking on task bar icons. I've not been able to locate code (maybe recognize it) that addresses the problem. Any pointers as to what I'm missing will be greatly appreciated. Thanks in advance.

At the moment there is no way to access .NET libraries natively... 2 Options left : 1. If this is a custom developed .NET libr. make it COM Visible as JohnOne indicated. 2. If you are looking for accessing .NET Class Libraries, you can use the PowerShell COM library as middleware... See my signature. I am looking into how we could still achieve this to access it natively. But some highly skilled forum members has already let me know that this will not be an easy task.... It could be achieved by using the ObjCreateInterface and reading a lot on MSDN ... It is NOW POSSIBLE TO ACCESS .NET Classes / THIRD PARTY ASSEMBLIES / POWERSHELL Cmdlets and MODULES See here on 'how to' Examples : All members are welcome to contribute and help in any way they can ... Rgds ptrex

I don't believe c# libraries have classic entry points like unmanaged dlls, so dllcall will not work. I think I recall you have to make your dll com visible and use as an object, you should search it, there is something on the forum about it. EDIT: .NET CLR is nowadays possible.