tl;dr:
- a 3-page summary of tips for writing the source code would be good
- ... and a C++/source code forum [EDIT: we now have one]
- AHK v2 is often simpler than AHK v1, e.g. command syntax/force expression/can be an expression/legacy if removed, fewer oddities
- priorities: in/contains, Loop, window groups, renaming/splitting ControlXXX functions by control type
Re. the development of AutoHotkey and delegation.
- If I was a main dev on a freeware project, I'd be wary of tying people in, and nagging them, to do more work than they had the time to do. I'd also be concerned whether their code would be good enough, and therefore whether their code would do more harm than good. Correcting code being potentially more time-consuming than writing it from scratch.
- Contrariwise, as a dev offering my services, I'd be wary of trying to be helpful, but actually being more of a nuisance. Making constant but unhelpful requests, re. 'what else I can help with'.
- If there were to be any delegation, the main devs could say: any takers for writing code X to do Y. With potentially multiple people attempting the same code. People would be just as willing to help here as they would on other AHK subforums. Sometimes I get the big green tick, sometimes I don't. And I don't mind my script not being chosen.
- We could have a C++-athon, where coders are challenged to write stand-alone console apps to achieve certain goals, code that could be used in future versions of AutoHotkey. That way people who don't even know AutoHotkey very well, could potentially be of use. The main devs could make certain stipulations that would make the code easier to incorporate into AutoHotkey.
- I'm learning C++, I've asked for a 'C++ for AutoHotkey forum' to be set up, perhaps within the Other Programming Languages forum, I have a few C++ template scripts, I'm reading the source code and old posts regarding the source code. If the main devs had any kind of 3-page summary of things to know about the AHK source code, that would be amazing to read. I am working on this myself, and/or longer versions, but other people could do a better job right now.
- One potential idea of interest. I was surprised that there isn't a development forum. Where a main dev could say: 'does anyone have any code or links related to this issue'. I.e. 'Ask For C++ Help' / 'Ask For Source Code Help'. To just in general read C++ experts discussing points about the source code.
Re. simplicity and AHK v1 and v2.
- You can only make the language so simple. Anyhow, people will still ask on the forum how to send these characters +^#?{}.
- Generally speaking, syntax-wise, AHK v2 is a subset of AHK v1, with various bits of syntax removed. Therefore it's simpler. You don't have to explain parameter nuances and things like 'force an expression' and 'can be an expression'.
- Having two ways to do the same thing isn't normally a problem. The problem is ambiguity, when you don't know which one of two ways will work.
- When working on beginner tutorials, which I will post soon, I found it much easier to write a tutorial for AHK v2 than for AHK v1.
- Also, functions are 'easier' than commands if you're familiar with sheet functions in Excel.
Re. AHK v2.
- From my perspective, development is happening quite quickly. Most of the decisions have been made, and now the future of the Menu command has been resolved. I'm interested re. any changes to control flow statements or directives, these haven't been mentioned much in 'Thoughts for v2.0'. And whether lines like
if (a contains b) && (c in d) will be possible.
- Some points I might make:
- I feel that eventually, the benefits of function names such as EditXXX, LVXXX, TVXXX, LBXXX, CBXXX, applicable to internal/external controls, will become apparent, e.g. LBGetItems/CBGetItems. It's a neat solution to various problems. Also, if additional GUI functions for AHK are added/proposed, the benefits will become further apparent.
Control Functions
https://lexikos.github.io/v2/docs/commands/Control.htm
[EDIT: See more points at the very bottom of this post.]
- Window groups. It might be useful have window groups based on regular arrays. A syntax such as ahk_xtitle/ahk_xclass/ahk_xexe to exclude certain window might be useful. [EDIT: I would probably get by fine without this, but when I first started using AHK, I'd wondered about more granular control of window groups, in particular emptying them.]
- A mode that is stricter about the use of []/() in COM objects might be beneficial. [EDIT: Ignore this. I'm more interested in a script to detect such lines, and to not change the behaviour of AHK. Especially after rereading 'Thoughts for v2.0'.]
Re. ControlXXX functions.
- [EDIT:] For certain ControlXXX functions, specific to certain control types, the most sensible thing to do may be to create functions with the control type in the name.
- One reason is that when I look at, for example, ControlShowDropDown/ControlGetCurrentLine/ControlGetSelected/ControlAddItem, I instantly think, which control type is that for, will it work with the control I'm working with.
- Seeing multiple functions specific to a particular type of control, identified by their prefixes, makes it easier to follow the logic of the script.
- I would say as a rule of thumb, a ControlXXX function should only be called ControlXXX if it works with six control types or more.
- People will naturally be reluctant to add more ControlXXX functions to AHK, with the 'Control' prefix, that only work for one type of control.
- There were a lot of listview/treeview functions in AHK v1, and so having LV/TV prefixes would be consistent with this.