Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

Thoughts for v2.0


  • Please log in to reply
105 replies to this topic
Jackie Sztuk _Blackholyman
  • Spam Officer
  • 3757 posts
  • Last active: Apr 03 2016 08:47 PM
  • Joined: 28 Feb 2012
Ahk is my frist and only language

When i was studding the 1.1 native COM syntax i was able to just write it out after some time...

but with the GUI commands i still need to look up syntax and copy/paste to get Gui's done right in a timely manner.

so id also say +1 to what IsNull said.
Helping%20you%20learn%20autohotkey.jpg?d

[AHK] Version. 1.1+ [CLOUD] DropBox ; Copy [WEBSITE] Blog ; About

faqbot
  • Members
  • 997 posts
  • Last active:
  • Joined: 10 Apr 2012
I know very little about objects/oop/class/base/... - every time I see such code I don't understand what it means or how to "call" something, apply it etc. I use some of it but don't actually understand why something works or why it stops working.
I don't think you can in all honesty say that someone with a minor interest in programming / scripting will be able to understand this
g := new A_Gui("Window title")
new A_GuiLabel(g, "Hello world!")
g.Show()
a lot faster or easier compared to something "clunky" like
Gui, Add, text, , hello
Gui, Add, button, , OK
Gui, Show
(last post as this will remain a matter of opinion)

IsNull
  • Moderators
  • 990 posts
  • Last active: May 15 2014 11:56 AM
  • Joined: 10 May 2007

I know very little about objects/oop/class/base/... - every time I see such code I don't understand what it means or how to "call" something, apply it etc. I use some of it but don't actually understand why something works or why it stops working.

I completely understand you. OOP/class/base is all stuff which is advanced, and if you are talking about creating own objects (writing classes) it is advanced stuff. So I can understand your fear, that AHKs Gui programming may become as strange as all the other classes you have seen so far. This is not the case.

 

First lets make a fair comparison with your example:

 

Gui, Add, text, , hello
Gui, Add, button, , OK
Gui, Show

 

vs raw object usage:

myGui := new Gui
myGui.Add(new Text("hello"))
myGui.Add(new Button("OK"))
myGui.Show()

 

 

I would say that the both codes are equally readable. You even can read the Object based syntax as a English sentence. It is not necessary to mention that one has to read some theory to fully understand this syntax, but this is also valid for the old syntax. (With the difference, that object usage has not as many exceptions as AHKs Commands, so once you get it, you are done )

 

Now the above example is unfair. The real advantage in the Object approach is when you have to manipulate / change properties of the Gui, and when you have to adress specific components of the GUI. In any real scenario, you have to. fincs already pointed that out before.

The Command Syntax may work when you have one GUI. But if you have multiple ones, it really gets nasty and complicated.

 

One more thing: If you know what a Function/Method is, the you are done. This is one important point, because why I am against the "labels" and any other redundancy in the syntax- why do we have two separate syntax patterns for the very same thing?

Why do we have Commands and Functions? Why did we have simple assignments and those strange expressions?

Because Commands and Labels seemed to be more easy and understandable than the expression stuff. Maybe they are. But one can not do enough with it - thus has to use expressions. Now, the Newbie gets distracted.

 

You can do anything, only using functions/methods and expressions. It wont work vice versa. 

This is what my AHK Newbies confused the most. The help should provide a clear guide, to a clear syntax.



Frozenthia
  • Members
  • 59 posts
  • Last active: Sep 10 2013 07:12 PM
  • Joined: 18 Dec 2010

For me, I just think object approaches and function/method syntax look more beautiful. When I see "newbies" dealing with Autohotkey, it's usually just to take advantage of automation. I think the person who would opt for a GUI (I'm one of them, for sure) will be the same person who would be completely fine with learning the new syntax and becoming comfortable with it. So I agree with IsNull and fincs. 

 

Helping a thousand people do 100 lines of WinWait, Click, Sleep, 20, Click, makes me skeptical of syntax change of GUIs being an issue. 

Also, this. On a side note, when I think about it, I could think of a hundred nice features for GUIs, that would cut down awkward code. Append, for example.

 

GuiControlGet, ov, somegui:, someEditbox
StringUpper, ov, ov
GuiControl, somegui:, someEditbox, %ov%

; vs

someEditbox.Text := StrUpper(someEditbox.Text)
 


nothing
  • Members
  • 129 posts
  • Last active: Oct 03 2014 04:51 AM
  • Joined: 09 Jan 2010

+1 Frozenthia

I think we need take care more about GUI.

The current GUI system is a bit prolix ( as  Frozenthia mentiioned).

for (only) the syntax:

I suggest the fincs's GUI : http://www.autohotke...cludes-oop-gui/

Or the java swing syntax.

Also, we can have a look to Autoit GUI syntax which separate the position,size options into 4 parameters.

In my opinion,i like the fincs's gui syntax.


nothing is impossible with ahk (_L).
Excuse my bad English.
Busy

