AutoItObject UDF

[AdmiralAlkex]

Yes it did, arrays are ok to use with beta.

I know for sure because it was me who wrote the code that fixed it .

Ah yes, I would assume that's #1565. Good to know.

Edit: This answer from FAQ is weird

Q. Why isn't it possible to pass arguments as ByRef to methods? This is a limitation within AutoIt. It's not possible to overcome this problem by directly calling the member functions, but that goes against the OO thinking and will not be covered here (use common sense).

Edited September 6, 2011 by AdmiralAlkex

[trancexx]

Edit: This answer from FAQ is weird

I don't know who wrote that, monoceres maybe. I haven't seen him for quite some time now. He probably meant to say something smart with that. Didn't turn out particurarly smart.

[JFX]

The memory loading of AutoItObject_X64.dll cause a crash on the Window 8 Pre-Release.

Using:

_AutoItObject_StartUp(True)

works

[trancexx]

The memory loading of AutoItObject_X64.dll cause a crash on the Window 8 Pre-Release.

Using:

_AutoItObject_StartUp(True)

works

Can you switch to and run script from there to confirm?

[Digisoul]

how can i release the object which i created with _AutoItObject_ObjCreateEx ?

here is a code example :

$oSWF = _AutoItObject_ObjCreateEx(@ScriptDir & "\flash.ocx", $sCLSID_ShockwaveFlash, $sIID_IShockwaveFlash)
GUICtrlCreateObj($oSWF, 0, 0, $Width, $Height)

after completing the work i am simply doing $oSWF = 0 & GuiDelete() but its not releasing the object and the threads of flash.ocx are growing on each call. These objects are also not releasing the other file resources.

Is there any way to forcibly release it ?

[trancexx]

how can i release the object which i created with _AutoItObject_ObjCreateEx ?

here is a code example :

$oSWF = _AutoItObject_ObjCreateEx(@ScriptDir & "\flash.ocx", $sCLSID_ShockwaveFlash, $sIID_IShockwaveFlash)
GUICtrlCreateObj($oSWF, 0, 0, $Width, $Height)

after completing the work i am simply doing $oSWF = 0 & GuiDelete() but its not releasing the object and the threads of flash.ocx are growing on each call. These objects are also not releasing the other file resources.

Is there any way to forcibly release it ?

It should release the object. How do you confirm that object is not released?

The only thing that's not released is dll handle because there is no way to do that with the current object implementation.

What you could try is call _WinApi_GetModuleHandle($sYourDllHere) and then manually release that handle by calling FreeLibrary.

Edited September 19, 2011 by trancexx

[Digisoul]

It should release the object. How do you confirm that object is not released?

I am using a swf for flash player,when i delete the window the handle of assigned video file is still in lock state with autoit program.

When i debug the whole thing then i found that every time i call the function for swf obj initialization it creates threads for flash.ocx in main program and after deleting the window; threads are still there & these threads are using the file handle.

May be i used wrong words, but this whole thing becomes a big headache, temp file is locked, consumed memory is growing and growing!

The only thing that's not released is dll handle because there is no way to do that with the current object implementation.

What you could try is call _WinApi_GetModuleHandle($sYourDllHere) and then manually release that handle by calling FreeLibrary.

I already tried this method, but it just crash the program.

I also checked flash activeX methods with TLBViewer but i didn't found any method for releasing/destroying the open handles!

[trancexx]

But what swf? Do you know for sure if swf is releasing the video file?

[Digisoul]

But what swf? Do you know for sure if swf is releasing the video file?

Sorry! i meant "swf as flv player", not sure about it, because when i delete the gui the CPU usage becomes normal, so i am just assuming that the playback is stopped.

I think i have to use AS3 ExternalInterface API to check what is going on inside the swf.

What should i do about the memory ? (The possible solution is use only 1 instance of swf object. which is a great headache, i have to redesign the whole program logic.)

[wraithdu]

It seems to me that if the swf is not releasing the file, that releasing the object will also be incomplete. Maybe you can find a way to make the swf release the file handle, then releasing the object will work properly, ie set the swf's file source to "" or 0 or something.

[Digisoul]

It seems to me that if the swf is not releasing the file, that releasing the object will also be incomplete. Maybe you can find a way to make the swf release the file handle, then releasing the object will work properly, ie set the swf's file source to "" or 0 or something.

Yes actually the swf is not releasing the file (source = 0/"" cant control this behavior, i have to use ExternalInterface to tell SWF that i close the window.), after more debugging i found that it only happens when the SWF is playing the video and i delete the GUI, if the video is completely played, i can delete the file, but the threads of flash.ocx still exists in the program and i am unable to figure out how can i release these objects/threads/dll completely to save the memory.

[Rexkix]

Please forgive a very simple question. I've got an "AutoItObject Package 1.2.8.2" directory and I don't know what do do with it.

Also, out of curisiouty, what's the relationship between the "AutoItObject.au3" file, the ".dll" files, and the C++ files in the Source directory. What are the files in the Interfaces directory about? I've never heard of ".intfc" files before. The examples appear to include AutoItObject with quote marks ("") instead of brackets (<>). How's that work?

Thanks in advance,

Edited September 24, 2011 by Rexkix

[trancexx]

Please forgive a very simple question. I've got an "AutoItObject Package 1.2.8.2" directory and I don't know what do do with it.

Also, out of curisiouty, what's the relationship between the "AutoItObject.au3" file, the ".dll" files, and the C++ files in the Source directory. What are the files in the Interfaces directory about? I've never heard of ".intfc" files before. The examples appear to include AutoItObject with quote marks ("") instead of brackets (<>). How's that work?

