v2-thoughts Discussion

Discuss the future of the AutoHotkey language
lexikos
Posts: 6042
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: v2-thoughts Discussion

13 Apr 2014, 21:24

fincs wrote:Plus, losing the ability to dynamically access properties is IMO undesirable.
So don't opt in.
This happens because there is no true separate Null value.
If there was, there would be the problem that dynamic properties couldn't return null as their actual value. SYM_MISSING is intentionally limited to parameter lists, so there is never ambiguity.
User avatar
fischgeek
Posts: 422
Joined: 29 Jan 2014, 21:39

Re: v2-thoughts Discussion

15 Jul 2014, 13:31

At what point (or where) can we discuss the "Gui API" as fincs put it?
lexikos
Posts: 6042
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: v2-thoughts Discussion

15 Jul 2014, 20:00

Whenever you feel like it, in a new thread. I don't intend to do any work on it myself.
User avatar
fincs
Posts: 500
Joined: 30 Sep 2013, 14:17
GitHub: fincs
Location: Seville, Spain
Contact:

Re: v2-thoughts Discussion

16 Jul 2014, 04:28

You may want to see my own GUI API redesign thread.
fincs
Windows 10 x64 Build 17134 / AutoHotkey v1.1.29.01
Get SciTE4AutoHotkey v3.0.06.01 - [My project list]
guest3456
Posts: 2359
Joined: 09 Oct 2013, 10:31

Re: v2-thoughts Discussion

28 Aug 2014, 16:26

Not sure where to ask this..

@Lexikos

In your mind, what is required before you will promote v2 from alpha to beta or even stable? Are there any specific fixes/features/improvements/milestones that you are looking at?

lexikos
Posts: 6042
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: v2-thoughts Discussion

29 Aug 2014, 01:57

I will consider that when I complete or remove everything from the list.
guest3456
Posts: 2359
Joined: 09 Oct 2013, 10:31

Re: v2-thoughts Discussion

29 Aug 2014, 15:01

Ah ok, so the v2-thoughts is in fact the first things that need to be addressed. Ok

Also just for reference, here are HotKeyIt's opinions, since he ended up posting in a different thread last year:

HotKeyIt wrote:That sounds good for v2 :)

