Plugins (deprecated)

[JRowe]

Mostly. There are a few notable projects that use it, like au3Irrlicht.

I've never seen a problem with using it. It's a good tool.

[FinalVersion]

I compiled the example, but Autoit gives the errors about the functions from the example.dll. And I'm using the example autoit script meant for the example.dll.

[JRowe]

We need more information if you want help. What errors are you getting? What did you compile with?

Actually, try using the preprocessor directive meant to disable the warnings thrown by unknown function names:

#AutoIt3Wrapper_plugin_funcs= _funcName1, _funcName2, _funcName3

Put that at the top of your script, with the correct demo function names.

Edited March 18, 2010 by JRowe

[FinalVersion]

No I just tried the example that comes with the SDK.

[jchd]

For some time I've been contemplating using the plugin architecture as a very convenient way to bring ad hoc fast functions with an easy to use syntax and low overhead.

I'm now at a point where I need to make a strategic choice: rely on plugins or not. Thus I'd appreciate to have informed opinions about:

1/ the perenity of plugins

2/ their ability to deal with in and out native Unicode strings.

As I understand it after spending good time reading this thread and looking at members' realizations, plugins are essentially stable and unlikely to disappear anytime soon. But their handling of Unicode is still to develop, is a non-trivial task and has low priority.

Given that what I intended to use plugins for is in large part for native strings handling, I suppose I need to stick to DllCalls.

Does that reflect the current situation?

[JSThePatriot]

For some time I've been contemplating using the plugin architecture as a very convenient way to bring ad hoc fast functions with an easy to use syntax and low overhead.

I'm now at a point where I need to make a strategic choice: rely on plugins or not. Thus I'd appreciate to have informed opinions about:

1/ the perenity of plugins

2/ their ability to deal with in and out native Unicode strings.

As I understand it after spending good time reading this thread and looking at members' realizations, plugins are essentially stable and unlikely to disappear anytime soon. But their handling of Unicode is still to develop, is a non-trivial task and has low priority.

Given that what I intended to use plugins for is in large part for native strings handling, I suppose I need to stick to DllCalls.

Does that reflect the current situation?

I'm sure you've moved forward since this post, but your understanding of where plugins are does seem to be quite correct. They are in general a low priority. They do what they do currently quite well in my opinion. They are still lacking many features and functionality, but that's understandable considering they are a low priority of the language.

GL with your endeavors,

Jarvis

[RickCHodgin]

I've created a .dll using the example.c "template" file that comes with AutoIT3. It compiles properly and everything seems to be working with the DLL.

Where do I put this plugin to be loaded by AutoIT?

I was looking for something like a plugins\ directory, but couldn't find one. Also, I see in the include\ directory there is a SQLite.au3 and SQLite.dll.au3. Is there some post-process that has to be run to convert the DLL from its native Win32 form to something AutoIT uses?

Any help would be appreciated. Thanks.

[RickCHodgin]

I'm also wondering if there's a feature (or could be) which allows AutoIT to parse a given line, such as:

foo_function($p1, $p2);

where "foo_function" is syntactically correct, but not found, and then have AutoIT automatically scan a plugins\ directory to look for .dlls that have the matching function name coded within the:

AU3_PLUGIN_FUNC g_AU3_Funcs[] = 
{
    /* Function Name, Min, Max */
    { "foo_function", 2, 2}
};

structure? This would seem to be a desirable trait, rather than explicitly calling PluginOpen().

- Rick C. Hodgin

Edited May 24, 2011 by RickCHodgin

[wraithdu]

Aside from what's provided with the SDK, PluginOpen and PluginClose are the AutoIt functions you need.

[devrandom]

Hello, there is an error in the example plugin.

Line 155:

if ( AU3_GetType(&p_AU3_Params[0]) != AU3_PLUGIN_INT32 || AU3_GetType(&p_AU3_Params[0]) != AU3_PLUGIN_INT32 )

Should be:

if ( AU3_GetType(&p_AU3_Params[0]) != AU3_PLUGIN_INT32 || AU3_GetType(&p_AU3_Params[1]) != AU3_PLUGIN_INT32 )

[twitchyliquid64]

In the first post Jon Mentioned the removal of the PluginOpen Command in Favour of a Preproccessor Directive.

That was over six years ago.

Therefore is it safe to assume that this will not be implemented, and it is unlikely for there to be any script breaking changes to the plugin system?

[Valik]

That is not a safe assumption.

[twitchyliquid64]

That is not a safe assumption.

As a developer, would you be able to tell me if any changes to this system are on the table? and if yes, what they are?

[Valik]

There is nothing to mention. It's an experimental feature not in a finished state.

[Shaggi]

Any chance arrays as return are on the way? I have a plugin func which has to return a dynamically sized array. Since this isn't possible, only way to do it is some string formatting or struct passing. But both require an interface from autoit, and doing the string thing really leaks memory.

Best was something like this...

struct ArrayReturn
{
    unsigned int amount;
    void * elements;
};

...

    DWORD * arr = new DWORD[nVec.size()+1];
    for(unsigned int i = 0; i < nVec.size();++i)
        arr[i] = nVec[i];
    ArrayReturn _return;
    _return.amount = nVec.size();
    _return.elements = arr;
    AU3_SetInt32(pMyResult,(int)&_return);

...

[twitchyliquid64]

Any chance arrays as return are on the way? I have a plugin func which has to return a dynamically sized array. Since this isn't possible, only way to do it is some string formatting or struct passing. But both require an interface from autoit, and doing the string thing really leaks memory.

Best was something like this...

struct ArrayReturn
{
    unsigned int amount;
    void * elements;
};

...

    DWORD * arr = new DWORD[nVec.size()+1];
    for(unsigned int i = 0; i < nVec.size();++i)
        arr[i] = nVec[i];
    ArrayReturn _return;
    _return.amount = nVec.size();
    _return.elements = arr;
    AU3_SetInt32(pMyResult,(int)&_return);

...

I doubt it, cause as valik said, it's an experimental function not in a finished state, not to mention there has been no development on this functionality for several years. Edited July 23, 2011 by hyperzap

[Unsigned]

EDIT: devrandom beat me to it.

Hello, there is an error in the example plugin.

Line 155:

if ( AU3_GetType(&p_AU3_Params[0]) != AU3_PLUGIN_INT32 || AU3_GetType(&p_AU3_Params[0]) != AU3_PLUGIN_INT32 )

Should be:

if ( AU3_GetType(&p_AU3_Params[0]) != AU3_PLUGIN_INT32 || AU3_GetType(&p_AU3_Params[1]) != AU3_PLUGIN_INT32 )

Also, I'd vote to keep PluginOpen() just because it allows dynamic loading of different plugins based on runtime conditions.

Edited October 1, 2011 by Unsigned

[1234hotmaster]

i also support PluginOpen because its useful and btw can the team please continue to work on it?

[sxyruz]

Great feature, as always. And will benefit all people, even those who will just be making the jump from not writing on C/C++.

AutoIt covers the basic needed features for any programming needs but in any case that you would ned to get a full blown language to work with you, C/C++ are always something to look forward to.

[acidman]

this plugin idea is a good one, considering not all of us has a background of making calls to .dll's so hell yea, go for it...