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.

Hi there, I am trying to save an email which was dragged from Outlook onto my AutoIt Application to file. Accepting files the regular way doesn't work since Outlook seems to be using the OLE Drag&Drop. I've found the DragDropEvent UDF by @Ward, but unfortunately, it can only retreive a limited amount of Formats, so I tried my luck. Here's the UDF in case you don't want to click the Link above. Based on the UDF, I created a new Function "DragDropEvent_GetVirtualFile" (see below), that is supposed to retreive the Filecontents. I managed to successfully retreive the amount of Mails and their titles (="filenames") but I am struggling to get to the filecontents. To test for yourself: Run The script, and Drag 1 or more mails from outlook onto the button. Then check the Console-Output. The output I am getting is this (as you can see, it errors when calling IDataObj.GetData() ) $tFileGroupDescriptor.cItems: 1 $tFileDescriptorW.dwFlags: 0 $tFileDescriptorW.clsid: {00000000-0000-0000-0000-000000000000} $tFileDescriptorW.sizel: 0, 0 $tFileDescriptorW.pointl: 0, 0 $tFileDescriptorW.dwFileAttributes: 0 $tFileDescriptorW.ftFileCreationTime: 0, 0 $tFileDescriptorW.ftLastAccessTime: 0, 0 $tFileDescriptorW.ftLastWriteTime: 0, 0 $tFileDescriptorW.nFileSizeHigh: 0 $tFileDescriptorW.nFileSizeLow: 0 $tFileDescriptorW.cFileName: xxxyyyyzzzz this is a mail subject!.msg +> QueryGetData(...) => success for FileContents !> $IDataObj.GetData(...) => Error 0x80040064 I was following this example: https://www.codeproject.com/Articles/28209/Outlook-Drag-and-Drop-in-C Interestingly enough, the QueryGetData at line 226 also fails, if the format specified in line 224 does not contain TYMED_ISTORAGE. (hGLOBAL doesn't work at all). All the implementations I found online seem to work. https://github.com/tonyfederer/OutlookFileDrag https://stackoverflow.com/questions/4756845/how-to-implement-drag-drop-from-outlook-mail-or-thunderbird-to-a-delphi-form https://mycsharp.de/forum/threads/114641/outlook-anhang-per-dragdrop-in-wpf-ausle https://stackoverflow.com/questions/8709076/drag-and-drop-multiple-attached-file-from-outlook-to-c-sharp-window-form Also, this is a nice summary of the sender's perspective: https://devblogs.microsoft.com/oldnewthing/20080318-00/?p=23083 Can anyone try help me with this? I feel like I've tried everyhting. Best Regards,

Or with the standard taskmanager: on the details page, right click the column headings, "select columns", and tick "Command Line".

