Leaderboard

This shouldn't be a problem if you do it by calling Invoke on object yourself. The problem could be converting arguments from AutoIt type to COM type, which AutoIt does internally for you when working with objects the usual way. Anyway for something as simple as this you could do it like this #include <ie.au3> ; Some constants used in code Const $tagIUnknown = "QueryInterface hresult(ptr;ptr*);" & _ "AddRef dword();" & _ "Release dword();" Const $tagIDispatch = $tagIUnknown & _ "GetTypeInfoCount hresult(dword*);" & _ "GetTypeInfo hresult(dword;dword;ptr*);" & _ "GetIDsOfNames hresult(struct*;struct*;dword;dword;struct*);" & _ "Invoke hresult(uint;struct*;dword;word;struct*;struct*;ptr;uint*);" Const $DISPID_PROPERTYPUT = -3 Const $DISPATCH_PROPERTYPUT = 4 Const $LOCALE_SYSTEM_DEFAULT = 0x800 Const $tIID_NULL = DllStructCreate("byte[16]") Const $tagDISPPARAMS = "ptr rgvarg;ptr rgdispidNamedArgs;uint cArgs;uint cNamedArgs;" Const $VT_I4 = 3 Const $tVARIANT = "word vt;word r1;word r2;word r3;ptr data; ptr" Const $sIID_IDispatch = "{00020400-0000-0000-C000-000000000046}" $sYourProperty = "Width" $iDesiredValue = 100 $oRegistrationInfo = _IECreate() ; just to have a "guinea pig" to experiment with ;>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ; Superposed object on top of the original one $oRegistrationInfoMy = ObjCreateInterface($oRegistrationInfo, $sIID_IDispatch, $tagIDispatch, False) ; Collect ID number of the function/property/method, whatever $tDisp = DllStructCreate("dword") $tName = DllStructCreate("ptr") $tN = DllStructCreate("wchar[" & StringLen($sYourProperty) + 1 & "]") DllStructSetData($tN, 1, $sYourProperty) DllStructSetData($tName, 1, DllStructGetPtr($tN)) $oRegistrationInfoMy.GetIDsOfNames($tIID_NULL, $tName, 1, $LOCALE_SYSTEM_DEFAULT, $tDisp) ; Tadaaa! $iDispId = DllStructGetData($tDisp, 1) ; Now build disp parameters $tDISPPARAMS = DllStructCreate($tagDISPPARAMS) $tDISPPARAMS.cNamedArgs = 1 $tDispidNamed = DllStructCreate("uint") DllStructSetData($tDispidNamed, 1, $DISPID_PROPERTYPUT) $tDISPPARAMS.rgdispidNamedArgs = DllStructGetPtr($tDispidNamed) $tDISPPARAMS.cArgs = 1 $tVar = DllStructCreate($tVARIANT) $tDISPPARAMS.rgvarg = DllStructGetPtr($tVar) ; Set desired value $tVar.vt = $VT_I4 $tVar.data = $iDesiredValue ; And call it $iRet = $oRegistrationInfoMy.Invoke($iDispId, $tIID_NULL, 0x800, $DISPATCH_PROPERTYPUT, $tDISPPARAMS, 0, 0, 0) ConsoleWrite(">>> Returned hresult = " & Hex($iRet, 8) & @CRLF) ;<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< MsgBox(0, "Info", "Press OK to exit") $oRegistrationInfo.quit

You might try this hook #include <WinAPI.au3> #include <WindowsConstants.au3> Global $hHook Local $hFunc, $pFunc, $hMod HotKeySet('{ESC}', '_Close') $hFunc = DllCallbackRegister('_MouseProc', 'lresult', 'int;int;int') $pFunc = DllCallbackGetPtr($hFunc) $hMod = _WinAPI_GetModuleHandle(0) $hHook = _WinAPI_SetWindowsHookEx($WH_MOUSE_LL, $pFunc, $hMod) While 1 Sleep(20) WEnd Func _MouseProc($iCode, $iwParam, $ilParam) If $iCode < 0 Then Return _WinAPI_CallNextHookEx($hHook, $iCode, $iwParam, $ilParam) Switch $iwParam Case $WM_MBUTTONDOWN, $WM_MBUTTONUP Return 1 ;disable EndSwitch Return _WinAPI_CallNextHookEx($hHook, $iCode, $iwParam, $ilParam) EndFunc ;==>_MouseProc Func _Close() _WinAPI_UnhookWindowsHookEx($hHook) DllCallbackFree($hHook) Exit EndFunc ;==>_Close

Letraindusoir, And the only way I can think of answering the first question is to append the variable name to its content like this: $vVariable = "VarName|12345679*9" _Expand($vVariable) Func _Expand($vVar) $aContent = StringSplit($vVar, "|") ConsoleWrite($aContent[1] & " = [" & Execute($aContent[2]) & "]" & @CRLF) EndFunc You will need a wrapper function to reassign the variable content within the script, but that is pretty trivial. M23

Letraindusoir, I do not see the connection between the 2 questions, but the second can be done easily with a RegEx: #include <Array.au3> $sString = '[["0x990033", "0xcc6699", "0xff6699", "0xff3366"]]' $aArray=_ToArray($sString) _ArrayDisplay($aArray, "", Default, 8) Func _ToArray($sText) Return StringRegExp($sText, '(?U)"(.*)"', 3) ; Array of matches EndFunc There is no error-checking in that snippet - so results on a badly formatted string are unlikely to be correct. M23

