AutoItObject UDF

[wraithdu]

I'll post to the issue tracker when I get a chance, but I'll post the bug here now.

The Linked List example does not decrement the list size in the remove method.

[Melba23]

trancexx,

Following on from wraithdu's post above, the first line of au3.UserUdfs.properties should read:

au3.keywords.user.udfs=

and then it follows the same structure as all the other properties files with \ as the EOL marker and a TAB at the beginning of each new line.

M23

[doudou]

Really non-trivial!

You should though have mentioned somewhere that use of inline binary DLL (which is the default) requires AutoIt 3.3.4, as 3.3.2 and earlier would crash at start-up:

AutoitObject.au3 (1195) : ==> String missing closing quote.

[ProgAndy]

Oh, we didn't consider older AutoIt-versions

Edited February 23, 2010 by ProgAndy

[doudou]

Oh, we didn't consider older AutoIt-versions

There are worse things

Some lazy people out there just skip every 2nd version update ... and get then what they deserve: compiler errors!

[trancexx]

There are some functions that are written for 3.3.6 or 7 or 8

Obviously they are left out.

[wraithdu]

I've update my previous post with better calltip\highlighting info.

[wraithdu]

Bah... just realized you can't use this from within any callbacks. I had this problem when I was first writing my ToggleButton UDF. If you try to call a callback from within a callback (like using SendMessage from a mouse hook to a subclassed button -> two AutoIt callbacks, or calling an AutoItObject method from a subclassed button's window procedure) then AutoIt freaks out and deadlocks.

Dammit... my UDF was so much prettier and easy to use in OO.

[trancexx]

Bah... just realized you can't use this from within any callbacks. I had this problem when I was first writing my ToggleButton UDF. If you try to call a callback from within a callback (like using SendMessage from a mouse hook to a subclassed button -> two AutoIt callbacks, or calling an AutoItObject method from a subclassed button's window procedure) then AutoIt freaks out and deadlocks.

Dammit... my UDF was so much prettier and easy to use in OO.

The problem is described in the FAQ.

Btw, should this work (answer on blind)?

#include "AutoitObject.au3"

; First callback
$hCallback1 = DllCallbackRegister("_FirstFunction", "none", "")
$pCallback1 = DllCallbackGetPtr($hCallback1)

; Second callback
$hCallback2 = DllCallbackRegister("_SecondFunction", "none", "")
$pCallback2 = DllCallbackGetPtr($hCallback2)


;_FirstFunction()
__Au3Obj_PointerCall("none", $pCallback1)


Func _FirstFunction()
    MsgBox(64, "First", "From first function first time.")
    __Au3Obj_PointerCall("none", $pCallback2)
    MsgBox(64, "First", "From first function second time.")
EndFunc 

Func _SecondFunction()
    MsgBox(64, "Second", "From second function.")
EndFunc

[wraithdu]

No, it shouldn't. I was going to put together a similar reproducer. Just got home...

[wraithdu]

But apparently it does...

I guess my deadlock has to do with the callbacks blocking AutoIt's message queue, while your example (and my new test) don't have a message queue to block.

So, no AIO with message processing callbacks... shame.

*snip*

Edited February 24, 2010 by wraithdu

[monoceres]

Come on! Read the FAQ

[wraithdu]

I did read... and apparently forgot since yesterday.

Anyway, I understand the ByRef limitation, but that doesn't mean a ptr/hwnd type should be illegal. What if I want to store a window handle or some pointer in a property? I can't do $obj.prop = GUICtrlGetHandle($id). Yes, I could do Number($ptr), but that's beside the point.

Edited February 24, 2010 by wraithdu

[monoceres]

It's not our fault. The COM-error you're getting is thrown by autoit immediately, before control reaches AutoItObject. It seems that autoit simple doesn't have any code to handle pointers (which really is no different from integers, just different flags).

Annoying to say at least.

Edit: There is a ticket on the subject.

Edited February 24, 2010 by monoceres

[wraithdu]

Huh, bummer. Well, nothing to be done at the moment then.

[UberNuss]

Eureka!

I remember discussing with DaleHolm about this sort of functionality for AutoIt. He said AutoIt would probably never have it. As a famously lesser nerd than he is, I did not argue against his prediction, but only sighed that it can never be.

Top job!

I wonder, would AutoItObject be useful for database construction - and what would be the pro's and con's to this use of AutoItObject ?

[wraithdu]

I found something puzzling regarding the callback deadlocks I was experiencing. For whatever reason, I can successfully call a method in my subclassed button's window procedure as long as I call it from the Switch statement for a specific message, such as the WM_LBUTTONUP case. However if I try to call the same method as the first line of the callback (before the Switch statement), then it deadlocks.

That doesn't make sense to me. Calling a method from anywhere within the callack should have the same result, right?

