Recently Browsing 1 member
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?
so in https://www.autoitscript.com/forum/topic/193254-solved-ipc-between-system-and-user/ I asked around about IPCs and got all the answers I was looking for.
Now the question is: what IPC is most "resilient" on an overwhelmed PC, meaning, the CPU is at 100%, memory is top out and, as is always, need to rely on the IPC.
..and all this happened because I open over 100 GUIs at once 😜
..but it happens sporadically on low CPU or memory demand anyways.
..should I sleep() some time before running another instance ?
I did not know if to make the question in technical, chat, ..or here. So it's here.
Since you will ask what I've tried, I've used the IPC from the Fork UDFish ( WM_COPYDATA that can do Admin/user mix ) and the FMIPC file mapping, that work under the same conditions.
So, how do you handle IPC if it fails ?
I was in need of an IPC (Interprocess communication) between system, admin and user levels, and ended up writing this UDF to suit my wantings.
Hope you find it useful too.
Works from WinXP/Server2003 to the now current Win10/Server2016.
It communicates between any mix of x32, x64, Admin, User.
In the zip file, there is the UDF and an example: FMIPC(v0.2018.04.04).zip
Special thanks to @RTFC for the help in the support forum