Jump to content
ProgAndy

AutoItObject UDF

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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


Public_Domain.png.2d871819fcb9957cf44f4514551a2935.png Any of my own code posted anywhere on the forum is available for use by others without any restriction of any kind

Open spoiler to see my UDFs:

Spoiler

ArrayMultiColSort ---- Sort arrays on multiple columns
ChooseFileFolder ---- Single and multiple selections from specified path treeview listing
Date_Time_Convert -- Easily convert date/time formats, including the language used
ExtMsgBox --------- A highly customisable replacement for MsgBox
GUIExtender -------- Extend and retract multiple sections within a GUI
GUIFrame ---------- Subdivide GUIs into many adjustable frames
GUIListViewEx ------- Insert, delete, move, drag, sort, edit and colour ListView items
GUITreeViewEx ------ Check/clear parent and child checkboxes in a TreeView
Marquee ----------- Scrolling tickertape GUIs
NoFocusLines ------- Remove the dotted focus lines from buttons, sliders, radios and checkboxes
Notify ------------- Small notifications on the edge of the display
Scrollbars ----------Automatically sized scrollbars with a single command
StringSize ---------- Automatically size controls to fit text
Toast -------------- Small GUIs which pop out of the notification area

 

Share this post


Link to post
Share on other sites

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.

UDFS & Apps:


DDEML.au3 - DDE Client + Server[*]
Localization.au3- localize your scripts[*]
TLI.au3 - type information on COM objects (TLBINF emulation)[*]
TLBAutoEnum.au3 - auto-import of COM constants (enums)[*]
AU3Automation - export AU3 scripts via COM interfaces
TypeLibInspector

- OleView was yesterday

Coder's last words before final release: WE APOLOGIZE FOR INCONVENIENCE 

Share this post


Link to post
Share on other sites

Oh, we didn't consider older AutoIt-versions :mellow:

Edited by ProgAndy

*GERMAN* [note: you are not allowed to remove author / modified info from my UDFs]My UDFs:[_SetImageBinaryToCtrl] [_TaskDialog] [AutoItObject] [Animated GIF (GDI+)] [ClipPut for Image] [FreeImage] [GDI32 UDFs] [GDIPlus Progressbar] [Hotkey-Selector] [Multiline Inputbox] [MySQL without ODBC] [RichEdit UDFs] [SpeechAPI Example] [WinHTTP]UDFs included in AutoIt: FTP_Ex (as FTPEx), _WinAPI_SetLayeredWindowAttributes

Share this post


Link to post
Share on other sites

Oh, we didn't consider older AutoIt-versions :(

There are worse things :lol:

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


UDFS & Apps:


DDEML.au3 - DDE Client + Server[*]
Localization.au3- localize your scripts[*]
TLI.au3 - type information on COM objects (TLBINF emulation)[*]
TLBAutoEnum.au3 - auto-import of COM constants (enums)[*]
AU3Automation - export AU3 scripts via COM interfaces
TypeLibInspector

- OleView was yesterday

Coder's last words before final release: WE APOLOGIZE FOR INCONVENIENCE 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

♡♡♡

.

eMyvnE

Share this post


Link to post
Share on other sites

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 by wraithdu

Share this post


Link to post
Share on other sites

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 by wraithdu

Share this post


Link to post
Share on other sites

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 by monoceres

Broken link? PM me and I'll send you the file!

Share this post


Link to post
Share on other sites

Eureka! :mellow:

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 ?


Das Häschen benutzt Radar.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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 :mellow:

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

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:

-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:

#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 by trancexx

♡♡♡

.

eMyvnE

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...