[trancexx]

I found something puzzling regarding the callback deadlocks I was experiencing. For whatever reason, I can successfully call a method in my subclassed button's window procedure as long as I call it from the Switch statement for a specific message, such as the WM_LBUTTONUP case. However if I try to call the same method as the first line of the callback (before the Switch statement), then it deadlocks.

That doesn't make sense to me. Calling a method from anywhere within the callack should have the same result, right?

I guess only someone who knows how the callbacks are implemented in AutoIt could give you the answers you seek.

How would you implement it?

That code I posted above. What if I somewhere in it do something like this:

$tBin = DllStructCreate("byte[96]", $pCallback1)
ConsoleWrite(DllStructGetData($tBin, 1) & @CRLF)

Well, I tried that and got this:

0x558BEC83EC10895DF4BA48F003038955FCBA58F003038955F88B4A0C83F900742B83C2308D5D088B421083F804740E8B03890283C3048B03894204EB048B03890249740883C30483C218EBDB8B55FC52B80809E300FFD08B5DF48BE55DC3040

I have no idea what I'm getting there

For example I could assume it's something I could organize into something like this:

expandcollapse popup

55
8BEC
83EC10
895DF4
BA48F00303
8955FC
BA58F00303
8955F8
8B4A0C
83F900
742B
83C230
8D5D08
8B4210
83F804
740E
8B03
8902
83C304
8B03
894204
EB04
8B03
8902
49
7408
83C304
83C218
EBDB
8B55FC
52
B80809E300
FFD0
8B5DF4
8BE5
5D
C30400

But then again, what's that???

Maybe if I split it in some kind of logical blocks:

expandcollapse popup

-FIRST BLOCK-
55
8BEC
83EC10
895DF4
BA48F00303
8955FC
BA58F00303
8955F8
8B4A0C
83F900
742B
83C230
8D5D08
-SECOND BLOCK-
8B4210
83F804
740E
8B03
8902
83C304
8B03
894204
EB04
-THIRD BLOCK-
8B03
8902
-FOURTH BLOCK-
49
7408
83C304
83C218
EBDB
-FIFTH BLOCK-
8B55FC
52
B80809E300
FFD0
8B5DF4
8BE5
5D
C30400

What if I add comments...

-FIRST BLOCK-
55           push ebp
8BEC         mov ebp, esp
83EC10       sub esp, 010
895DF4       mov dword[ebp-0C], ebx
...

I don't know. It's above me. I don't even know what that means.

Nevertheless I could, considering conditions, switch execution to another thread:

expandcollapse popup

#include <WinAPI.au3>
#include "AutoitObject.au3"

$hGui = GUICreate("")
$hButtonMsgBox = GUICtrlCreateButton("Msgbox", 100, 100, 100, 30)
$hButtonCall1 = GUICtrlCreateButton("Call", 100, 300, 100, 30)
GUISetState(@SW_SHOW, $hGui)


; First callback
$hCallback1 = DllCallbackRegister("_FirstFunction", "none", "")
$pCallback1 = DllCallbackGetPtr($hCallback1)


; Second callback
$hCallback2 = DllCallbackRegister("_SecondFunction", "none", "")
$pCallback2 = DllCallbackGetPtr($hCallback2)

Global $hThread

While 1
    Switch GUIGetMsg()
        Case -3
            Exit
        Case $hButtonMsgBox
            MsgBox(64, "Title", "Text")
        Case $hButtonCall1
            ;GUISetState(@SW_HIDE, $hGui)
            $hThread = _Thread_PointerCall($pCallback1) ; call, but this time in another thread
            ;_WinAPI_WaitForSingleObject($hThread)
            Beep(1200, 1200)
            ;GUISetState(@SW_SHOW, $hGui)
    EndSwitch
WEnd


Func _FirstFunction()
    MsgBox(64, "First", "From first function first time.")
    _SecondFunction()
    MsgBox(64, "First", "From first function second time.")
EndFunc

Func _SecondFunction()
    MsgBox(64, "Second", "From second function.")
EndFunc



Func _Thread_PointerCall($pAddress)
    Local $aCall = DllCall("kernel32.dll", "ptr", "CreateThread", _
            "ptr", 0, _
            "dword", 0, _
            "ptr", $pAddress, _
            "ptr", 0, _
            "dword", 0, _
            "dword*", 0)
    Return $aCall[0]
EndFunc

What's happening to original thread (and messages) while the another one is running?

Edited February 24, 2010 by trancexx

[James]

This is amazing! I'm re-writing some of the code I've written before to include AU3O (?) and it's been fun! It's weird using Object like code in AutoIt, but such awesomness

Cheers so much for this

James

[JRowe]

Maybe AUOO? Got a wolf howl thing going on, there.