Recently Browsing 0 members
No registered users viewing this page.
Other than different methodologies, are there any differences between the two? Does one work out to be faster or more reliable than the other when deployed at scale? I'm trying out both UDFs, was curious which method is preferred by the community.
I've made a library, based on AutoItObject UDF with the goal of implementing getter and setter functionality and make it possible to define new object properties in as few steps as possible.
Thank you to @trancexx for getting me on the right track, and all users in Hooking into the IDispatch interface for the code to get me going.
If I've forgotten to add credit, please let me know
#include "AutoItObject_Internal.au3" $myCar = IDispatch() $myCar.make = 'Ford' $myCar.model = 'Mustang' $myCar.year = 1969 $myCar.__defineGetter('DisplayCar', DisplayCar) Func DisplayCar($oThis) Return 'A Beautiful ' & $oThis.parent.year & ' ' & $oThis.parent.make & ' ' & $oThis.parent.model EndFunc MsgBox(0, "", $myCar.DisplayCar) More examples: https://github.com/genius257/AutoItObject-Internal/tree/master/Examples
Edit2 (19th March 2017):
First of all, sorry about the lack of updates on this project. I always start too many projects and end up ignoring old projects, if I run into problems ^^'.
So I've started moving my AutoIt scripts to GitHub. I will still post the most recent script version here.
I tried to implement the code in this topic:
Firstly, i have no idea how these lines of code work but meanwhile i noticed that:
; Everytime autoit wants to call a method, get or set a property in a object it needs to go to ; IDispatch::GetIDsFromNames. This is our version of that function, note that by defining this ourselves ; we can fool autoit to believe that the object supports a lot of different properties/methods. Func __IDispatch_GetIDsFromNames($pSelf, $riid, $rgszNames, $cNames, $lcid, $rgDispId) ... EndFunc The problem is i ran into is that some object calls didn't go through IDispatch::GetIDsFromNames.
Here is the code to replicate what i'm mentioning:
I followed the example in the topic and tried to do the same thing with method .Documents (line 193) and .Open (line 194) but didn't get the same result because .Documents was being passed through __IDispatch_GetIDsFromNames while .Open didn't.
$Au3_CallByName = 'Documents' Local $oDoc = $oAppl.Au3_CallByName $Au3_CallByName = 'Open' $oDoc = $oDoc.Au3_CallByName($sFilePath, $bConfirmConversions, $bReadOnly, $bAddToRecentFiles, $sOpenPassword, "", $bRevert, $sWritePassword, "", $iFormat) Console outputs:
==> The requested action with this object has failed.: $oDoc = $oDoc.Au3_CallByName($sFilePath, $bConfirmConversions, $bReadOnly, $bAddToRecentFiles, $sOpenPassword, "", $bRevert, $sWritePassword, "", $iFormat) $oDoc = $oDoc^ ERROR Is there any workarounds to solve this?
while I created an example script to generate and execute a function during runtime, I stumbled across a neat way to share data between running autoit scripts.
This is done using the amazing magic of AutoItObject_Internal . (You'll need at least Version 3.0.0 of AutoItObject_Internal)
Using this UDF, you can create a shared data storage, basically an empty "AutoitObject_Internal-"Object which you can then use to write / read data Inline. no set/get methods, just
#include "AutoItSharedData.au3" $oShare = _AutoIt_SharedData_CreateOrAttach("MyCustomID") $oShare.some_data = 'foo' and you're done. any other script accessing this data will have to do:
#include "AutoItSharedData.au3" $oShare = _AutoIt_SharedData_CreateOrAttach("MyCustomID") ConsoleWrite($oShare.some_data & @LF)
Basically it's Larsj's Implementing IRunningObjectTable Interface, but you dont have a Dictionary, but an IDIspatch Object instead.
There are already a bunch of IPC options available - and this is another one.
Example Script 1
Example Script 2
To test: run Example Script 1, Then run example Script 2.. or the other way around.
Example Script 3
To test: run Example_sharedata3.au3.
/Edit: Please note that there's a limitation with the Running object table :
The Script accessing a variable first, will be the "server" for this variable. This means, access to that variable from other scripts should only be possible, as long the "server" script is running! Use appropriate Object Error handlers in case you don't want the surviving "clients" to crash.
Feedback and/or improvements appreciated
Removed need for AutoItObject, as AutoItObject_Internal now comes with ROT support Added UDF Header Fixed typo on "#include AutoItObjectInternal.au3" -> "#include AutoItObject_Internal.au3" Added ObjGet() after registering the object fails (in case 2 programs tried to register the same ID simultaneously) Updated Examples & zip archive. Cheers,
hello autoit team
i tried to create a SPVoice object
when i create the object and tried to use this function SetAlertBoundary
it gave me an error
please where is the problem?
here is the code
local $o_Sapi_OBJ = ObjCreate("SAPI.SpVoice") if IsObj($o_Sapi_OBJ) then $o_Sapi_OBJ.SetAlertBoundary("SPEI_PHONEME") endIf note i got the function name from microsoft web site
i have windows10