Thanks in advance,

After you have downloaded the package, extract AutoItObject.au3 to a folder where your scrips that uses AutoItObject are/will be.

That's all there is to it.

Dll files are alternative way of loading AutoItObject. You normally don't need them.

Interface files are interfaces definitions. Interface folder is a collection of different interface definitions. You never heard of .intfc because that never existed before.

#include "some.au3" means for AutoIt to use some.au3 found in script directory, rather than using some.au3 from default include directory. That is, if both files existed.

C++ source is included in the package because AutoItObject is open source and someone could be wondering "How the fuck this works?"

Edited September 25, 2011 by trancexx

[AdmiralAlkex]

The examples appear to include AutoItObject with quote marks ("") instead of brackets (<>). How's that work?

Just open the helpfile and go to #include, it's all explained.

[Rexkix]

After you have downloaded the package, extract AutoItObject.au3 to a folder where your scrips that uses AutoItObject are/will be.

Interesting. Looking at the examples, the only way I could get TicTacToe to run was by copying AutoItObject.au3 to the Examples folder. Normally, I put my projects each in a folder of their own. This would mean each would need their own copy of AutoItObject.au3, potentially introducing configuration management inconsistencies. I suppose I could address this by having each project use a symbolic link instead of an actual copy. Wouldn't it make more sense to put it in AutoIt's Include folder and refer to it with (<>) instead of ("")? Then it would feel like more of an integral part of the language.

In general, does its current status as an extension to the language discourage others who develop other "AutoIt middleware" extension stuff from using it in their work? Is there an AutoIt language committe that can be lobbied to add Objects as a basic feature?

Also, out of curiousity, how does AutoItObject do it's magic stuff of changing the language syntax as it does? Creators and member functions have a $this variable, and $instances have a "." operator.

Thanks for your help here and for doing such a great job developing this extension. It looks great!

[Kip]

Is there an AutoIt language committe that can be lobbied to add Objects as a basic feature?

Also, out of curiousity, how does AutoItObject do it's magic stuff of changing the language syntax as it does? Creators and member functions have a $this variable, and $instances have a "." operator.

Yes, there is an "AutoIt language committe". It's called Jon. (and all other developers)

And no, Objects will not be added as a basic feature. (In fact, it is on the NOT-to-do list)

AutoItObject does not change the syntax. It uses the build-in COM mechanism.

For more information about the not-to-do list: search the forum.

For more information about COM: helpfile, forum, google.

Edited September 25, 2011 by Kip

[Melba23]

Rexkix,

Might I suggest reading the Adding UDFs to AutoIt and SciTE tutorial in the Wiki. It explains how you can download UDFs and use the standard < > syntax to #include them in your scripts. That way you do not need to have a copy in each folder.

M23

Edit: Typnig!

Edited September 25, 2011 by Melba23

[Ascend4nt]

Interesting. Looking at the examples, the only way I could get TicTacToe to run was by copying AutoItObject.au3 to the Examples folder.

I consider this poor design, and I've seen it done numerous times. If you're going to bundle examples with a UDF, at least make sure they run without user intervention! The examples folder in this case should have each file prefix the include with a '..\' (i.e., #include "..\AutoItObject.au3").

In general, does its current status as an extension to the language discourage others who develop other "AutoIt middleware" extension stuff from using it in their work? Is there an AutoIt language committe that can be lobbied to add Objects as a basic feature?

I've used this a number of times and while it is a bit confusing at first, it adds an important missing piece to the language. With the current beta, this is now being integrated into the language itself, at least as far as true COM objects (derived from IUnknown). It might be possible to create other objects through some VTable-tweaking though - but we'll have to wait and see what becomes of the new 'ObjCreateInterface'.

[Rexkix]

Might I suggest reading the Adding UDFs to AutoIt and SciTE tutorial in the Wiki. It explains how you can download UDFs and use the standard < > syntax to #include them in your scripts. That way you do not need to have a copy in each folder.

Thanks. I also understand post #37 better now.

But I'm not quite sure where to store these things. The page you linked to advises against putting things under the AutoIt install folder because they would get overwritten during an update, presumably of AutoIt. But my SciTE and all the files mentioned in post #37 and on the page you pointed to are under %PROGRAMFILES%\AutoIt3\SciTE. That's confusing. Whatever changes I make there, I'll be sure to backup elsewhere.

I wish the install program would fix the HKEY_CURRENT_USER\Software\AutoIt v3\AutoIt entry and change the SciTE syntax files too, but there's probably good reasons why it doesn't.

It's really cool when you get it all put together. Thanks again.

[SkinnyWhiteGuy]

I've been looking at this now, seeing what all I can use it for, and so far I like it. I do have one question.

Is it possible to define a default method for an object? As in, the Scripting.Dictionary can access items using either the .Item() method, or just by calling the object directly:

$dict = ObjCreate("Scripting.Dictionary")
$dict.Item("one") = 1
$dict("two") = 2
ConsoleWrite($dict("one") & @TAB & $dict.Item("two") & @CRLF)

I would like to do that. Actually, I would like to have a hash object I could store as a Class Property, but the pointer/byref bulletin listed in the FAQ tells me that using Scripting.Dictionary itself won't work. The LinkedList example is close, and I could probably use it to build something similar, but it wouldn't have the syntax that I just asked for.

Having skimmed through all of this topic, several things popped up in my head as possible uses for this. This is really good stuff.

Thanks.