I have gone through v2 thoughts, following are outstanding items as I understand, hope I covered all.
Probably we should create a poll to get the things rolling, we can always revert back if necessary.
Alternatively everyone could reply with his opinion (keeping all items in the list and adding +1 or -1 in front.
As soon as we have 20 - 40 replies or some time is gone I could download them and evaluate.

Following already incudes my opinion and considers asap completion.
  • Keep A_Tab / A_Space
  • Keep A_IsUnicode, no need for A_ChrSize or A_StrEncoding.
  • Sub Commands for DriveGet, Drive should be created, or even better to rewrite in AutoHotkey for stdlib
  • Control... and Gui, should keep their sub commands.
Standard Library:
  • For next release of AutoHotkey_H v2 I have already converted following functions that can be used where we agree, I plan to convert even more:
    • DirCreate.ahk
    • Download.ahk
    • FileCreateShortcut.ahk
    • FileGetShortcut.ahk
    • FileGetVersion.ahk
    • FileRecycle.ahk
    • FileRecycleEmpty.ahk
    • ImageSearch.ahk
    • MenuSelect.ahk
    • PixelGetColor.ahk
    • PixelSearch.ahk
    • ProcessClose.ahk
    • ProcessExist.ahk
    • ProcessSetPriority.ahk
    • ProcessWait.ahk
    • ProcessWaitClose.ahk
    • SplitPath.ahk
    • ToolTip.ahk
    • TrayTip.ahk
  • Rename MouseClickDrag to MouseDrag.
  • Remove Click and don't use flexible parameter ordering, keep MouseClick for consistent syntax.

Error Handling:
  • Exception vs. ErrorLevel
  • I suggest adding a directive or command to change the setting as user likes, default should be ErrorLevel.
  • The directive and command can have a list of functions/commands the user wants to change, also supporting * wildcard

Code: [Select all] [Download] GeSHi © Codebox Plus

#UseException ; enables to use exception where appropriate for all build in functions/commands
#UseException * ;same as above
#UseException, DllCall File* Control* Gui*
UseExcepiton("Gui* Control* File*",1) ; Set to use Exception
ExceptionIsOn := UseException("Gui* Control* File*") ; returns 1 which means all given commands use exception
ExceptionIsOn := UseException("Drive") ; returns 0 so Drive uses ErrorLevel
ExceptionIsOn := UseException("Drive Gui*") ; returns -1 to indicate mixture

  • ErrorLevel should be always set or returned, even if id does not make sense, even for successful DllCall, just for consistency.
  • Errors directly relating to expression evaluation, such as invalid dynamic function calls or stack underflow (typically caused by undetected syntax errors) should throw exception.

Math:
  • Use exception for error in math operation where appropriate.
  • Treat "" as 0, but optionally display a warning (enabled by #Warn).
  • Math functions such as Round() should have the same behaviour as math operators.
Based on the fact that "" stands for nothing and from my understanding human brains says (nothing + 1) = 1 and not (nothing + 1) = nothing.
Another reason is the way Autohotkey implements the variable, it is treated like a placeholder for numbers, strings, memory, object.... Imagine variable is a container, then: [container with 5 kg of something] + [empty container] = 5 kg of something ; or does your brain think different?

Objects:
  • Throw an exception when a memory allocation failure occurs
  • Throw an exception when a method call fails if it was because the method doesn't exist or there were too few parameters.
  • No need for in/contains/is, use Type() and other workarounds like InStr( ",list,of,items," , "," item "," ) or {list:1,of:1,items:1}.HasKey(item)
  • Obj.HasValue() would be great to have, then even ["list","of","items"].HasValue(item) can be used

Classes:
  • Make base a reserved word in class methods.
  • leave "".base as it is.
  • Allow the script to define global methods, skip that for the moment.

WinGroup:
  • Remove ExcludeTitle and ExcludeText from all commands, and add a new command or parameter for adding negative rules to a window group

COM:
  • Remove the "polymorphic" behaviour of the ComObj() function

Wishes from my side, simple to take over from AutoHotkey_H (lexikos, if you like I can do a poll request on github):
  • Implement Struct() and sizeof()
  • Implement OnMessage for specific hwnd, e.g. OnMessage(0x0,0x123ahk,"Function")
  • Allow Function object in OnMessage, e.g. OnMessage(0x0,func) ; where func is a function object.
  • ahk_parent %hwnd% for all Win... commands. Useful when you have 2 MsgBox from separate AutoHotkey scripts
  • Sleep {} in Send command, e.g. Send a{100}b
  • A_CoordMode... variables to get current CoordMode, required for example for ToolTip.ahk if it goes to standard library


from
viewtopic.php?p=1540#p1540

gps4213
Posts: 1
Joined: 15 Dec 2014, 14:02

Re: v2-thoughts Discussion

15 Dec 2014, 16:09

tank wrote:
lexikos wrote:That would add overhead and has no apparent purpose.
I might add its a little programmer centric as well. objects are in general difficult enough for non programmers to grasp lets not do things just for the sake of oop



Long time user, first time poster.

I am not the sharpest tool in the wood shed, but I am smart enough to make my own programs, albeit slowly, with AHK. I have a difficult enough time with.this.and.that would really kill my use of AHK. But I do know and see how useful that would be.

As long as the low level programmers like me can still use AHK 1/1.1, I am happy to see AHK get some needed improvements.

Thank you all for the years of time you have worked on this project.

Guy
User avatar
WAZAAAAA
Posts: 72
Joined: 13 Jan 2015, 19:48

Re: v2-thoughts Discussion

02 Jul 2015, 05:20

Is there any plan on making v2 multithreaded like AutoHotkey_H/AutoHotkey.dll/AutoHotkeyMini tried to?
YOU'RE NOT ALEXANDER
lexikos
Posts: 6042
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: v2-thoughts Discussion

03 Jul 2015, 01:33

No. That's entirely beside the point of v2.

This thread is about a document which contains tentative plans for v2. If it's not in that document, it's not planned.
guest3456
Posts: 2359
Joined: 09 Oct 2013, 10:31

Re: v2-thoughts Discussion

03 Jul 2015, 12:05

besides, why not just use AHK_H if you need that?

lexikos
Posts: 6042
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: v2-thoughts Discussion

08 Apr 2017, 04:54

I have significantly updated v2-thoughts (I usually do minor updates after each alpha):

Brief passing mention of the replacement of Gui/GuiControl/GuiControlGet (see here).
More detail for DriveGet, Drive and Control getting treatment similar to WinSet/WinGet.
My thoughts about FileRead and FileAppend, which I recently decided are too inconsistent.
Some tentative thoughts about binary data (the can of worms I opened when I improved support for binary zero in strings).
ClipboardAll.
Expression operators (in/contains).
Syntax for properties vs methods (are inconsistent).
WinTitle and window groups with exclusions.
User avatar
jeeswg
Posts: 4787
Joined: 19 Dec 2016, 01:58
Location: UK

Re: v2-thoughts Discussion

08 Apr 2017, 08:06

[quick link to page to save people having to search for it]
v2-thoughts
https://autohotkey.com/v2/v2-thoughts.htm

DETECTHIDDENWINDOWS

This is a genius idea, and saves the need for a further parameter:
Title ahk_mode 3 ahk_dhw 1

I would have:

Code: [Select all] [Download] GeSHi © Codebox Plus

ahk_dhw 0 ;V
ahk_dhw 1 ;VH
ahk_dhw 2 ;H

Cf. the old-style loop, 0/1/2=files/both/folders.

I had thought just now, possibly:

Code: [Select all] [Download] GeSHi © Codebox Plus

IfWinActive, Notepad ahk_!class Notepad ahk_!title - Notepad
IfWinActive, Notepad ahk_xclass Notepad ahk_xtitle - Notepad
IfWinActive, Notepad ahk_nclass Notepad ahk_ntitle - Notepad
IfWinActive, Notepad ahk_notclass Notepad ahk_nottitle - Notepad


FILEREAD

The best solution for FileRead would be to assume it's off. No new user would assume that text is being altered by default as it's read by FileRead or appended by FileAppend. Users absolutely have to be warned about CRLF v. LF anyway, you can't avoid or hide the problem. FileRead has a *t option, that's probably the best approach.

Btw does anyone actually use EOL translation, I've done a million things with strings and never wanted that. Surely a parsing loop with omit CR, or replacing CRLF with LF retrospectively is fine or better.

Btw *Pnnn is misleading, e.g. it can't handle UTF-16 BE and it doesn't mention this in the documentation. What other encodings are not supported by *Pnnn? Have any users asked for other encodings to be supported?
This:
https://autohotkey.com/docs/commands/FileEncoding.htm
links to this:
http://msdn.microsoft.com/en-us/library/dd317756.aspx
But which of those encodings are/aren't supported is not stated.

FileRead *c is one of the most useful things in AutoHotkey. I use it all the time. I would even like *cnnn, so that you can read the first n bytes of a file only.

Btw is there an encoding option to force FileRead/FileAppend with the default ANSI codepage, rather than *P1252 which is specific.

So an options parameter might have: t0 (EOL translation off, the default), t1 (EOL translation on, or also 't' by itself), P1252 (ANSI, or maybe 'P0'/'CP0' for default ANSI codepage cf. StrGet/StrPut), c4 (read first 4 bytes of a file as binary, I'd imagine that the authors' preferences would be to change this to something like 'r4'/'b4', 'raw'/'binary').

VARSETCAPACITY

VarSetCapacity should stay as it is, it should measure bytes not characters. I don't care if I have to use *2 every time. Sometimes I use it for strings (chars), sometimes I use it for it binary structs (bytes). *Maybe* you could have a 4th parameter to specify that the 2nd parameter means chars, or a 4th parameter as an 'options' parameter, or a separate function called VarSetLength.

Btw we need a 64-bit compatible version of wOxxOm's InBuf function to search for an odd/even number of binary bytes, or return results at odd/even offsets. RegExMatch can only handle even-sized needles/result offsets. I'm trying to read up on machine code/assembler to do it myself, but I'm new to it, if anyone wants to assist me at the link or do it themselves.

InBuf function currently 32-bit only (machine code binary buffer searching) - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=28393

IN/CONTAINS

Has anybody considered a normal function for this? E.g. StrContains, ArrayContains, ObjContains.

==================================================

[EDIT:] More comments.

CONTROL

Control Choose/ChooseString should be 2 separate functions: 'ControlChoose', 'ControlChooseString'.

CLICK/MOUSECLICK

MouseClick should have 3 parameters:

Code: [Select all] [Download] GeSHi © Codebox Plus

MouseClick, options, x, y
MouseClickDrag, options, x1, y1, x2, y2

Combine the capabilities of Click and MouseClick to give just MouseClick. 'MouseClick' and 'MouseClickDrag', rather than 'Click' and 'ClickDrag', to fit with 'MouseMove'.

The following is incredibly confusing, and reminiscent of MsgBox's parameter problems, this is just the sort of unfortunate AHK v1 quirk we should get rid of:


Current 'click' commands:
Click, MouseClick, MouseClickDrag, ControlClick, SendXXX, (ControlSendXXX).
Last edited by jeeswg on 08 Apr 2017, 13:40, edited 12 times in total.
guest3456
Posts: 2359
Joined: 09 Oct 2013, 10:31

Re: v2-thoughts Discussion

08 Apr 2017, 10:46

lexikos wrote:I have significantly updated v2-thoughts (I usually do minor updates after each alpha):

Brief passing mention of the replacement of Gui/GuiControl/GuiControlGet (see here).
More detail for DriveGet, Drive and Control getting treatment similar to WinSet/WinGet.
My thoughts about FileRead and FileAppend, which I recently decided are too inconsistent.
Some tentative thoughts about binary data (the can of worms I opened when I improved support for binary zero in strings).
ClipboardAll.
Expression operators (in/contains).
Syntax for properties vs methods (are inconsistent).
WinTitle and window groups with exclusions.



very thorough. i'm not sure about in/contains being object only and not strings, but 'in' would then suffice for the oft requested .HasValue() method

one question:

https://autohotkey.com/v2/v2-thoughts.htm wrote:Gui, GuiControl and GuiControlGet are being replaced with GuiCreate() and Gui/GuiControl objects.


at what point would it ever make sense to just remove all Commands in favor of Functions? GUI seems like a big command to change, forcing users to use Func/Expression syntax. or do you think that people will call the new GuiCreate() func in command style?

lexikos
Posts: 6042
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: v2-thoughts Discussion

08 Apr 2017, 19:58

jeeswg wrote:The best solution for FileRead would be to assume it's off.
I'm not sure what you think that's solving. That's already how FileRead is, and I don't think I implied that would change.
Btw does anyone actually use EOL translation,
Yes.
Btw *Pnnn is misleading, e.g. it can't handle UTF-16 BE
I believe that the listing of UTF-16 on the page of "Code Page Identifiers" is erroneous. My view is that "code page" is synonymous with "ANSI code page", and UTF-16 is clearly not ANSI. That aside, *Pnnn does support the values for UTF-8 and UTF-16-LE, which are not code pages.

The documentation only says that it must be a numeric code page identifier, not that it can be any code page identifier. If anyone tries an unsupported identifier they'll quickly find that it doesn't work. The fact that FileEncoding only lists "UTF-16" as synonymous with little endian is a hint toward the lack of support for UTF-16-BE. I'm not inclined to mention it because it is so very rare. UTF-7 isn't supported either...

There are probably even ANSI code page identifiers which work on some systems and not others.
Have any users asked for other encodings to be supported?
Not that I recall, but I wouldn't be interested anyway.
FileRead *c is one of the most useful things in AutoHotkey.
It is, however, completely redundant if you're not reading clipboard data.
Btw is there an encoding option to force FileRead/FileAppend with the default ANSI codepage
Yes, it's 0, as defined by the SDK (CP_ACP).
VarSetCapacity should stay as it is, it should measure bytes not characters.
No, it shouldn't.

(That was just for arguments sake.) Why should it? Without this, your opinion alone carries no weight, even if it is written with false authority (which quite frankly irritates me). How you use VarSetCapacity now is irrelevant if you don't explain why you should continue using it that way. For instance, is there some error with the logic "[Structs] should use VarSetLength, since the entire length of the structure is meaningful"?
or a separate function called VarSetLength.
I never suggested that VarSetCapacity would be used to set the length of a variable. In fact, I already suggested "VarSetLength" in v2-thoughts.

The whole point of calling VarSetCapacity into question was that it specifies the variable's capacity, not it's length. A length of n means the variable contains n bytes (or characters) of data. Any bytes in memory beyond that length are just junk (if the length itself has any meaning whatsoever). If both the length and the capacity of a variable can be specified, it makes much more sense to specify the length of a struct than the capacity of the thing holding it.
Has anybody considered a normal function for this?
Sure. Next question?

Operators are more expressive. The way Chris put it, "This kind of thing seems like a big benefit in improving the readability and flexibility of expressions."

On the other hand, that was before objects. Arr.HasValue(Val) is not much different to Val in Arr, maybe even clearer. That would eliminate the (unasked?) question of how or whether Val in Obj should be handled when Obj isn't an array (even though there's currently no clear distinction between arrays and other objects). In JavaScript, "A" in {A: 1} is true and "A" in ["A"] is false. Using HasKey() or HasValue() makes it clear, and also provides a way to specify case sensitivity that doesn't involve changing a thread-global setting.

I think that the most intuitive meaning for "in" is to search in an array. Other operators could find whether an object has a property, or whether it can perform an action (call a method). (I'm not really inclined to implement these other operators, though.)

As for functions, there's hardly any difference between the implementation of a built-in function and the implementation of an operator. The questions of which operations to support and what the behaviour should be would apply either way.
Control Choose/ChooseString should be 2 separate functions:
There you go again. You should at least minimally attempt to explain your opinion, otherwise I'm inclined to ignore it.
The following is incredibly confusing
I will probably never understand why that would confuse anyone.

Also consider Send {Click ...}, which has the same syntax as the Click command.

guest3456 wrote: i'm not sure about in/contains being object only and not strings,
Who said that? I wrote "Someone suggested" and then explored the alternatives, but didn't mean to imply that the current functionality wasn't an option. I did forget to mention my opinion that a comma-delimited list would often be more convenient and readable than any alternative.
at what point would it ever make sense to just remove all Commands in favor of Functions?
I'd prefer not to discuss that here, or yet. I will say that I've put serious thought into it for several years.
GUI seems like a big command to change, forcing users to use Func/Expression syntax. or do you think that people will call the new GuiCreate() func in command style?
No one is being forced to use func/expression syntax for GUI (except that assignments require expression syntax). It is perfectly feasible to use command syntax for most parts of the GUI, only now the command syntax is cleaner and can be used where it couldn't before (like with ListViews). If everyone uses expression syntax (with v2 in its current state), it isn't because they are forced to do so.
guest3456
Posts: 2359
Joined: 09 Oct 2013, 10:31

Re: v2-thoughts Discussion

08 Apr 2017, 20:13

i'd forgotten that Obj.Method, param1, param2, ... now works as command syntax

User avatar
jeeswg
Posts: 4787
Joined: 19 Dec 2016, 01:58
Location: UK

Re: v2-thoughts Discussion

08 Apr 2017, 22:36

I was referring to FileRead/FileAppend/StrGet/StrPut together. I think that EOL translation should be off by default, for both FileRead and FileAppend, partly for consistency, and that 'P0' or 'CP0' should be available to FileRead and FileAppend. I'm not bothered if one function uses 'P' and one function uses 'CP', but it's worth mentioning.

I find it difficult to conceive of why anybody would want EOL translation, if anyone would care to offer an answer. If more people don't use it than do use it, then that's an argument for having it off by default.

I've added support for UTF-16 BE to the Notepad replacement I'm creating, because Notepad has it. I don't know how common its usage is.

It is, however, completely redundant if you're not reading clipboard data.

I'm surprised by this, I don't use it for reading the clipboard contents, I use it for putting the contents of binary files into variables, *cnnn would allow grabbing the first few bytes only, for file type identification. It's a one-liner, and there's no advantage to using a File object instead.

Re. 'CP0'. It is possible I have made a mistake here, however:

Code: [Select all] [Download] GeSHi © Codebox Plus

FileRead, vText, % "*P0 " vPath ;this opened a UTF-8 file as UTF-8 rather than forcing ANSI
FileAppend, % vOutput "`r`n", % "*" vPath2, CP0 ;file was UTF-8, appended as UTF-8 rather than forcing ANSI
FileAppend, % vOutput "`r`n", % "*" vPath2, CP1252 ;file was UTF-8, appended as UTF-8 rather than forcing ANSI


Re. VarSetCapacity. Apologies, I've just read that bit again (and your additional comment), and I still don't know what you meant, otherwise I would have given a fuller comment at the time.
- Are you saying that TVITEM has a 'length' of 56/40 bytes. Personally I would never use the word 'length' for that, but maybe it's common in some circles. You could potentially have something like 'VarSetCapacityBytes', 'VarSetCapacityChars', but to change the meaning of VarSetCapacity would be very inconvenient, and I think 'capacity' implies 'bytes' rather than 'characters'.
- Does a UTF-16 string with 4 characters have a 'length' of 8 bytes and a 'capacity' of 4 characters, or a length of 4 characters, and a capacity of 8 bytes? With UTF-8, size in bytes becomes even more useful when talking about size/'length'/capacity.

Re. in/contains. If I want to do something in AHK, I use a function. Since in/contains were scheduled for removal, I've been using StrIn/StrContains functions, just fine. I, personally, don't see the need for the special syntax just for one function.
- Although Chris is right 99% of the time, and I do greatly appreciate his work as one of the two main contributors to AutoHotkey, other people do use AutoHotkey.
- Regarding expressiveness, StrContains(string, list), StrMatch/StrMatchList(string, list) are reasonably expressive.

Re. Control Choose(String). I would have said more about Control Choose/ChooseString, but nothing was said in the post about why the two should be combined, and so I'm still unsure for the rationale. If you combine the two, you need another parameter.
ControlChoose(string) to get the 1st occurrence of an item?
ControlChoose(string, num) to get the nth occurrence of an item?
ControlChoose("", num) to get the nth item?
- What if the item's string itself is blank? Hence, so that nothing can ever go wrong, keep them separate.
- If using the rationale of treating a number stored as text differently from a number stored as a number? There is a lot that could be said on that issue, I would say, avoid this at all costs, and thus, keep the functions separate.
- Also, I believe the AHK v2 approach is to avoid, where possible, using blank parameters.
- I had relevant concerns when I wrote these:
JEE_FirefoxFocusTabByNum(hWnd, vNum)
JEE_FirefoxFocusTabByName(hWnd, vTitle, vNum=1)
JEE_ChromeFocusTabByNum(hWnd, vNum)
JEE_ChromeFocusTabByName(hWnd, vTitle, vNum=1)

Re. Click. I don't think that Click within Send is any better than Click by itself.

- So '2' has a different meaning without the comma. Is that click right twice, or click right at '2,5', is 'right 2' one parameter? If a command was ever confusing, then this is it. At least 'x2 y5' could be used.
- Furthermore this was the one difference I had with Coco, over converting AHK functions, he thought they should be regarded as separate parameters, I thought the whole thing should be regarded as one parameter.
- There are disadvantages to both approaches, hence, in my view, better just to have a normal 3-parameter function.
[EDIT:] In retrospect I think the main problem is the comma, remove the comma, and use x0 y0 instead, and everything looks pretty good. A space-separated list, all within one parameter. The only problem though, is how to specify the 2nd set of coordinates for MouseClickDrag, xx0 yy0, maybe (not great), xd0 yd0, for destination? You wouldn't even need a separate MouseClickDrag function.

Changes in the past have caused me untold difficulties, I'm not going to hide my views now, but I hope that I don't come across harsh, I'm a big supporter of AHK v1 and AHK v2.
lexikos
Posts: 6042
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: v2-thoughts Discussion

09 Apr 2017, 03:19

Re. 'CP0'. It is possible I have made a mistake here
As you showed, it has nothing to do with CP0, since CP1252 has the same effect. See the documentation.
FileOpen wrote:Encoding: The code page to use for text I/O if the file does not contain a UTF-8 or UTF-16 byte order mark,

but to change the meaning of VarSetCapacity would be very inconvenient
Converting scripts if VarSetCapacity is renamed to VarSetCapacityBytes (or some shorter and more convenient equivalent) would be extremely trivial.
Does a UTF-16 string with 4 characters have a 'length' of 8 bytes and a 'capacity' of 4 characters [...]
A string does not have "capacity". The buffer in which the string resides has capacity. When writing C++ code, or probably in any other language (except when dealing with low-level memory allocation functions), the capacity of a string buffer is measured in the base unit of the string, which is "characters" (actually wchar_t, code units, or whatever), not bytes, unless it's a byte string.

A string has a length measured in characters, but a sequence of any other kind has a length measured in whatever its base unit is. If you're creating a struct with NumPut, the base unit is bytes. VarSetXXX is rather impure, in that it assumes the variable contains a particular data type. Length really should be a property of the value, not the variable, but that might be outweighed by practical considerations.
If you combine the two, you need another parameter.
No, I do not, hence having written ControlChoose(N | String, ...).
to get the nth occurrence of an item?
Control ChooseString never provided this capability, and I had--and have--no intention of adding it.

ControlChoose(string) is more convenient than ControlChooseString(string), but since I'm not sure that I'd ever use it, I don't really care. I will concede that ControlChooseString is clearer and has less risk of being misused.
So '2' has a different meaning without the comma.
No, it has nothing to do with the comma. Coordinates must be specified in a pair. "If coordinates are specified, ClickCount must appear after them."
At least 'x2 y5' could be used.
It could be, but Click(x, y) is better than Click("x" x "y" y) in my opinion.
[Coco] thought they should be regarded as separate parameters, I thought the whole thing should be regarded as one parameter.
Both are supported. Passing separate parameters is the same as passing values separated by spaces/commas.

If you want a fixed order for Click parameters, you can fix it in your mind and be consistent with the code you write. (And avoid reading scripts by other users...)

Btw...
Someone wrote:Also, I believe the AHK v2 approach is to avoid, where possible, using blank parameters.

You made the suggestion MouseClick, options, x, y, which would often have to be written as MouseClick,, x, y (as it already is in v1, except that one can avoid using that command and use Click instead).
User avatar
jeeswg
Posts: 4787
Joined: 19 Dec 2016, 01:58
Location: UK

Re: v2-thoughts Discussion

09 Apr 2017, 20:02

If coordinates are specified, ClickCount must appear after them.

Wow, the comma makes the function even more awkward than I realised.

Click("x" x "y" y)

That's one reason I suggested 3 parameters rather than 1.
Although this isn't too bad in AHK v2 style:
Click("x%x% y%y%")

I don't mind blank parameters personally, apart from the slightly unwieldy AHK v1 InputBox command.

==================================================

[EDIT:]
In the past, I had thought of:
VarSetLen(vOutput, 26) cf. StrLen
v.
VarSetCapacity(vOutput, 26*(A_IsUnicode+1))
VarSetCapacity(vOutput, 26*2)
But because it only really saved me typing a few characters, I didn't post it on my wish list, it's less useful now that AHK v2 will be dropping ANSI support, still, it saves you the *2 and is shorter. I've been meaning to check if VarSetCapacity should leave an extra 2 bytes (or 1 in ANSI/UTF-8) for the null character. Are there common uses for byte 'units' other than 1 and 2?

Btw I'd wondered if any programming languages leave a bit of space, say 1 or 2 or up to 20 characters, at the start of a variable, in case the user wants to prepend a bit of text to the variable without having to move all the data to make room for it.

==================================================

[EDIT:]
Control ChooseString never provided this capability, and I had--and have--no intention of adding it.


Just for the record, I'm fine with that and wasn't advocating its addition.
Last edited by jeeswg on 10 Apr 2017, 20:13, edited 10 times in total.
User avatar
nnnik
Posts: 3068
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: v2-thoughts Discussion

10 Apr 2017, 01:49

jeeswg wrote:Although this isn't too bad in AHK v2 style:
Click("x%x% y%y%")

This is pretty bad actually. First you need to mark entry into a string region and then mark a dynamic region twice. It is both redundant and incredibly annoying to type.
Also I think we should slowly move away from this kind of Syntax and replace it with a better alternative ( e.g. { x:x, y:y } )
Recommends AHK Studio

Return to “AutoHotkey v2 Development”

Who is online

Users browsing this forum: No registered users and 3 guests