Search the Community

GTK+ Framework | Widgets I'm doing experiment to use GTK+ Widgets on AutoIt3 and seems it sucessfull. Its cause some user on AutoIt3 forum requesting it. Well there are I'm using V2 of GTK+ which you can get binary file at http://www.gtk.org x32 http://ftp.gnome.org/pub/gnome/binaries/win32/gtk+/2.24/gtk+-bundle_2.24.10-20120208_win32.zip x64 http://ftp.gnome.org/pub/gnome/binaries/win64/gtk+/2.22/gtk+-bundle_2.22.1-20101229_win64.zip Don't get too happy. Because this far from complete. As for V3. Maybe I will release if V2 have been completed. Hah, its anonnying when get failed on implementing some function! So as far my work only go to: gtk2.zip (link fixed) or gtk2.zip There sample file how to use it. Oh yeah copy AutoIt3 Script to 'bin' folder of package you download from gtk.org If you interesting to join this project, please let me know. PM or E-Mail me. Thanks Screenshots .. .. ..

Introduction Plug-in frameworks have basic principles to follow and can support whatever the developer wants it to. There are many options for various languages when it comes to plug-in frameworks but not so much in terms of Autoit. The subject matter here though is not to define what a plug-in framework is suppose to be or what it should support (for a brief overview you can go here) http://en.wikipedia.org/wiki/Plug-in_(computing) Objective 1) Create a minimal non application specific plug-in framework base structure that will support non-compiled .au3 scripts in the form of extended functionality features or plug-ins for AU3 compiled.exe executable's. Model Model Overview The above model demonstrates a chain style plugin whereas all functionality is initiated and received from a global point being the Host Application. Theoretically two directional functionality can take place between both Host Application & plug-ins in the above model reproducing two-way plugin structural behavior. To make this as functional as possible we take out everything in the Host Application, and all we leave behind is a generic skeleton for the framework as well as any application specific instructions for handling incoming plug-ins. The plug-ins ultimately become the functioning parts of the application and/or the application directions for the framework. The Host application becomes a zombie for handling whatever the hell we tell it to handle. All application feature functionality resides in the plug-ins. The Empty Compiled AU3 file is you guessed it, a module a piece of reusable software the middle man for handling parameters that will in turn invoke the plugin same as you would if you brought the Autoit interpreter with you. The plug-ins can then send parameters back to the main application telling it how to respond. During the 2nd initialization of the Host Application via the initialized plug-in we will check for parameters passed. In the end what you have is a very well mannered base component for you application specific framework. One that waits in turn while having a conversation with the other components, only speaks when spoken to, and finishes what it starts in the form of start with one process end with one process. Components 1) Host Application (YourApplication.exe) 2) Empty Compiled Au3 file (pluginloader.exe) - self explanatory 3) Plug-in (plugin.au3) Research Resources https://code.google.com/p/jin-plugin/ http://www.drdobbs.com/cpp/building-your-own-plugin-framework-part/204202899 http://www.eclipse.org/articles/Article-Plug-in-architecture/images/listeners_extensions.jpg http://www.cs.tut.fi/~mda/documentation/eclipse/MadeArchitecture.gif http://www.programcreek.com/wp-content/uploads/2011/09/EclipsePluginArchitecture2.jpg