AutoHotkey Community

First, I want to give a BIG shout out to Lexikos for the ingenious template that spawned into this OOP library.

The website is up, but not yet completely up-to-date though. However, it had a major revamp and looks great.

This thread is for Requests and Bug Reports ONLY. If you want to ask for assistance in using the library, see the Class library (OOP) - Help thread instead.


The zip file contains Class.ahk, the wrapper classes, the Node Class, Array, Vector, and some example scripts (located in the "Class Examples" folder) which demonstrate some of the Class library's functionality. Also, there is a Rectangle Class to demonstate how to modify the Node class to be your own, personalized class.

The included Node class can be used as a template for almost any class you would need (except possibly container classes). Also, there are included wrapper classes to wrap the basic types (String, Int, UInt, Short, UShort, Char, UChar, Float, and Double). Int64 and UInt64 are now added. Additionally, there are some container classes: an Array class and a Vector class (dynamic array).

All classes use the Class library (Class.ahk) to provide their functionality, but the different Classes are optional and are only required if you wish to use them. Extact the zip to a library folder so that the classes are included automatically as needed.

My recommendation is to check out the included example scripts which demonstrate some of the class library's functionality. Also, the website has a TON of information to help you get started.

Download the Class library and
Check out the site
To easily navigate the class website, check out this addition - AccessClassLibrary.


Maintaining the class library requires a lot of time and effort. If you find the class library useful, please consider donating.

_________________
As always, if you have any further questions, don't hesitate to ask.

Add OOP to your scripts via the Class Library. Check out my scripts.

Not meaning to be dense, but can you give an example of how you as an AHK developer plan to use this class, or some other example usages?

Being a proponent of OOP languages, I'm just curious exactly how to develop with this library.

Thanks.

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music

OK, the MAIN reason I took on this endeavor is because I'm building a menu wrapper (which will be done soon thanks to this library). Right now, the menu wrapper so far can move items within a menu (while maintaining the menu icon (if added using Menu Icons), the menu "goto label"/submenu, the display name, and other menu data). It can also add a menu item in the middle of a list. HOWEVER, what annoyed me is that if you wish to move the menu item to another menu, you must re-enter the menu label. Also, for me, at least, I want to have different values associated with a menu/menu item (which are project specific). For example, built-in to the menu wrapper will be functionality for the menu to have the MenuName (as reflected in AHK). Also, I'm working on a bookmark manager, which I plan to sell, in which I need to keep of certain menu/menu item specific values (the url for one). I built this library with those goals in mind.

The menu and menu item dll structure has a value which can store a value. This value will be the address returned from Menu_new and MenuItem_new (which will be classes that I developed). They will be based on the Node class, and will allow user-defined values. So, each person can have their own (project-specific) values. So, not only can different people use the same menu wrapper and have their own user-defined values, but the same person can have different values depending on the project.

Then, the menu wrapper will include a Cdll which contains Cdlls for each menu. Those Cdlls will contain the menu data. This allows me to add the menu/menu item value to the cdll and sub menu cdll to the main Cdll (which stores all the menus). So, I only have to delete that "top-level" Cdll, and it will delete all the menu related stuff. Thus, it's only one line, added to the OnExit subroutine, and the ENTIRE menu wrapper will be freed. This means I don't have to worry about freeing each value.

Then, the address will be stored on the menu/menu item in the menu/menu item dll structure so that my menu wrapper can access and modify those values.

So, long story short, this library allows me to

1) make a menu wrapper (which I desperately need)
2) create a menu wrapper which can store (project specific) values associated with a certain menu and menu item.
3) reuse this menu wrapper for all my projects without any redesign. Just like the rectangle class in the zip can be adapted to different projects by only adding getter/setters for the values and adding any desired functions, the menu wrapper can be used by any project, by any one, and be easily modified (by adding a few getters and setters) to create their own, user-specific, project-specific menu wrapper.

_________________
As always, if you have any further questions, don't hesitate to ask.

Add OOP to your scripts via the Class Library. Check out my scripts.

I think I'm starting to understand, however, it seems i'll have to wait until you release your Menu Wrapper to study it and truly understand how to utilize this. Sounds like it could really help with my development, since I'm frequently trying to create new wrapper libraries to do things I need. Thanks!

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music