nothing
  • Members
  • 129 posts
  • Last active: Oct 03 2014 04:51 AM
  • Joined: 09 Jan 2010

:= must be used in place of = when initializing a declared variable or optional parameter.

All of the v1.1 functions and libraries may not run on v2 because of this change.

I think both ways :=  and =  can be acceptable.


nothing is impossible with ahk (_L).
Excuse my bad English.
Busy

fincs
  • Moderators
  • 1662 posts
  • Last active:
  • Joined: 05 May 2007

All of the v1.1 functions and libraries may not run on v2 because of this change.
I think both ways := and = can be acceptable.

The point of v2 is to break compatibility with v1.1 in order to improve language flexibility, consistency and usefulness.

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

In v1, = is a form of assignment. In v2 (as it is now), it is never assignment. Allowing it just for function parameter default values and/or variable declarations doesn't seem appropriate.
 

If you use :=, it will work on v1.1.09+ and v2-alpha.



nothing
  • Members
  • 129 posts
  • Last active: Oct 03 2014 04:51 AM
  • Joined: 09 Jan 2010

well, got it!

therefore, almost the functions and libraries should be updated to fix this change.

i think it's hard to do that or it's not a little work.

what about giving the both ways and give time for the coders to get used to with this change, and recommend in the document that :

"you should use ":=" instead of "=" because it will be force in some later version of autohotkey v2"

 

I mean that this change is a bit too fast. let everybody have time to get used to. Or (i think) a lot of coders would stay with v1.1.


nothing is impossible with ahk (_L).
Excuse my bad English.
Busy

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

Currently it is not possible to explicitly refer to a window whose title is literally "ahk_id something".

 

You can use regex; e.g. ahk\_id foo. Since you haven't offered any examples of how your idea could be implemented and I don't see how it relates to v2, I probably won't give it any further thought.

 

it may be a good idea to expose built-in OOP interfaces through the A_ prefix in order not to collide with user variable names.

 

Noted, although it looks a bit awkward.

 

File access and COM objects could perhaps work in the same way:

obj := new A_ComObject("InternetExplorer.Application") ; same syntax as ComObjCreate()
f := new A_File("somefile.txt") ; same syntax as FileOpen()

 

Rather than a class of objects, COM objects are essentially an entire category of classes.  I'm inclined to leave the syntax for instantiating COM objects as is.  For files, I think that FileOpen() is a lot more natural than new A_File() (e.g. because the file is not new...).



Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

Let me reiterate:
 

I think that the entire Gui system is outdated, and would require more time to review than I am willing to spend on it (at least for v2.0).

 

What this means is that I do not intend to review the Gui command prior to the full v2.0 release, if at all.  Further discussion about it is fine, but it is probably best if the discussion can be split from this thread.

 

I'll also note that while an object-based API for Gui or any other AutoHotkey functionality could be easily added on by scripts after the v2.0 release, certain parts of the current Gui system have to be more closely integrated - also, the current system is already complete.

 

I do not want this thread to become another place to post random wishes for v2.0 - adding to my plans - but about refining what I have already outlined.



jaco0646
  • Moderators
  • 3165 posts
  • Last active: Apr 01 2014 01:46 AM
  • Joined: 07 Oct 2006

Syntax

  • Require the ending percent sign. As guest3456 said, there is not enough benefit to justify omitting it.

 

Built-in Variables

  • Allow assignment.
  • Keep A_Tab and A_Space. Named constants are more readable than escape sequences.
  • Remove A_IsUnicode.

 

Commands

  • Remove Topmost and Trans.
  • Rename to WinRedraw.
  • Rename to WinGetControls and WinGetControlsHwnd.
  • Rename to MonitorGet... with multiple output variables.
  • Rename to DriveSetLabel
  • Merge GUI & Control, though I haven’t considered how since my original comment:

http://www.autohotke...-48#entry491057

 

Exceptions vs ErrorLevel

  • “Exception-handling can be very useful, but should not be required in the day-to-day scripts of average users,” should be the driving sentiment.
  • Provide a more explicit method of controlling whether exceptions are thrown (default to off).
  • Always set ErrorLevel.

 

Errors in Math operations

  • Treat "" as 0, but optionally display a warning.


Person93
  • Members
  • 443 posts
  • Last active: Feb 11 2014 12:07 AM
  • Joined: 26 Jan 2012

Regarding empty strings in math operations, I think that there should be a directive which defaults to having it throw an exception.

 

Additionally, the template for new scripts which comes with the autohotkey installation should include this directive with a brief comment explaining what it does.



Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

Person93, that sounds like...

Options I will not consider:

  • Treat "" as 0 or invalid, depending on a directive or setting.


guest3456
  • Members
  • 1704 posts
  • Last active: Nov 19 2015 11:58 AM
  • Joined: 10 Mar 2011

i vote for
 
Treat "" as 0, but optionally display a warning (enabled by #Warn).

and extend this for all non-numeric strings. i am fine is "" is treated as "" also, but in either case, some type of warning is a must