derz00 wrote:I must read this sometime. Am also in a edX course, learning Python and the science in general. Coming back to AHK it seems really loose, etc. But just the other day I wrote my first class. So I am wondering if you can give any tips? It works well, and does what I want. But it seems like a lot of this. Is that just the way it is? Or there would be better ways to design it?

(It is to replace SplashText (gone from v2) in one of my applications.)

Well you are wrapping around an object so you use a lot of this.v to access that objectI don't quite see why you use a class for this. A class is something that should be general - so why are you using globals instead of a parameter for In_Icon and Out_Icon.I also feel that your class lacks more methods and that your splash_icon method should actually be the constructor.

I added quite a bit to the second part - I think I will make a clean cut soon and start a second tutorial which ill cover slightly more advanced topics, that can really make the difference between a good useable class and some attempt at doing something.The third part is used for a special category I will call "Tips & Tricks and Ticks and Trips" which will summarize some of the things I have said, give additionaly information and suggest projects you can do by yourself or others have created that you can play around with.

Helgef wrote:Hello I read the second part now, it is very well composed .I have minor disagreements,

Avoid variable names that sound like they would make good class names

There is no need to think like this, especially not since forcelocal was recently added.

Avoid byref

Inside the called function it is not an issue, the caller can declare the byref variable as local. Byref is very useful, eg when passing big strings.

I have to say that I didn't have a look at recent developments regarding AHK in depth - towards me this local mode is news - it looks like good news.However within this tutorial I present design decision making and coding behaviour that has become a habit to me.Also I will still stand my word that it is better to avoid byref as an output variable in the context of OOP.You cannot expect the user of your class to use proper coding in order to avoid the drawbacks of byRef.You still could use byRef for the speedy input of data into a function or a method - however that speed gain is only possible for very limited cases where a variable is provided directly as the input.In other cases byRef doesn't provide any advantage. Working with variables that contain strings directly is very rare in my OOP style - I can imagine that it is the same for everyone and the same for OOP in general.In order to create fast OOP we will probably have to create a speedy String class. Actually testing it out convinced me - if you want fast strings with AHK OOP you will have to use a string class:https://autohotkey.com/boards/viewtopic ... 72#p195372

It is good advise I like that the tutorial led to a real piece of usable code Cheers.

Yeah I like that tip too.And I ill spend a lot of time on this class, because it is something very basic that I want people to built upon.I just plan to write this class and take you guys along for the ride.

nnnik wrote:Thanks for reading it.Did you have trouble understanding anything?Were there any parts that confused you?

No, it all made sense to me. The concept of the this. reference is not new to me, so I can't really give feedback on your explanation. But it is one of the confusing parts of the syntax. Just because it's difficult to put it into words, I guess.

If I hadn't been watching this thread and seen you were actively working on it, I probably wouldn't have read it. The first part laid things out well, now I want to get into the next parts as I have time, to learn the skills of it.