27 replies to this topic

[RalphaelNinja]

Yeah it is a common issue that the OOP examples tend to be too simple and the value behind can not be identified. After all, the OOP approach makes things more complicated in the first place, but as soon the program gets a bit of complexity the abstraction shows its true value.

 

@RalphaelNinja: I have taken several approaches to show "old school" programmers with a background in RPG and now (Visual) Basic to get in touch with OOP. It is amazing how difficult it is to show someone the benefits of it by just a discussion. Common arguments against OOP from the old school people cover "needs more code to achieve the same", "I can not follow the code flow due to abstraction (polymorphism)" and finally "it might just be too complicated".

 

I understand that the root cause of those wrong arguments comes from the fact that those people try to apply their old and proven structural programming knowledge to the OOP world. Off course, you still program structurally inside classes, but they seem not to be able to get the big picture.

 

I wonder if you have some easy to understand arguments to explain the matter to "another" old school programmer?

 

hello Fellows... if I read your post correctly, you are asking if I have more easy to understand arguements to another "old school programmer?"

 

Actually I'm one of the kinky old school programmers back then; I actually love OOPS and needed no convincing to head for the dark side. Today, OOPS is so easily available that there is no reason why you shouldn't tackle it with vigor as everything is now OOP and that is the way it is. In the old days you have to pay to get OOPS and now like with AHK, it is free. Free!! what more can you ask for

 

1st Arguement: Free is one of my arguements that it is time to take an old topic and put it to rest. Everything is in OOPS now and If you are a structure programmer then you have to start OOPS by using classes. This is the foundation on which OOPs is based on. Within the Class you begin defining the structure of the object, the local variables and the self contained methods. When you begin working with a Class, you begin to think of self contained Commands that you can tell this object to do; like in my case, "Blink" "off", sit and beg...

 

Second arguement: OOPS is used wisely can reduce your structure coding by 50% or more. I've finished my program that allows you select which sim Expansion pack that gets activated and by using OOPS the coding has been reduced from 3000 lines of coding down to about 1000 lines. Structures that previously had over a hundred if-then-else coding has been reduced down to:

 

for k, v in SimButtons

   v.save()

 

v.save() is the method in which each game updates itself in the registry. Now instead of having to deal with each game separately and maintaing information about which game goes with which variable, like game_01 goes with game_01_registry goes with game_01_textstring etc, all this information along with its methods are all "encapsulated" in a single game object.

 

Granted you could store all this information in a "Structure" or "Record" array, but.... this is what an object is... a structured record

 

Third Arguement: Once you wrap your head around this paridigm, there are some things that you can do in OOPS that you really cannot do in standard logic flow.

 

In my game selection, one of the function that I needed was to select one expansion pack to play and the rest would be deactivated and their entries removed from the registry. Now given that I did not have an array of games, I would have to hard code the games in straight deativation list, or I could simply remove all the games and re-insert only the game that I wanted to play.... but I still had to remember what the original settings was so that I could restore the deleted games.... yes yes.... there are hundreds of possible solutions....

 

but one came to mind.... OOPS...

 

here is my oop solution...

 

for k, v in simbuttons

   v.push()

 

the push() method is defined to save the status of itself and set it's new status to off

turn on the game that I selected.... run the launcher...

 

and on return

for k, v in simbuttons

   v.pop()

 

last arguement:

 

This was the original reason that I decided to go to OOPS with this game selection program, to reduce the complexity of the logic. Objects themselves are self contained and you don't have to worry where the associated data and functions that can manipulate that object are stored. This is true if you have very complex functions of which you no longer have to pass as parameters that contains hundreds of parameters. Objects can be created with defaults. In the hands of a programmer artist, OOPs is a thing of beauty, but like any programming tool, it can get ugly rather quickly; like most of the novelty examples that I have seen; however this is true of all programmers as they love obfusated code.

 

when I see code like: for k,v in simbuttons v.off(), I am in love!! it is just so simple!!

[paulinColorado]

RalphaelNinja,

 

Thank you very much for starting this tutorial for 'old-timers'.  I am one, and have only scratched the surface of AHK objects. 

 

