Plugins (deprecated)

[A. Percy]

Then I was debbuging plugin with the new version of autoit and ...

---------------------------

---------------------------
This is a compiled AutoIt script. AV researchers please email avsupport@autoitscript.com for support.
---------------------------
OK   
---------------------------

Very interesting, but it's a shoot in my head...

[A. Percy]

Then I was debbuging plugin with the new version of autoit and ...

---------------------------

---------------------------
This is a compiled AutoIt script. AV researchers please email avsupport@autoitscript.com for support.
---------------------------
OK   
---------------------------

Very interesting, but it's a shoot in my head...

Six months after... and nothing.

I'm using 3.2.4.9 to debug my plugin. Any suggestion?

[Valik]

Almost assuredly the core of your plugin doesn't need to be written to interface with AutoIt. Write normal C++ code accepting the parameters you want. Test it, debug it, et cetera in a normal application. Once you are satisfied it's working correctly, write a thin wrapper function to marshal the AutoIt type(s) to C++ types.

Basically, in order to write an AutoIt plugin, you must separate the code that interfaces with the AutoIt API from the implementation of the functionality. It's a good design, aanyway, but pretty much mandatory if you want to debug the code.

[A. Percy]

Almost assuredly the core of your plugin doesn't need to be written to interface with AutoIt. Write normal C++ code accepting the parameters you want. Test it, debug it, et cetera in a normal application. Once you are satisfied it's working correctly, write a thin wrapper function to marshal the AutoIt type(s) to C++ types.

Basically, in order to write an AutoIt plugin, you must separate the code that interfaces with the AutoIt API from the implementation of the functionality. It's a good design, aanyway, but pretty much mandatory if you want to debug the code.

You are right. But in case of testing a bug, I'll have some re-work to reproduce "bugged" situation. I've write a opengl plugin some time and I'm planning write a Irrlicht plugin. Well, I'll think about it.

Thank you

[JSThePatriot]

I would like to know if it is still true that there limited support of AutoIt variables in the plugin architecture?

Thanks,

JS

[Jon]

I've not got around to doing any more work on it, no... :|

[JSThePatriot]

I've not got around to doing any more work on it, no... :|

Jon,

That isn't a problem at all. I was just checking back. =D I haven't even had my own time to update all my libraries.

Thanks for the continued support on such a great product!

JS

[encode]

Just wanted to say thanks for the C++ SDK. I've been using JSThePatriot's modified version from the MD5Hash source, and so far it's working great.

Before I discovered the SDK, I was trying to use DllCall to interface with some really basic C++ code, but I couldn't get string support to work at all.

I hope support for plugins is at least maintained, even if you have no time to work on adding additional features. They're much easier to code for, especially to someone who isn't that up to scratch with C++.

[A. Percy]

I had a dream... arrays

[JSThePatriot]

I had a dream... arrays

Unfortunately right now, I must say...keep dreamin

JS

[A. Percy]

Is being hard to return collision points without arrays

[JSThePatriot]

Is being hard to return collision points without arrays

Yes, I have been wanting to write a SQLite library using the plugin architecture, but returning the data naturally would require arrays as well. Or at least to structure it in a manner that I would like to see. Of course I could write the plugin, and it could out put everything as a delimited string, but then I would have to write a library that accesses the plugin.

Thanks for listening,

Jarvis

[Valik]

I suggest you guys look at iterator implementations. In particular, look at how iterators work in Python or Lua. You're locked into the mind-set that you must return all data in one call and aren't really thinking about maintaining a state which persists until all the data is returned over multiple calls. It is certainly not ideal having no array support but that doesn't mean you can't return raw data in such a way that the array can be built on the AutoIt side of things. Study up on the way Python iterators are designed and apply the concept to a plugin. Lua uses the same technique if you're more familiar with that language. Also, if you have SciTE4AutoIt you can find an instance of an iterator I implemented in Lua but I don't recall where it is. Perhaps AutoItGotoDefinition.lua but don't hold me to that.

[JSThePatriot]

I suggest you guys look at iterator implementations. In particular, look at how iterators work in Python or Lua. You're locked into the mind-set that you must return all data in one call and aren't really thinking about maintaining a state which persists until all the data is returned over multiple calls. It is certainly not ideal having no array support but that doesn't mean you can't return raw data in such a way that the array can be built on the AutoIt side of things. Study up on the way Python iterators are designed and apply the concept to a plugin. Lua uses the same technique if you're more familiar with that language. Also, if you have SciTE4AutoIt you can find an instance of an iterator I implemented in Lua but I don't recall where it is. Perhaps AutoItGotoDefinition.lua but don't hold me to that.

Valik, Thanks for the proposed solution that will probably work until more data types are supported in the plugin architecture. I was trying to avoid having my plugin return multiple data sets as I would feel the need to then write an AutoIt interface library, but it doesn't sound terribly bad when you speak of it. lol

Will see what I can come up with. Thanks for the suggestion.

JS

[A. Percy]

Ok, I keep following the white rabbit

[i542]

Just checking... Is this topic still alive? And if it is will there be possibility of programming in VB.NET or I would have to make DLLs?

[Richard Robertson]

.Net doesn't create the same sort of dll as C++ does. .Net only works on an object oriented basis which means no file level functions and things like that.

There currently is no way to call a managed (.Net) system from a native system without using either a managed C++ middleman or by calling the unmanaged-managed interface provided with the framework. It's more complicated than it should be though.

[toakhilesh]

I have been workign with Managed/Unmanaged C++ for past some time (using C++/CLR in VS2005), and there is a way present to create a DLL that has .NET code in it. I have created a Control Panel Applet (a standard DLL interface), that in turn shows a .NET Managed UI.

I have not used it VB.NET, but if you are using VC++ with .NET then it will be possible to use .NET with that. But whether it is really required and useful will be another story.

[Richard Robertson]

That would be the managed extensions of C++ that I mentioned indirectly. It doesn't quite help Ivan use VB.

[toakhilesh]

That would be the managed extensions of C++ that I mentioned indirectly. It doesn't quite help Ivan use VB.

Right. And I feel VB.NET is actually of no advantage as compared to VB6 that provided in comparison with VC6. MS killed VB6's potential by not extending the functionality it in VB 7/8. It is just there for giving .NET another language without any advantage over the others. They even took away the option to create native and COM dll.

But in VS 2008 I have heard that it allows mixed language programming (I have not yet had a chance to use it yet). Maybe using that it might be possible to create a native DLL and also use VB.NET.