AutoItObject UDF

[Hammerfist]

A reasonable proposal to the developers of this library - can you implement the support for member classes, along with data and member functions? like a "$aObject.Style.Color = 0x000000"

[ProgAndy]

A reasonable proposal to the developers of this library - can you implement the support for member classes, along with data and member functions? like a "$aObject.Style.Color = 0x000000"

There is noting to implement. Create a property style (probably as read only) and set another object as its value. Edited July 4, 2012 by ProgAndy

[Hammerfist]

ProgAndy, thanks!

[Andreik]

I want to store a DllStruct as a property of an object and seems to not work. I know there's _AutoItObject_DllStructCreate() but I don't know if it's useful for what I tried to do.

I have this object

Func Text()
    Local $oClass = _AutoItObject_Class()
    With $oClass
        .AddMethod("Create","__text_create")
        .AddMethod("SetAlign","__text_setalign")
        .AddMethod("SetColor","__text_setcolor")
        .AddMethod("SetPos","__text_setpos")
        .AddMethod("GetPos","__text_getpos")
        .AddMethod("SetText","__text_settext")
        .AddMethod("GetText","__text_gettext")
        .AddMethod("Destroy","__text_destroy")
        .AddProperty("Family",$ELSCOPE_READONLY,0)
        .AddProperty("Font",$ELSCOPE_READONLY,0)
        .AddProperty("Rect", $ELSCOPE_READONLY,0)
        .AddProperty("Format",$ELSCOPE_READONLY,0)
        .AddProperty("Brush",$ELSCOPE_READONLY,0)
        .AddProperty("Text",$ELSCOPE_PUBLIC,"")
    EndWith
    Return $oClass.Object
EndFunc

Method Create it's suppose to set Rect property.

And a method of another object that have as parameter an object like above. This is the implementation of this method:

Func __graphics_drawtext($oSelf,$oText)
    _GDIPlus_GraphicsDrawStringEx($oSelf.Graphics,$oText.Text(),$oText.Font(),$oText.Rect(),$oText.Format(),$oText.Brush())
EndFunc

I'm not sure how to use _AutoItObject_DllStructCreate() in implementation of Create method and to use it then in __graphics_drawtext(). _AutoItObject_DllStructCreate() will return an object and I need a struct. Sure I can create a struct in __graphics_drawtext() function and then set all members or to call _GDIPlus_RectFCreate() but it's not quite performant since __graphics_drawtext() it's called very often. It would be nice to can create a struct one time and then use it where is needed. Any ideas how I can do that?

[trancexx]

DllStruct can't be set as property. There are more than one reason for that, firstly AutoIt version you run doesn't know what to do with DllStruct type when passed to COM code, secondly AutoItObject wouldn't know what to do with it even if it could get it.

_AutoItObject_DllStructCreate creates IDispatch object, not DllStruct. The beauty of such object is its default property - being pointer to allocated memory space (the thing you need).

Default property (or method if you like) is accessed by adding empty set of brackets after the object variable:

$oImObject = _AutoItObject_DllStructCreate(...)
$vImDefaultPropertySlashMethod = $oImObject()

[Andreik]

Thank you lady, it's work nice.

[FaridAgl]

I have some difficulties using _AutoItObject_DllOpen.

The following script doesn't work for me, however it's from the help file:

Opt("MustDeclareVars", 1)

#include "AutoItObject.au3"

Global $oError = ObjEvent("AutoIt.Error", "_ErrFunc")
Func _ErrFunc()
ConsoleWrite("COM Error, ScriptLine(" & $oError.scriptline & ") : Number 0x" & Hex($oError.number, 8) & " - " & $oError.windescription & @CRLF)
EndFunc

_AutoItObject_Startup()

Global $oUser = _AutoItObject_DllOpen("user32.dll", "MessageBoxW dword(hwnd;wstr;wstr;dword);")

$oUser.MessageBoxW(0, "Text for the box", "Title", 48 + 3)

COM Error, ScriptLine(14) : Number 0x8002802F - Function not defined in specified DLL.

[FaridAgl]

However it doesn't work right now (For me), I can clearly imagine what it should do and I have a suggestion (Maybe a feature request).

Would be nice and useful if we can define which element of the returned array is important to get, and then instead of getting an array in result, it gives a simple variable.

For now, it is like this:

Global $oUser = _AutoItObject_DllOpen("user32.dll", "MessageBoxW dword(hwnd;wstr;wstr;dword);")
Global $result = $oUser.MessageBoxW(0, "Text for the box", "Title", 48 + 3)
ConsoleWrite($result[0])

Would be great, if there was something like this:

Global $oUser = _AutoItObject_DllOpen("user32.dll", "MessageBoxW 0 dword(hwnd;wstr;wstr;dword);")
Global $result = $oUser.MessageBoxW(0, "Text for the box", "Title", 48 + 3)
ConsoleWrite($result)