I encountered a runtime problem that only occurred after the amount of data exceeded perhaps 20,000 strings, mostly key-data pairs in associative arrays.  But objects are relatively new, and I understand it may need time to stabilize especially for heavy use - many thanks to the AHK developers.    ( Problem:   Data recently saved to an associative array would not be found on subsequent queries - sometimes (access would fail deterministically, but was sensitive to data sets.  Perhaps a failure to commit cached data timely?).  Executable size had exceeded 20MB)

 

I've been very pleased at the stability of releases, and haven't submitted a bug in years (I would have submitted this

one, but the datasets were private, and the problem is data-dependent)

 

Anyway, I sought help at the #Ahk chat group, and left feeling patronized.  The complete absence of helpful comments and the clever non-answers I received surprised me.     I stayed on but "away" for perhaps 30 minutes.  On review of the "discussions," all became clear given the numerous references to exams, classes (held in classrooms), and spring break.  At least during my visit, students dominated the forum, and socializing, spring break, and oneupmanship seemed to trump technical discussions and helping one another.

 

[Re the forum: I'm probably leaping to unfair conclusions based on a single experience and 30 minute sample. Plus, this was just before spring break.  Too old to recall Spring Break . . . ]

 

In any event, I was glad to find your post, and appreciate the time you took to prepare it.   As you pointed out, it is impossible to ignore OOP.   Yet the number of built-in objects, classes, properties, and methods one needs to know before writing an app for MS Windows using the MS language implementations makes this old-timer long for C. 

 

AHK has been a mainstay for me for several years.  It is free, and has empowered me to customize the Windows XP and 7 GUIs, numerous apps, as well as write scripts to extract/insert data into various apps with feature voids (eg, data backup/restore).  The introduction of general objects to AHK is terrific.  And it still remains free, and offers much simpler object(ish) GUI support and defaults than Windows C#, etc.

 

Anyway, here is one unqualified thank-you for your contribution .  I would like to see more such discussions.  I also wonder if I've been unable to find info on AHK internals that is there to be found - not source, but a discussion of the architecture of the runtime interpreter.

[JnLLnd]

@RalphaelNinja:

 

In the hands of a programmer artist, OOPs is a thing of beauty

 

I love this thread!

 

First, thank you for adding a word to my relatively limited English vocabulary. I could not pronounce "lackadaisical" but I will recognize it when I read it again :-)

 

I'm an old programmer too. Self-trained to Basic, Turbo Pascal and Modula-2 (soooo strict language) but also exposed early to OOP with HyperCard on old Fat Mac and more recenlty in the VBA world. As you, I was first confused by the lack of structure and type control in AHK but finaly found it very flexible and powerful.

 

I'm actually experiencing with objects and arrays of objects (collections), creating functions to save/load/sort collections to files, etc. Next step will be using classes and, then, your tutorial will be very helpful.

 

Thank you for posting all this.

[RalphaelNinja]

RalphaelNinja,

Thank you very much for starting this tutorial for 'old-timers'. I am one, and have only scratched the surface of AHK objects.

I encountered a runtime problem that only occurred after the amount of data exceeded perhaps 20,000 strings, mostly key-data pairs in associative arrays. But objects are relatively new, and I understand it may need time to stabilize especially for heavy use - many thanks to the AHK developers. ( Problem: Data recently saved to an associative array would not be found on subsequent queries - sometimes (access would fail deterministically, but was sensitive to data sets. Perhaps a failure to commit cached data timely?). Executable size had exceeded 20MB)

I've been very pleased at the stability of releases, and haven't submitted a bug in years (I would have submitted this
one, but the datasets were private, and the problem is data-dependent)

Anyway, I sought help at the #Ahk chat group, and left feeling patronized. The complete absence of helpful comments and the clever non-answers I received surprised me. I stayed on but "away" for perhaps 30 minutes. On review of the "discussions," all became clear given the numerous references to exams, classes (held in classrooms), and spring break. At least during my visit, students dominated the forum, and socializing, spring break, and oneupmanship seemed to trump technical discussions and helping one another.

