I was quite busy recently so I didn't follow the discussion up until today. I have read up to the page 6 and will comment now, so sorry if something is already discussed on subsequent pages which I will read later.
First of all, congratz for this great work. Amazing. Now AHK looks like real language, finally.
Bellow I will mention some things that I think deserve attention. Oterwise, I agree with Lexikos on everything else.
Lexikos wrote:
Legacy commands to consider keeping (for convenience): IfWinActive, IfWinExist, IfInString, IfExist. I personally don't find IfInString all that convenient. Should it be kept? Should the others be kept?
I would remove those. It's much more logical to use pure "if" form. The benefit is that you reduce the number of constructs available and number of documentation pages and unnecessary redudancy which all lead to confusion.
Lexikos wrote:
As a substitute for SetFormat (which has been removed), I've included a script function for formatting strings. Take a look in Lib\format.ahk for a description of the syntax. It is basically a mixture of .NET's String.Format function and the C runtime's format specifiers. Any comments or suggestions about the syntax are welcome. Once the syntax is finalized, I'll add a built-in function.
Why do we need this? Since replacement of ahk vars in the literal strings is already done, why not adding some formating chars to it: "My integer: %num%, my hex: %num:h%", or something similar. This is so 'every day' that it should be integrated this way.
Lexikos wrote:
I've wondered for a while why we have commands like WinSet and WinGet with numerous sub-commands, then separate commands like WinGetClass and WinSetTitle
I would personaly like to see it as an object. For instance if W represents window obtained by some mean, we could use w.tittle, w.pid etc... There are few aditional benefits of this approach, other then the convenince and reduced number of commands - you could choose evaluation type - i.e. in lazy mode don't get the tittle unless its used. You could call W.refresh() later if you want update, which is faster then repeating all the code again, or using functions; you keep it as organised whole as it is (some
other automation languages used this approach); you can easily save entire info using json; also, you could specify which attributes of the window to get asap and which are the lazy ones, lets say WinExist("Notepad", class pid title children) will preload given attributes and lazy load other ones you may eventually need. WinExist("Notepad") could give only handle, WinExist("Notepad", *) could give everything. Just an idea, could be improved probably.
Lexikos wrote:
The idea is that expressions may be embedded in a non-expression arg by writing %func(params) or %(expression). I believe this will require extensive changes to implement properly, so it probably won't be implemented in v2.0. However, I will add support for the simplest case, %(var), if there's enough demand for it.
I would personaly like to see this in v2. I am talking about the complete idea.
Lexikos wrote:
Window groups could be improved to make exclusions more intuitive – e.g. GroupExclude G, title would combine with existing rules to exclude all windows with “title” in the title, whereas GroupAdd G,,,, title currently adds all windows to the group, except those with “title” in the title. Furthermore, supporting ahk_class, ahk_id, etc. in the exclusions could prove very useful.
If windows as objects are implemented, groups follow naturally as collection object:
Code:
wndGroup := WindowGroup()
wndGroup += WinExist("Notepad"); add all notepad windows to the group, WinExist returns window object
wndGroup -= "ahk_class Notepad" ;remove all notepad windows from the group
wndGroup[i] ; i-th element of the group
wndSubGroup := wndGroup["Notepad"] ;get all notepad windows from the group into new group
wndGroup.toString("(%w.pid) %w.tittle , Childrens: %(w.children.count)") ;get the list of windows using given format string.
Quote:
Should SubStr(str, -1) extract the last two characters of str as it does now, or only the last character?
The last one only IMO.
Lexikos wrote:
If someone is keen to write a replacement for these, I'd consider removing them; but it doesn't seem worth much trouble.
I vote for removing completely. Garbadge, IMO.
Fincs wrote:
Auto-concat is one of my favourite features of AHK, so please don't remove it.
I totally agree. I you still wish to remove something, remove the dot
Leraning one wrote:
Too much versions and forks of AutoHotkey, different syntax, different rules = bad.
Transition is always initial suffering for the benefit of the improved life later on.
Lexikos wrote:
By the same token, the functionality of "in" and "contains" could be implemented as methods of the array object. There's no real need for additional syntax.
Perfect.
jaco0646 wrote:
Other random ideas:
#SingleInstance
Should this be the default?
SetTimer
Should this make scripts automatically #Persistent?
ListLines, Off
Should this be the default? Chris mentions that it increases performance.
GuiClose
Should ExitApp be the default? It's definitely the most common behavior for the GUIs I've written.
All good suggestions IMO.
IsNull wrote:
For AHK v2 I recommend to remove the Commands completly and replace them with Build-In Methods.
I agree. Further benefit is adoption of named parameters (InputBox example) as those are planned for function arguments.
Lexikos wrote:
At least two notable forum members have expressed a desire to remove literal assignment (var `= value) entirely. I like this idea. Do you?
I think it has its merrits.
IsNull wrote:
First off, keeping Commad-like Syntax is bound to also keeping the "traditional" Variable dereferecing %var%.
Totally agree. Also, perhaps making parenthesis "(...)" optional, like in VB or Ruby is good way to keep newbes happy and not to make some commands worse, like MsgBox which is used with only 1 param mostly. So, "msgbox( str ) = msgbox str" and "fun(a1, ... aN) = fun a1, ... aN".
My additions:
- Change MsgBox name to Msg. It deserves this as it is used all the time. Also, it can be changed so that outputs messge in console for console scripts, so dropping "Box" is intuitive - msg displays message. You might really want to display GUI box in console window but that is not something people typically want.
- More integrated object - Registry for instance, different collections (file, window etc...) This can maybe provide framework for replacing all different loop commands with only one that accepts object capable of iteration along with object that holds iteration options, ideally with neat syntax sugar.
- Integrated lowlevel.ahk
Login
Register
FAQ
Search
