SEuBo

Hi Nine, contrary to what I've said in the first post about "the first script accessing a variable": My best guess is that because Test2.au3 is the last script to assign any value within $oShare, it becomes the "Server" for this IDispatch. Even though the behaviour isn't really consistent. I'd have to dig into that. Potential workarounds: 1) Add Sleep(100) as last line of Test2.au3, like so: #include <AutoItSharedData.au3> $oShare = _AutoIt_SharedData_CreateOrAttach("MyCustomID") Do Sleep(10) Until $oShare.Request $oShare.Response = @MSEC Sleep(100) 2) OR: Add Error-Handler into Scripts, like so: #include "AutoItSharedData.au3" $oShare = _AutoIt_SharedData_CreateOrAttach("MyCustomID") $oError = ObjEvent("AutoIt.Error", _ErrorHandler) $oShare.Request = @MSEC Do Sleep(10) Until $oShare.Response MsgBox(64,"",$oShare.Request & "/" & $oShare.Response) func _ErrorHandler($oObject) SetError($oObject.number) EndFunc I'll investigate this later today. Cheers,

Hey frank10, those are unfortunately limitations of the AutoIt Parser, as far as I understand. I guess you have no chance, but to use a temporary variable. Regarding the direct access of Array-Elements for writing, there is a potential workaround, which is still not pretty. We could "fake" a method for all the Array data. This would be done by replacing your AutoItSharedData.au3 with the following file (for testing purposes:) Instead of ;~ $oShare.arr[1] = 5 ; NO you could then write: $oShare.arr(1) = 5 Not great, but at least something.

Last try to push this.

It may be that I don't fully understand the library yet. I assumed that using an Accessor, I could only have one single parameter and could access other properties only by using the .parent-property. that really sounds like it could become troublesome. I will watch out for this when digging deeper into this topic. Yes, I copied that behaviour in my version of the Invoke method. Did you take a look at Accessing AutoIt Variables from LarsJ? (I am sure you did). I will play around a bit more to see if I can get the behaviour I want. If you could take a look at the following script and the custom Invoke and tell me how I could get the return Value of method1, I would be pleased. No problem at all - I think I could work around everything using setters/getters and just accessing the properties directly. I just see huge potential with this UDF and I want to make defining and calling "regular" methods more easy. That would also allow some kind of inheritance - or at least traits. This library deserves way more attention - but I feel like it need's to be more "accessible" and more generalized.

Does noone have an idea? I just can't understand why it's not working, because I figured if I drag and drop something from the explorer (instead of outlook), the GetData()-Method returns an IStorage-Interface (still to be implemented.). With outlook it just fails... Can't get my head around that. Ideas appreciated!

🤩 Oh my god. I can't believe it was such a stupid error. /Edit: And also thank you for the other explanation.

Hi @genius257, Do we have a chance to make this method call work withouth the extra paranthesis? ($oObject.Method1)("Test") #include <AutoItObject_Internal.au3> #include <Array.au3> #AutoIt3Wrapper_Run_Au3Check=n Local $aArray[3] = [1, 2, 3] $oObject = IDispatch() $oObject.Method1 = _method1 $oObject.Method2_with_byref = _TestMethodByref ; Test Method1 ($oObject.Method1)("Test") $oObject.Method1("Test2") ; Test Method 2 _ArrayDisplay($aArray) ($oObject.Method2_with_byref)($aArray, "New Value") $oObject.Method2_with_byref($aArray, "Aw, Shit") _ArrayDisplay($aArray) ;MsgBox(0,"",VarGetType($oObject.Method1)) ;MsgBox(0,"",VarGetType($oObject.Method1("vargettype"))) Func _method1($vParam) MsgBox(0,"",$vParam) EndFunc Func _TestMethodByref(ByRef $aData, $sText) ReDim $aArray[UBound($aArray) + 1] $aArray[UBound($aArray)-1] = $sText EndFunc I tried to play with the Invoke Function and in an seperate $DISPATCH_METHOD section under the $DISPATCH_PROPERTYGET, I managed to get the arguments from rgvargs but i'm not sure on how to proceed and invoke the actual function. I have now added a new section for $DISPATCH_METHOD to the Invoke()-Function. It's near the bottom and begins with: If BitAND($wFlags, $DISPATCH_METHOD) = $DISPATCH_METHOD Then I've also changed the lines for $DISPATCH_PROPERTYPUT and $DISPATCH_PROPERTYGET (I think the BitAnd wasn't really correct.) I didn't manage to get the functions return value, and ByRef parameters still don't work except when using the extra parenthesis I wanted to get rid of, see below. i assume that is because with the parenthesis, it's 'accessing' the method member, thus receiving the function ptr, thus letting AutoIt handle the Byref because it's not tunneled through COM. ($oObject.Method2_with_byref)($aArray, "New Value") ; works with ByRef $oObject.Method2_with_byref($aArray, "Oh No!") ; doesnt work Any Ideas on Return value & ByRef? /Edit2: or is there another way to define/call methods which I didn't see?