Hope the AutoItObject team understand what I mean.

BTW, I'm moving to this UDF from the last night, it's interesting.

[FaridAgl]

Hmmm, sorry for bumping a thread multiple times and triple posting, but am I posting in a wrong place? Maybe there is no such a support here or maybe even the AutoItObject's project is left behind or whatever.

Just want to know should I even wait for some kind of reply?

Edited January 8, 2013 by D4RKON3

[trancexx]

Don't worry about bumping and no, it's not wrong place.

AutoItObject project is left behind, like you said. No one works on it any more as far as I know, but that doesn't mean it's outdated. See, AutoIt language hasn't developed enough to render AutoItObject completely obsolete.

Some of the functionality AutoItObject has I added to the core language already, the rest is still there waiting for people to use it through this unique set of UDFs.

The main problem here is the lack of community intelligence. I must also say that AutoIt is really a victim of wrong... sorry, bad decisions made by people with not enough healthy ambition found on all positions, even the highest. All that lead to clear and obvious brain drain. Today it's very hard to find someone in this community who's capable for sane, intelligent discussion about advanced and complex programming issues, problems or simply concepts. And so here we are, like it or not.

Enjoy learning.

Edited January 8, 2013 by trancexx

[jaberwacky]

If it makes you feel better:

Unfortunately, I lack the tech skills to help in the development of this UDF in any way. As you may know I have switched to using this UDF almost exclusively. So, trancexx, I gather from your post that AutoIt will one day maybe have the same capabilities that this UDF offers and maybe then some?

[trancexx]

^^One day there will be no borders, no boundaries, no flags and no countries and the only passport will be the heart. Also, one day the Sun will explode.

[FaridAgl]

So, while we are waiting for that day, can you please take a look at my previous post? :|

[AdmiralAlkex]

So, while we are waiting for that day, can you please take a look at my previous post? :|

That works for me using an older version (1.2.4.0 I think?) but fails with 1.2.8.2. I don't see anything in ScriptBreakingChanges.txt to explain it, so no idea why.

[trancexx]

That works for me using an older version (1.2.4.0 I think?) but fails with 1.2.8.2. I don't see anything in ScriptBreakingChanges.txt to explain it, so no idea why.

The change was on AutoIt side. But to be completely honest it was really AutoItObject's (my) fault.

The problem was that previously AutoIt would keep method's name used to call IDispatch::GetIDsOfNames alive all the way through the IDispatch::Invoke. I saw that and used that string's pointer (instead of copying it) to speed things up when looking for the exported function inside AutoItObject's implementation of IDispatch::Invoke. At one point Jon decided that keeping that string alive is not necessary (very much correct) and AutoIt code is changed so that before AutoIt calls IDispatch::Invoke that string is destroyed, memory freed. The result of that is that AutoItObject no longer had valid string to work with.

This was compensated with AutoItObject 1.2.8.3. The change wasn't script breaking, it was more script un-breaking and the issue is seen for combination of newer AutoIt and several AutoItObject versions up until mentioned 1.2.8.3.

Edited January 9, 2013 by trancexx

[AdmiralAlkex]

<Text>

This was compensated with AutoItObject 1.2.8.3. The change wasn't script breaking, it was more script un-breaking and the issue is seen for combination of newer AutoIt and several AutoItObject versions up until mentioned 1.2.8.3.

That makes sense.

Are you going to share the mentioned 1.2.8.3 with us?

[trancexx]

That makes sense.

Are you going to share the mentioned 1.2.8.3 with us?

I see no point going back.

The whole project is open source. Anyone willing to work on it is wellcome.

[AdmiralAlkex]

I see no point going back.

The whole project is open source. Anyone willing to work on it is wellcome.

My checkout of your repository is rev. 258. Was that the latest before Origo went down? I don't know how often I SVN Updated it...

I see that rev. 258 is already marked 1.2.8.3. I'm no expert in c++ but I see there is some changes from 1.2.8.2 (rev 257) in the area you spoke of, and it does seem to work with _AutoItObject_DllOpen().

Why was it never posted? Mind if I do post it?

[trancexx]

Do you have script called PackageCreator.au3 and mpress.exe in that folder? If yes then you should be able to create AutoItObject.au3 correctly.

[AdmiralAlkex]

PackageCreator is there but no mpress. I will play around with it.

Edit: Filesize too low

Edit2: CHM is missing, how do I build that?

Edit3: saw HelpFileCreator, looking at it now

Edit4: I know your Windows username now

Edit5: Complains about not being able to compile Origo. I don't know what that parameter is for so ignoring it.

Edited January 13, 2013 by AdmiralAlkex