No problem. Yeah, I should be able to have the menu wrapper out tomorrow. I'm also going to incorporable Lexikos' Menu Icons into the wrapper. He says he stored the icon's handle with the the menu item, which used the same space that I'm going to use for the menu data. So, there will be two versions of the wrapper - one that includes the menu icons' abilities and one that doesn't. I'm hoping that I don't have to change the function names - to minimize the wrappers impact on code that uses the menu icons library.

But, yeah, hopefully it makes some more sense after looking at that. Also, have you checked out the included examples? If they don't describe the functionality well, I can modify them to clear up some confusion.

_________________
As always, if you have any further questions, don't hesitate to ask.

Add OOP to your scripts via the Class Library. Check out my scripts.

The included Node class can be used as a template for almost any class you would need (except possibly container classes). All classes use the Class library (Class.ahk) to provide their functionality, but all other classes are optional and only required if you wish to use them.

The zip file, found, here contains Class.ahk, the wrapper classes, classes Node, Cdll, and Array, some "test" scripts to demonstrate the Class library's functionality, and a Rectangle Class to demonstate how to modify the Node class to be your own, personalized class.
First off, every Class object has a class name stored with it. This allows for type checking (currenly, only the class' destroy function use type checking, should all Class functions use type checking?) Also, this allows dynamic calling of a classes destroy function. The objects have a "lock count" (description following), so the object is only destroyed when the lock count is zero.

Next, I use type "obj" (which is internally stored as a uint) to distinguish a class object from a normal address. Each class object (except _Node objects, e.g. Cdll_Node) have a lock count which tracks how many times a variable is used.
Each class has a new and a destroy function. The new function returns the address for the newly created object (or 0 if it fails, which should only result if there is not enough memory), and the destroy function returns true if the object was destroyed. The destroy function returns false if attempting to destroy an object of the wrong type (e.g. calling Node_destroy while passing a String object), or if the lock count for the object is not zero (the lock count is decreased by one and false is returned).

If the object is not a wrapper, then the address for the object is returned. Substitute the wrappers class for %ClassName%.



Next, the Node Class.



Finally, the two Container classes.

Cdll functions:




Note, Cdll_node (like all _Node classes) doesn't have a lock count.



The other container class included is Array.


______
Right now, the menu wrapper so far can move items within a menu (while maintaining the menu icon (if added using Menu Icons), the menu "goto label"/submenu, the display name, and other menu data).

The menu and menu item dll structure has a value which can store a value.

Then, the menu wrapper will include a Cdll which contains Cdlls for each menu. This allows me to add the menu/menu item value to the cdll and sub menu cdll to the main Cdll (which stores all the menus).

Then, the address will be stored on the menu/menu item in the menu/menu item dll structure so that my menu wrapper can access and modify those values.
______

Yeah, I should be able to have the menu wrapper out tomorrow. I'm also going to incorporable Lexikos' Menu Icons into the wrapper.

Just a little update. I didn't realize this before, but you can use %ClassName%_initClass() to initiate not only the class name, but any class related data (even perform function calls). Since %ClassName%_initClass() is called each time a class object is created, it is the perfect way to initialize class values.

For example:



Of course using this method, you could call many functions from initClass and use the same method in CallFunction to call functions (to initialize static values).


I'm using this structure in my menu wrapper to create a Cdll that hold all the menu related data. Then, you can delete this class object like so.


This allows the code to deal with the cleanup, instead of your user.

_________________
As always, if you have any further questions, don't hesitate to ask.

Add OOP to your scripts via the Class Library. Check out my scripts.

New revision, added type checking on getters and setters related to _Node class values. The code would crash if you called Cdll_Iterate(ClassObject) with a Cdll_node (returned from Cdll_addBefore/After) instead of the sentinel Cdll (returned from Cdll_new).

The link on the first post points to the revision and I post it again, Download Class library.

_________________
As always, if you have any further questions, don't hesitate to ask.

Add OOP to your scripts via the Class Library. Check out my scripts.

Currently trying to decide if I want to start converting SteamWin to use this library. Since I'm already developing it in separate stdlib-compatible libraries, I think it should be pretty straight forward.

Trying to weight the benefits of doing so or not doing so, however. I'm still very interested in using this library but still just slightly off the mark of grasping how exactly to turn my libraries into classes/wrappers.

Thanks a lot for making this. I'm looking forward to seeing what can be done with it, and hopefully being one of the developers to do something with it

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music

If you could post some code I could help even more, but here's it blind. Also, if you haven't already, check out the included Rectangle class and Rectangle test, which may give some insight. If you have any questions about either feel free to ask.

This library is great for all the times you need to associate many "values" with a certain item. That item becomes a class object, and those values become either built-in or user-defined values for the Class.

Built-in values are ones that are project-independent. For example, in the Rectangle class included with the download, width and height are built-in, because every rectangle has those values. Also, there is the added built in function, Rectangle_area, which returns the area for the rectangle object. You get/set built-in values by specifing for the index "b" followed by the zero-base byte offset. Don't worry about the internal "class values", because the "b" means that it's a built-in value and the index is adjusted automatically. Remember to set the built-in size to whatever it may be so that the code can adjust the offset for any user-defined values you may add. Also, you may either choose to include these built-in values as arguments for the _new function (like as done in the rectangle class), or you may choose to set them later.

Then, you may have project-specific values. If not, you can call %ClassName%_new with zero parameters and zero is used for the size value (number of "user-defined" values). These values can be any value that takes up four bytes (or less). Four bytes will be used regardless (even for short, char, etc.). Thus, you may want to pack/unpack these values yourself (see example below), so not to waste space. Since this may be useful for people, I'll whip up a function to do the packing and unpacking for you. Values that take up more than four bytes (e.g. double and when added Int64/UInt64), must be wrapped, and their address stored instead.

To get/set user-defined values, use one-based indexes. For example, calling Class_setValue(ClassObject, 1, data, type) will set the first user-defined value to <data> and be of type <type>. Note: provided you set the built-in size to the correct value, you can adjust the number of built-in values without having any impact on your code (you don't have to adjust any indexes). User defined values are automatically placed after built-in values (so be sure to set the built-in size to the correct value).

Note also, that built-in values/function and the getters/setters for those built-in values should be included with the class (because they don't change). If the class' new function accepts a parameter for the user to set the number of user-defined values, those values' getter/setter methods and any project-dependent functions should be included with the project (and not stored in the class) - see Rectangle_test.ahk for an example. If there is a parameter to allow for user-defined values, the user of the class MUST create a function %ClassName%_destroy_private(ClassObject) to destroy those objects and free the memory. This is best done by calling the setter method for each user-defined value and setting it to "" (for strings) and 0 (for numerical data and objects (type "obj") - "" is also accepted). Even if the number of user-defined values is zero, this function must still be created (but it would be an empty function). However, if the class is not designed to accept user-defined values, then there is no need to have a parameter for it, and instead a static value, Size, should be created and set to zero ("static Size = 0"). Also, in this case, there is no need for a %ClassName%_destroy_private function, so it can be removed from the class' destroy function.

Hopefully, that clears up some confusion. If not, some code/examples would help - I'm batting blind here.

Edit:
Sorry, forgot to add the packing/unpacking example, I'm writing an example to pack/unpack two shorts into an int right now. I'll post in a few.

Edit:
Sorry, it took so long, it's been a while. Storing two unsigned values is easy, but two signed values - had to rederive it, but here it is.

This will wrap two shorts (signed) into a four byte value (range is for each value, -32768 to 32767). Call pack to pack the value and unpack to unpack the value. Like I said, I'll write up something to add this functionality to the class library- after I finish the menu wrapper. The user will have to specify for the format (so the packer knows if the values are signed/unsigned, short/char), but I'll make it easy on yal.

_________________
As always, if you have any further questions, don't hesitate to ask.

Add OOP to your scripts via the Class Library. Check out my scripts.

Thanks for such detailed information. That did help clear up a lot of my confusion. My challenge currently is adapting it to my new version of my project, SteamWin. I hate to be a bother, but perhaps you could give me a recommendation as to how you would best incorporate the OOP library based on what I'm doing.

The concept is designed around providing a window manager for creating Steam-like windows (Steam is game-distribution, management, and community software by Valve Software). It's goal is to be able to parse and display windows using any Steam skin package. It's mainly designed to be used in my SteamLab project, but it's been requested to make a separate package that can be used for other projects, so I'm trying to make it accessible.

There are several sections of the script, developed as interconnected libraries. I'll try to just give you an idea of how they're split out and what they do.

Base libraries:
SW_Core provides initialization and shutdown functions, and base functions shared through all the libraries
SW_Scheme parses the steamscheme.res file into a set of arrays entered into a database that can be utilized by the other libraries
SW_Setting processes the basesettings array in the scheme and gets settings from the database
SW_Control processes the controls array in the scheme, adds controls to windows, manages controls and control groups, etc. Called by the individual control functions which serve as wrappers for this one.
SW_Appearance processes the appearances array in the scheme and follows a set of steps to render things onto Gui elements with GDI+
SW_Color processes the colors array in the scheme and gets, converts, and sets colors to and from things
SW_Border processes the borders array and describes how to draw the borders (backgrounds, etc.) onto controls.
SW_Font processes the fonts array and manages the various font definitions used throughout the controls

Individual control functions such as:
SW_Frame is an SW_Control wrapper for managing windows
SW_Button is an SW_Control wrapper for managing buttons
SW_CheckButton is an SW_Control wrapper for checkboxes and radio buttons
SW_CheckButtonList is an SW_Control wrapper for lists of associated checkboxes/radio buttons
... tons of others ...

Some pre-built window libraries for ease of use such as
SW_Wizard
SW_DownloadBox
SW_MsgBox

Some helper libraries such as:
SW_GuiNum manages a list of GuiNums (1-99), passes out available GuiNums, manages which elements are using which guinums, etc.
SW_GdiPlus wraps tic's GdiPlus library into generic functions used to render controls

Each control wrapper (and most other libraries) has common function wrappers such as Add, Edit, Remove, Draw, etc.

... and the list goes on. Many of the libraries rely on varying numbers of elements in other libraries but there isn't always a clear hierarchy aside from some common sense notions such as that CheckButtons belong to CheckButtonLists and that all controls belong to a Frame, etc.

It's quite an in depth project and it's unruly to manage. I've been trying to keep consistent and stdlib compatible, but converting many of these things to objects in an OOP environment sounds appealing to me if I can figure out how to best apply it to AHK and your library.

I'll stop before making this post too long. Thanks for your explanations and assistance so far, I think I'm almost ready to start using the OOP libraries to develop with.

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music

Because the kind of thinker I am, when I'm not sure what to do, I start vague and work toward the specifics. So, first off, I'm presuming you have used OOP before. If not, then we'll need to tackle that first. However, presuming this fact, then I'll ask the vague questions and use your answers to make them more specific.

1) What kind of "objects" do you expect to need? An object has values associated and functions that use those values. The first thing I picked up on is the GuiNum. This would be an array of Guis (you'll need a Gui Class) - size 99. Since the number of gui's can't change, and the user can use any gui, it makes sense to initialize 99 guis. Since the values start off null, there is only the overhead of the 99*4 bytes required to store the guis. Only after a gui is created (and values are stored) will more memory be required.

Now, each Gui has certain values. I'm not sure if you're storing the controls in the gui, or what, but I'll use it as an example.

Each gui has certain controls. Each control type would be a different class - a checkbox class, radiobutton class, etc. (which can adopted from the node class to fit your needs). Each of those classes have certain values. For example, a control has a goto label, a variable name, a font color, font size, etc. Any (or all) of these would make a perfect canidate for a "field" (a value in an object). So, the fields you use depend on what you want to store. From there, you can add functions that use that data. These functions can be added to the class or not. The benefit of adding them to the class (and adding the %ClassName%_ prefix) is that AHK will automatically looks in your library and will find them easily. Also, it allows you to keep the functions with the class (and out of your way).

2) How do you think that this library will help you? By that I mean, what about the library caught your eye. I ask, because just as you're not sure how to use the library, it will be very hard for me to grasp the complexity of your project. So, the middle ground is, you tell me how you think the library can help you, and I can help you achieve that goal, or tell you straight up that the library isn't designed for that. From there, it may be that the library COULD suit it, but it would require certain classes to be built - which I'm all for creating classes (especially container classes that anyone can use).

I think that's the main points. I'm not sure how to advance because I don't have enough information. If you could explain (broadly enough so I don't get confused by the project's specifics) what you think the library can do for you, I can start figuring out how to apply the library to your needs.

_________________
As always, if you have any further questions, don't hesitate to ask.

Add OOP to your scripts via the Class Library. Check out my scripts.

I think you've answered my question there. That was the idea I had also, that I would essentially create a class for every control for starters and go from there.

I am, I will say, vaguely familiar with OOP, in that I have used OOP languages and understand the fundamentals of OOP but don't have extensive experience in its practice.

I am always leaning toward OOP using MVC architecture, such that my primary development environment (on and off) is CakePHP, which is essentially a PHP port of Ruby on Rails.

The fundamentals of OOP are what I'm already trying to use in separating out my various libraries. All thats missing is the actual OOP support to tie it all together.

Each of my libraries essentially represents what would be a class as I'm familiar with it (SW_Control would represent the Control class, SW_Appearance would represent the Appearance class, SW_GuiNum would represent the GuiNum class, SW_Button represents the Button class, etc). Each of those classes has objects that can be represented, and most of the objects need to be represented a number of times (instances)

Each of my libraries has common and custom functions (methods) which could be simplified I think by putting common functions in a parent class and referencing them where needed.

Each object has common properties and each class's objects would have some common properties unique to the class.

My goal is to put as many functions as possible into the classes to keep them organized and out of my project code.

I think the OOP library can facilitate some or all of that, and I'm starting to see the resemblence between its available functions and what I'm used to using.

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music

Also, I'm not sure how you organize it now, but you might want to use a container class to store all the controls that "go together". This way, you only need to destroy that container and all values inside are destroyed - this prevents needing to keep track of all the objects you createdd and destroying them one by one. For example, back to the example I gave, you would have all the controls that are in a certain gui in one container. This way, when you delete the gui, you can delete the container, which, in turn, would delete the gui control objects.

I'm adding some much needed functionality to Cddl and Array and will add the like to Vector, so that should help if you require "search" features. The question becomes, how does your data need to be stored?

Arrays can't be resized, so they are meant for times when you know how many objects will exist beforehand. Now, the array size can be set on run-time, but once the array is created, you have to go through a big mess to rebuild it. Arrays have a "small" memory footprint. They take a base value of 16 bytes (for the needed values), and then 4 bytes for each entry (which can store any class object - use the wrappers to store basic types).

Cddls offer the benefit of constant time inserts and deletions (provided you pass the node's address that you want to delete). I'm adding functions that will allow you to delete an item based on it's node value (working out what this "value" will entail), and this will take linear time, since it has to look through all the items. Right now, I believe I'm going to use this container for the menu wrapper - it's why I designed the class. Cdlls don't need to move data around when inserting and deleting values, unlike Vectors which do. However, Cddls are larger in size. Cddls have a base value of 16 bytes and then 16 bytes for each Cdll_Node. I'm going to have to do some performance testing to see how long it takes to delete/insert items and see if it's worth the memory use (I'll report my findings when I get to that). Vectors, in comparasion, require a base value of 16 bytes for the (internal) Array that stores the values and then 16 bytes for the Vector. Then, like arrays, they require 4 bytes for each added value.

Cdlls are useful if you need to have a fixed location for the values (a "unique id" of sorts for the item). You can use the Cdll_Node's address to provide this unique id. Since Vector elements move around as items are inserted and deleted, there is no fixed point you can use. So, if you don't need a unique id for the Class (or if there is one you can use), then Vectors might be a better road. I'm wondering if Vectors are a better fit than Cdll for the menu wrapper, so thank you for asking these questions, because it's making me think what I should do for my own project.

_________________
As always, if you have any further questions, don't hesitate to ask.

Add OOP to your scripts via the Class Library. Check out my scripts.

Scratch that, in part. Lexikos just informed me that the process automatically frees memory on close - who knew?? However, when a gui is destroyed, the gui object should be destroyed (as well as any objects that were based on that gui).

_________________
As always, if you have any further questions, don't hesitate to ask.

Add OOP to your scripts via the Class Library. Check out my scripts.