[Re the forum: I'm probably leaping to unfair conclusions based on a single experience and 30 minute sample. Plus, this was just before spring break. Too old to recall Spring Break . . . ]

In any event, I was glad to find your post, and appreciate the time you took to prepare it. As you pointed out, it is impossible to ignore OOP. Yet the number of built-in objects, classes, properties, and methods one needs to know before writing an app for MS Windows using the MS language implementations makes this old-timer long for C.

AHK has been a mainstay for me for several years. It is free, and has empowered me to customize the Windows XP and 7 GUIs, numerous apps, as well as write scripts to extract/insert data into various apps with feature voids (eg, data backup/restore). The introduction of general objects to AHK is terrific. And it still remains free, and offers much simpler object(ish) GUI support and defaults than Windows C#, etc.

Anyway, here is one unqualified thank-you for your contribution . I would like to see more such discussions. I also wonder if I've been unable to find info on AHK internals that is there to be found - not source, but a discussion of the architecture of the runtime interpreter.

yes, there does seem to be a data leak somewhere in AHK and I feel it is related to the lackadaisical syntax of AHK. In my own object, I had to use a string of "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" to reserve space for data that I want to stuff into the object since I notice that if I assign data longer then the original string, it would corrupt the other data in the object; apparently the string is stored as a constant.

If you are having problems with data over 20MB, you should isolate the data portion itself with random data generator that generates your array up to 20mb and show that it has problems after exceeding the 20mb and post that up as an example. You might be surprised that it might not be a 20mb limit but rather somewhere in your code AHK is overwriting your data because it is interpreting a string as a pointer or vice versa; I've had my share of idiosyncrasis with AHK.

It will probably be a bug that might never get fixed so you will need to work around it.

As part of my structure programming background, isolating and grouping working pieces of code guarantees that certain pieces will always work by ensure that I have tested that piece throughly before moving on.

Such as my registry copy code that copies subtrees of the registry once I pass the root of the registry. It is a recursive function call that I wasn't sure it would work with AHK, but after many tests and many Msgbox'es, the function was finally allowed to write to the registry and I would double check the copy. Once that was working, this became a function call and was moved out to an include module.

If you need some deductive help, pm me and I'll look over your code.

Thank you for the thank you too... I'm more then happy that someone is reading my ramblings...

[RalphaelNinja]

@RalphaelNinja:

 

 

I love this thread!

 

First, thank you for adding a word to my relatively limited English vocabulary. I could not pronounce "lackadaisical" but I will recognize it when I read it again :-)

 

I'm an old programmer too. Self-trained to Basic, Turbo Pascal and Modula-2 (soooo strict language) but also exposed early to OOP with HyperCard on old Fat Mac and more recenlty in the VBA world. As you, I was first confused by the lack of structure and type control in AHK but finaly found it very flexible and powerful.

 

I'm actually experiencing with objects and arrays of objects (collections), creating functions to save/load/sort collections to files, etc. Next step will be using classes and, then, your tutorial will be very helpful.

 

Thank you for posting all this.

 

Thank you too for your thank you.

 

Remember that when you are programming to always have a purpose; such as a solution to a problem even if you are programming just for the sake of programming, go find a problem to resolve then write to solve it. In this way, you will touch upon all elements of the programming language immediately and you will find ways to interact with all the elements. 

 

For example my game selector in which I had to store all my icons within an object array and the resulting simplicity of the buttonpress.

 

If it wasn't for the game selector program, I would have never bothered with figuring out AHK's objects.

 

Thanks for reading...

[DanHunter]

@RalphaelNinja:

 

Normally, I don't post, but since you asked, this example has been very helpful to me; thank you!

 

I just found AHK about 2 weeks ago, so I am very new to this. I am very impressed with the power and simplicity of AHK and I've been having tons of fun with it.

 

As a learning exercise, my 1st program is to write a debugging tool: a watch window, to examine memory and see what AHK does with what I've told it to do. I have this working, but now I want to make a class out of the watch window, so I can have multiple watch windows open at once. It's a steep learing curve, but your example of how to do classes, solved 1 of three things I didn't know how exactly to do.