/Edit: I've updated the first post in regard to this. The usage scenario is create & call a function which parameters and behaviour is unkown during compile time (or startup) and can also not be determined by algorithms, because it is supposed to be programmed while the application is running. I am developing an AutoIt based ERP system together with a small local business as a prototype/first customer help them reduce costs. The entire application, and all data / functions are encapsulated in Objects (- from here on I use the word "objects" equivalent to "classes". ). There are - System objects (e.g. "Application", "Database", "ObjectBuilder", "Printer", "Mail", etc.) and - Business objects (e.g. "Material", "Materialprice", "Customer", "Salesorder", "Material Text", "Contract", "Invoice", "ContractReleaseOrder", etc.). The system objects are fixed and encapsulate everything that runs "in the background" and some very generic functionality. There will be a standard set of business objects and templates, but in general, business objects, their relations and their logics are to be created during runtime - by the user. This will be a heavily UI-guided process. Also, users are supposed to write Scripts "just-in-time", while there are looking at some data inside the application. Those Scripts shall have access to the whole Application: the screens, the data, the other objects, AutoIt Functions, the neat and the ugly bits. There is nothing worse than having a functionality somewhere that is doing exactly what you need, but you can't call it. At the moment, the Business Objects are created manually (XML files with their definition and au3 files with method coding). After those files are added (and an #include-statement was added to a collective include), I have to restart my application. Otherwise I can not access the just created include. And this is where my problem comes from: The Function sourcecode is entered by the user and it can only be called in the current application after restart (which is bad, when you already entered data on the screen, but also want a new script to run). There are a lot of workarounds for stuff like this - exposing data & functions via API and defined interfaces, etc., - NOT letting users enter code and mess with stuff, - using languages that are better suited.. But I chose AutoIt because it is amazing and I want it to be the scripting language inside my AutoIt Application. As I said: very special use-case. Just for clarification

Hey, yes you can, see example for array & object (in array) below - I think problems only really occur with DLLStructs, Pointers and Function-References. Some types (like handles) have to be Hwnd()'ed again on the other side. As far as I understood, those are internal limitations. Larsj did a great job summarizing it here (scroll down to "data types"): $aArray : Array variable type. $dBinary : Binary variable type. $bBoolean : Bool variable type. $pPtr : Int32 variable type. $hWnd : Int32 variable type. $iInt : Int32 variable type. $fFloat : Double variable type. $oObject : Object variable type. $sString : String variable type. $tStruct : Not recognized as a valid variable type. $vKeyword : Keyword variable type. fuMsgBox : Not recognized as a valid variable type. $fuFunc : Not recognized as a valid variable type. $fuUserFunc : Not recognized as a valid variable type. Example SharedData4:

Hey! As I said, it's a very very special usage scenario and I never had to use such a thing within the all my autoit life - up until now. https://www.autoitscript.com/autoit3/docs/intro/running.htm Run a script using another compiled script: Compiled.exe [/ErrorStdOut] /AutoIt3ExecuteScript file [params ...] Execute another AutoIt script file from a compiled AutoIt3 executable. Compiled.exe [/ErrorStdOut] /AutoIt3ExecuteLine "command line" Execute one line of code as with AutoIt3.exe above. This means that there is no need to have a copy of AutoIt3.exe in addition to the compiled file - the interpreter stub of the compiled file will replace it. So as long as there is at least one compiled script available, other AutoIt scripts can be run without the need to have AutoIt3.exe on the machine., either pre-installed or added via FileInstall. that is, if the script is compiled with #pragma compile(AutoItExecuteAllowed, true) as you stated, yes. but that's the default.

Hi, Because your Example wouldn't allow Variable assignments, Loops, If-Statements, etc. #include <AutoItGenFunc.au3> $oFunction = _AutoItGenFunc_CreateFunction("", _ ; <------ What are the Parameters? '' _ ; <------ What is the Sourcecode? & @LF & 'For $i = 1 to 100' _ & @LF & ' IF $i < 50 then ' _ & @LF & ' Sleep(100)' _ & @LF & ' Else' _ & @LF & ' Sleep(10) ; faster at the end.' _ & @LF & ' EndIf' _ & @LF & '' _ & @LF & ' ToolTip("Counter:" & $i)' _ & @LF & 'Next', _ "") ; <------ What should be returned? If IsObj($oFunction) Then $oFunction.Call() EndIf oh and the "why" is: I have a Complex application and users are supposed to create business objects and corresponding logic by themselfes supported by GUI easy AutoItObjects based Scripting. Logic is supposed to be entered and executed during runtime. This is my workaround until I can understand how to hook into IDispatch deep enough to dynamically load the coding directly into an AutoItObject-Object or something. This is nothing I intend to use on daily basis, but I still found it interesting enough to share, since most discussions about dynamic functions in Autoit end up with Execute(), Assign(), Eval() and it's limitations. Cheers,

Thanks @RTFC Just in to make sure I understand the approach right: I would write a C++ Dll to "wrap" the C functions that are provided in sapnwrfc.h (and thus in the sapnwrfc.dll?) ? I would define those functions as "extern c" I would compile it to DLL (e.g. "AutoItSapnwrfc"), would include the AutoItSapnwrfc.dll and sapnwrfc.dll + (probably the others?) into my autoit script folder and do the DLLCall on my AutoItSapnwrfc.dll? Is there no way to "directly" call the sapnwrfc.dll-functions? Isn't it already a dll? Sorry for the stupid questions. Thanks,

Yes, I also dont think someone already has done such a thing. It would be a highly useful thing in context of SAP & AutoIt Connectivity though. Would you have some guidance on how I would be translating those functions? I probably won't utilize the whole functionality and I assume a lot of the stuff is for backwards-compability. I'd be willing to work into that topic, but I am a bit lost with all the information available online. I am a complete C beginner so it's hard to follow some technical discussions; I barely managed to compile this simple C code and spent 3 days until I've added the right compiler and linker directives. ..This is when you appreciate the easiness of AutoIt.

Hi! I am just getting started with C and C++. I have created a pretty simple C code which is calling a dll function. When I compile and run, I get the appropriate Output. So it works fine. Now I would want to transform that to AutoIt. -> I would like to call the "RfcOpenConnection" function from AutoIt - but whatever I try with DLLCall, I can not get it to work. Can someone point me in the right direction? DLL, C Sourcecode and compiled exe are attached too large to be attached, so they're uploaded here: https://drive.google.com/file/d/12CUSsISl0mojiMCNxKjps1Sdoox3JlCX/view?usp=sharing Thanks a bunch!

If anyone is still trying to do stuff like this in 2021, I kindly point towards Sorry for reviving, but I want to give the people googling for this a better chance. I know the thread is 11 years old. Please ignore this post, if it upsets you. Cheers,