I use this to be able to write to console in any case (compiled or not): Global $CW = @Compiled ? __ConsoleWrite : _ConsoleWrite Func __ConsoleWrite(ByRef $s) Local Static $hCon = __ConsoleInit() DllCall("kernel32.dll", "bool", "WriteConsoleW", "handle", $hCon, "wstr", $s & @LF, "dword", StringLen($s) + 1, "dword*", 0, "ptr", 0) Return EndFunc ;==>__ConsoleWrite Func __ConsoleInit() DllCall("kernel32.dll", "bool", "AllocConsole") Return DllCall("kernel32.dll", "handle", "GetStdHandle", "int", -11)[0] EndFunc ;==>__ConsoleInit ; Unicode-aware ConsoleWrite Func _ConsoleWrite($s) ConsoleWrite(BinaryToString(StringToBinary($s & @LF, 4), 1)) EndFunc ;==>_ConsoleWrite I setup the SciTE console to Unicode, so that's why the last function is needed. Use it like that: $CW("some text" & @LF)

All I managed to do reliably with the callbyname function is crash AutoIt However I did manage to make call by name work It's not going to work for you I doubt because its 600 lines of code but hey I'll post it anyways So basically I recreated the method by which autoit calls members (well any com program really) its definitely beta code and it's barely tested HAVE FUN

I started this JSON library back in late 2007, because I needed a way to pass structured data between Javascript HTAs and AutoIt3 scripts. I've recently worked to get it in good enough shape to share with the AutoIt community, and while it still needs a bit more polish, the core functionality should be solid. Three files are included in the attached archive: JSON.au3 – the UDF Library itself. It includes a (very large) comment section at the top, which should provide sufficient documentation on how the various data types are encoded and decoded, as well as the various Javascript-based decoding extensions allowed (single-quoted strings, comments, etc.).JSON_Translate.au3 provides example functions for the powerful "translator" functionality. Translator functions can be used for both encoding and decoding. When encoding, it allows you to recursively convert your data from its normal format into the required data structures used by the JSON UDF library. When decoding, it allows you to convert the data in the opposite direction – from the JSON UDF library's data structures to the data structures your program normally uses. To use this functionality, you'll need to write your own translator functions, but this allows you to meet the custom needs of your own programs without having to hack JSON.au3. The examples provided in this file can probably be improved, but show one way of translating AutoIt-specific data types (such as binary and hwnd) back and forth.testJSON.au3 provides some quick examples of regular and translator-enhanced usage, which also help verify that encoding and decoding are working properly. These tests may not be comprehensive.The area needing the most work is error-handling. JSON data structures can be deeply nested, and it's tricky to make sure errors "bubble up" properly in AutoIt. (Plus, I need a flowchart to keep track of all my setError() numbers!) Thanks to Douglas Crockford of JSON.org, whose 2005 Javascript code for JSON encoding and decoding provided an excellent starting point for this library. Edit: updated to 0.9.1 on 2009-10-19 substantially updated opening commentsencoding: implemented logic to return "warning" @error flags for unsupported variable types & JSON objects with non-unique key stringsother minor fixes & tweaksJSON.7z

I'm fan of Autoit, i like very much and use it to make several programs to automate task with error log controls and windows showing information, i'ts very versatile, but i think there is no other thing like that in linux for two reasons, first and most important i'ts based on Windows Libraries and so it can interact with almost any "dll"; second in linux you don't need to use autoit, it's another programming philosophy, a open one. When i need to do things like Autoit on Windows in Linux, simply use bash and perl scripts, bash is very powerful, it's awesome, and it's not only bash, there are many commands like sed, cat, cut, grep, awk, etc... there are essential to know if you want to be a linux administrator too, as the pipes, when you know these commands, you simply don't need autoit on linux, there are even commands to show dialog box and interact with them.

Use the vkCode element from the structure $tKEYHOOKS = DllStructCreate($tagKBDLLHOOKSTRUCT, $lParam) in the callback procedure you register. This is the extended ASCII character code, and some extra codes for special keys, which you can find on MSDN after searching for vkCode. As I said I've good reason to keep my hints a bit cryptic. There's some potential here we don't want to discuss for obvious reasons.

I'd like to include a build timestamp in my AutoIt compiled executable. A build timestamp is some identification of the date and time on which the executable was compiled, and it could be displayed on a GUI element to provide definitive version information beyond a typical release version "vX.Y" label. I.e. the title of a GUI window could read "Application vX.Y by Me - build yyyy-mm-dd.hh-mm-ss" I know AutoItWrapper has a directive "#AutoIt3Wrapper_Res_Field" which allows for this type of information to be included in the resources of the compiled executable, but I don't know how to access it from within an AutoIt script. Is there a some sort of predefined constant which AutoItWrapper can replace at compile-time or is there some way to reliably read the compiled resources? Or perhaps there's another way to achieve this?

Did some searching and, through massive loops, found the very simple solution: CODE#AutoIt3Wrapper_Res_Field = Timestamp|%date% %time% If @Compiled Then MsgBox(0, "", FileGetVersion(@ScriptFullPath, "Timestamp")) Else MsgBox(0, "", "Not compiled") EndIf

Hello, I'm looking for a way to disable right clicking on a specific window. Thanks