[RalphaelNinja]

@RalphaelNinja:

 

Normally, I don't post, but since you asked, this example has been very helpful to me; thank you!

 

I just found AHK about 2 weeks ago, so I am very new to this. I am very impressed with the power and simplicity of AHK and I've been having tons of fun with it.

 

As a learning exercise, my 1st program is to write a debugging tool: a watch window, to examine memory and see what AHK does with what I've told it to do. I have this working, but now I want to make a class out of the watch window, so I can have multiple watch windows open at once. It's a steep learing curve, but your example of how to do classes, solved 1 of three things I didn't know how exactly to do.

Your response is much appreciated as it seems that there are many lurkers here and I never know if something that I write helps anyone.

 

What other 2 things that you don't know how to do? 

[DanHunter]

I didn't know how to do multiple GUIs, but that was then, and now I know how to do it.

 

I found out that I couldn't parameterize the labels for the code that processes the GUI events, so I abandoned the class idea. If I couldn't completely encapsulate the watchbox class, then there was no point. As I read the documentation, Gui event handlers cannot have parameterized labels.

 

But, at least now, I know how to do classes in AHK.

[JnLLnd]

As I read the documentation, Gui event handlers cannot have parameterized labels.

 

 

Did you mean something like this?

Gui, One:New, , First
Gui, One:Add, Text, x640 y320, ONE
Gui, One:Show
Gui, Two:New, , Second
Gui, Two:Add, Text, x320 y240, TWO
Gui, Two:Show
return

OneGuiClose:
MsgBox, Closing Gui #1
ExitApp

TwoGuiClose:
MsgBox, Closing Gui #2
ExitApp

If no name is given, special labels such as GuiClose have the default "Gui" prefix unless overridden by +LabelPrefix in the options.

 

 

 

 

 

 

Also, the above can give more control. See here.

[DanHunter]

@jlalonde: Sorry, I was totally unclear. The problem with trying to make a class out of the Gui is two-fold.
One, the GUI vNNNN parameters have to be either static or global, but what I really wanted them to be was among the class variables. And, two, the Gui gLLLL goto's have to be labels and cannot live where they belong, ie, inside the class as event-driven FUNCTIONS.

It was possible to kludge it up and do it, but the result was ugly, and so, defeats the rationale for using classes. If you can't make the class an entirely self-contained unit that looks like a complete black box except for its publicly available properties and methods, what's the point of doing it?

[JnLLnd]

@DanHunter: I used classes but never designed one. Now that I'm quite comfortable with Objects, this is my next step. 

[RalphaelNinja]

@Danhunter: I totally agree with your statement that it very difficult to encapsulate a AHK GUI into a class without the kludge effect due to the goto label. In fact someone did just that with different methods for each event and I found their code to be totally incomprehensible. 

 

However with that said, there is a way to mix event driven code with objects gui and that would be centralizing the goto label so that all events points to a single goto label, which then determines which window object and method, in an array, that it should call.  

 

This is similar to the goto label PressmyButtons which deals with all the icon button toggling using an Associative Array.  One Goto Label, multiple handling of icon toggling.

 

However if you wish to create a generic Window Gui Class, you will need to define a goto label for each of the different types of Gui Events and a method within the object to deal with that type of event. It can be done, but it becomes messy due to the method that AHK implements its GUI. The problem can be resolved by registering a method to be called when an event occurs; thus removing any global or fixed labels.

[DanHunter]

@RalphaelNinja: Thanks for the info. I've totally moved on to project #2, but I'll prob come back to this later. 

 

By "registering a method", I don't think you mean using OnMessage(). Does it use RegisterCallback()? If so, then do you put the callback function into the "Gui, Add" statement as g labels and use A_Gui within the callback to determine which Gui it belongs to?

 

 

Also, I have a question re my new project here: http://www.autohotke...etween-scripts/

 

If you can shed any light on that one, it'd be GREAT!

 

 

EDIT: nevermind, problem w interprocess communication is solved