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.

[quote="nnnik"]Thanks for reading it.Did you have trouble understanding anything?Were there any parts that confused you?[/quote]

No, it all made sense to me. The concept of the [c]this.[/c] 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.

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.

[quote="Helgef"]Hello I read the second part now, it is very well composed :thumbup:.I have minor disagreements, [quote]Avoid variable names that sound like they would make good class names[/quote]There is no need to think like this, especially not since [i]force[/i] [c][docs]local[/docs][/c] was recently added.[quote]Avoid byref[/quote]Inside the called function it is not an issue, the caller can declare the [c]byref[/c] variable as [c]local[/c]. Byref is very useful, eg when passing big strings.[/quote]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.php?p=195372#p195372

[quote]It is good advise :thumbup: I like that the tutorial led to a real piece of usable code :thumbup: Cheers.[/quote]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.

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.

Put your classes inside another class and name your file after that class

It is good advise

I like that the tutorial led to a real piece of usable code

Cheers.

Hello I read the second part now, it is very well composed :thumbup:.I have minor disagreements, [quote]Avoid variable names that sound like they would make good class names[/quote]There is no need to think like this, especially not since [i]force[/i] [c][docs]local[/docs][/c] was recently added.[quote]Avoid byref[/quote]Inside the called function it is not an issue, the caller can declare the [c]byref[/c] variable as [c]local[/c]. Byref is very useful, eg when passing big strings.[hr][/hr][quote]Put your classes inside another class and name your file after that class[/quote]It is good advise :thumbup:

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.

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.

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.

[quote="derz00"]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 [c]this.[/c] :P 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.) [code]class splash { __New() { this.v:=GuiCreate("-Caption") this.v.SetFont("s16") this.v.AddText("r1 x5 w390 center","You have punched " status) this.v.SetFont("s18") this.st:=this.v.AddText("r1 x5 w390 center",status) this.p:=this.v.Add("Progress", "x50 w300 h20 cBlack") } splash_icon(status, timeout := 1600) { global In_Icon, Out_Icon TraySetIcon(status?In_Icon:Out_Icon) this.st.Text:=status?"IN":"OUT" this.st.Opt(status?"cRed":"cBlack") this.p.Opt(status?"cRed":"cBlack") this.v.Show("w400 h160") time:=A_TickCount+timeout while A_TickCount < time { this.p.Value := ceil(100-(time-A_TickCount)/timeout*100) sleep 125 } this.v.Hide() } __Delete() { this.v.Destroy() this.v:="" }}[/code][/quote]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 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. :P 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.)

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 [c]this.[/c] :P Is that just the way it is? Or there would be better ways to design it?

Hello again .It is a good read, well done . I like that you encourage planning, eg, with paper and pen, it really is helpful. I will add a little planning tips: Start by writing the documentation. This is not easy to do when one works on a project alone, because most often one is to eager to start coding, but for shared projects, it is key, imo. Another approach (sort of a digital version of the paper and pen suggestion or a good way to start after you have your plan on paper) is to write an empty class, that is a class which only contains methods and properties but no actual implementation. For the file example, one could begin to write this, and add comments about input/output/algorithms etc,...

This gives a good overview and is a good base for the documentation. You keep the sketch and then implement a copy of it, updateing the sketch if needed, when done with the implementation, much of the documentation is done too.

The method name __Init is reserved for this purpose, and should not be used by the script.

Thanks for your efforts.Cheers.

Hello again :wave:.It is a good read, well done :thumbup: . I like that you encourage planning, eg, with paper and pen, it really is helpful. I will add a little planning tips: [b]Start by writing the documentation[/b]. This is not [i]easy[/i] to do when one works on a project alone, because most often one is to eager to start coding, but for shared projects, it is key, imo. Another approach (sort of a digital version of the paper and pen suggestion or a good way to start after you have your plan on paper) is to write an [i]empty[/i] class, that is a class which only contains methods and properties but no actual implementation. For the file example, one could begin to write this, and add comments about input/output/algorithms etc,...[code]class File { __New( fileName ) { } getPath() { ; Useful comments about input/output and algorithms... } getPathName() { } getPathDir() { ;same as getDirectory } getPathDirectory() { } getPathExtension() { } getPathNameNoExtension() { } getPathDrive() { } move( newFilePath, overwrite := 1 ) { } copy( newFilePath, overwrite := 1 ) { } open( p* ) { } getSize( unit := "" ) { } getAttributes() { ;flag string see AutoHotkey Help: FileExist for more infos } changeAttributes( changeAttributeString ) { ;see FileSetAttrib for more infos } getTimeAccessed() { ;in YYYYMMDDHH24MISS see AutoHotkey help for more infos } setTimeAccessed( timeStamp ) { } getTimeModified() { } setTimeModified( timeStamp ) { } getTimeCreated() { } setTimeCreated( timeStamp ) { } delete() { }}[/code]This gives a good overview and is a good base for the documentation. You keep the sketch and then implement a copy of it, updateing the sketch if needed, when done with the implementation, much of the documentation is done too.[hr][/hr]

[quote]__init() is not even documented[/quote]It is mentioned under [url=https://autohotkey.com/docs/Objects.htm#Custom_Classes_var]instance variables[/url].[quote]The method name [c]__Init[/c] is reserved for this purpose, and should not be used by the script.[/quote][hr][/hr]Thanks for your efforts.Cheers.