It does, and it's mentioned in the Help File under "Controls". I would be delighted if you could check if the quotation is correct when you're on the other machine. Here's an working example with paint, so the error lies probably within the Window Title ("Mixer"), which could find the wrong window - or your $controlInstance value. $iPID = Run("mspaint") $hWnd = WinWait("[CLASS:MSPaintApp]") ControlSend($hWnd,"","","^e") $hPopup = WinWait("[CLASS:#32770]") ControlClick($hPopup, "", "[CLASS:Button; INSTANCE:6]") Sleep(1000) ControlClick($hPopup, "", "[CLASSNN:Button7]") Sleep(1000) ControlClick($hPopup, "", "[CLASSNN:Button"& 8 &"]") Sleep(1000) $ten = 10 ControlClick($hPopup, "", "[CLASSNN:Button"& $ten &"]") Sleep(1000) $eleven = '11' ControlClick($hPopup, "", "[CLASSNN:Button"& $eleven &"]") Sleep(1000) ControlClick($hPopup, "", "Button"& "6") Sleep(1000) ControlClick($hPopup, "", "Button"& '7') Sleep(1000) ProcessClose($iPID)

Thanks for you kind words. I didn't do much but to stumble accross this (Even a blind squirrel finds a nut once in a while ) but I am glad you like it! All credits go to @genius257 for AutoItObject_Internal and of course to the original AutoItObject-Team for their great effort.

If you #include a .au3 file in your script, the included file will become part of the 'main' script. - #Include <Filename.au3> is basically just a short way of telling AutoIt to "read text in Filename.au3 and insert all lines here". All files you included with #include will be part of your .exe automatically. How you actually "include" the functionality inside your GUI highly depends on how your function scripts are set up. If they are standalone-scripts, to perform data you could just FileInstall(...) and Run(...) them. Please see the Help File for autoitscript.com/autoit3/docs/intro/running.htm for details. If they are actual function collections, you can just call those functions in your GUI's "Message Loop" - that is where you handle the button clicks. Here's an example of a Script with 2 simple buttons which would call functions from two different include files:

New Version. Since AutoItObject Internal now comes with ROT support, I removed the need for AutoItObject. No Dlls anymore, and most notably: 64-Bit support. Archive in first post updated.

I am not sure if I am reading that correctly, but shouldn't be there less quotes? Global $classNNString = "[CLASSNN:FlapsCheckbox" & $controlInstanceString & "]"

Hey there, Thanks again for the response - and apologies that my answer is a bit late. My understanding is now the following, please correct me: In my C++ code, I am currently not actually "using" the dll file, since I am including the sapnwrfc.h (which is the function definition) and the sapnwrfc.lib (which is the actual function "coding"?). -- Or is the C++ code still "including" the functions but the logic resides in sapnwrfc.dll and sapnwrfc.lib is just some kind of placeholder? I think I've got that. The problem is, that even a simple DLLOpen(...) with the sapnwrfc.dll from autoit doesn't work. I didn't even get to try to call a function from it. What is the reason for this? Is there some kind of difference between C or C++ DLLs? or are some DLL's just for internal use? so then I would "re-route" from my C method call directly into the DLL, so to say? Again - a lot of noobish questions. Cheers,

Hey! Thanks for the reply. That's too bad - I actually was hoping for an outlook professional like you to jump in and solve this mystery. I know that I could work around the issue by using your OutlookEx UDF; on drop, I'd just save the active mails to a temp file. But it would be so awesome to build a more general solution which would support all kind of Drag&Drop Sources. Maybe someone else has a bright idea! I've read through the msdn documentation again and again, but I can't figure it out. CFSTR_FILECONTENTS CFSTR_FILEDESCRIPTOR If anyone sees the issue in the code from the first post - feel free to speak up

Does anyone still have that file and could share it again? Original download link is broken.