Page 2 of 2

Re: Re: v2.0-a079-be5df98 - Loop statements

Posted: 15 Aug 2017, 19:01
by Helgef
I respect your opinion that one is clearer than the other. I misunderstood and though that you where making a claim that the first is faulty (by design).

Cheers ☕

Re: Re: v2.0-a079-be5df98 - Loop statements

Posted: 15 Aug 2017, 19:19
by jeeswg
Hi Helgef. Hey np. :wave:
To avoid a really short post, I thought I'd just mention that I have Wish List 2.0 in the pipeline ...

Re: Re: v2.0-a079-be5df98 - Loop statements

Posted: 16 Aug 2017, 05:17
by just me
Hi jeeswg,

IMO, v2.0-a079-be5df98+ is primarily designed for 'function-style' syntax. Only flow control statements are forced to some kind of 'command-style'. If you want to avoid what you are calling ambiguity, use the 'function-style'

Code: Select all

Cmd( , Arg2)

Re: Re: v2.0-a079-be5df98 - Loop statements

Posted: 16 Aug 2017, 08:36
by derz00
jeeswg wrote:derz00, what you say is true, however, unfortunately I will be looking at other people's code from time to time. It actually makes me hazy sometimes to read code like that, where I can't readily visually distinguish between command name and parameter 1. Plus if no initial comma mode is forced, I can't even then correct/repair the code by adding in commas, unless there was a directive to allow initial commas. I gave it the benefit of the doubt initially, but through experience I now know where I stand.
This much has already been said about this, but I still do not understand the above statements.

Re: Re: v2.0-a079-be5df98 - Loop statements

Posted: 16 Aug 2017, 09:02
by jeeswg
Here are some examples from an AHK v1.0 list of commands with square brackets removed:

Code: Select all

;initial comma:
Control, Cmd, Value, Control, WinTitle, WinText, ExcludeTitle, ExcludeText
ControlClick, Control-or-Pos, WinTitle, WinText, WhichButton, ClickCount, Options, ExcludeTitle, ExcludeText
ControlFocus, Control, WinTitle, WinText, ExcludeTitle, ExcludeText
ControlGet, OutputVar, Cmd, Value, Control, WinTitle, WinText, ExcludeTitle, ExcludeText
ControlGetFocus, OutputVarWinTitle, WinText, ExcludeTitle, ExcludeText
ControlGetPos, X, Y, Width, Height, Control, WinTitle, WinText, ExcludeTitle, ExcludeText
ControlGetText, OutputVar, Control, WinTitle, WinText, ExcludeTitle, ExcludeText
ControlMove, Control, X, Y, Width, Height, WinTitle, WinText, ExcludeTitle, ExcludeText
ControlSend, Control, Keys, WinTitle, WinText, ExcludeTitle, ExcludeText
ControlSendRaw, Control, Keys, WinTitle, WinText, ExcludeTitle, ExcludeText
ControlSetText, Control, NewText, WinTitle, WinText, ExcludeTitle, ExcludeText

;no initial comma:
Control Cmd, Value, Control, WinTitle, WinText, ExcludeTitle, ExcludeText
ControlClick Control-or-Pos, WinTitle, WinText, WhichButton, ClickCount, Options, ExcludeTitle, ExcludeText
ControlFocus Control, WinTitle, WinText, ExcludeTitle, ExcludeText
ControlGet OutputVar, Cmd, Value, Control, WinTitle, WinText, ExcludeTitle, ExcludeText
ControlGetFocus OutputVarWinTitle, WinText, ExcludeTitle, ExcludeText
ControlGetPos X, Y, Width, Height, Control, WinTitle, WinText, ExcludeTitle, ExcludeText
ControlGetText OutputVar, Control, WinTitle, WinText, ExcludeTitle, ExcludeText
ControlMove Control, X, Y, Width, Height, WinTitle, WinText, ExcludeTitle, ExcludeText
ControlSend Control, Keys, WinTitle, WinText, ExcludeTitle, ExcludeText
ControlSendRaw Control, Keys, WinTitle, WinText, ExcludeTitle, ExcludeText
ControlSetText Control, NewText, WinTitle, WinText, ExcludeTitle, ExcludeText
At a glance, I find the first example far more readable, even though I'm quite familiar with all of these command names.

In fact I find the lower example dizzying. One possibility is that I'm automatically scanning right to find the first comma, to confirm that I'm looking at a command, and each time I look at one of the lines I do this ... that is very dizzying. Also the command name and parameter 1 sort of blur into one entity, without the comma, making it harder to read.

What just me said is correct, you could use the function style instead, but I might have to look at or work with someone else's script.

If someone gave me such code, with no initial commas, I'd be tempted to 'correct' it, to add in the initial commas, however, if AHK v2 makes it impossible to do this, then obviously I can't do it.

I was not initially against 'no initial commas' per se, but considered the pros and cons, and gained some experience with them, by going over Coco's AHK v2 functions for AHK v1, which I've amended and appended as AHK v2 has seen new updates. I.e. I maintained his coding style of no initial comma (and indents of 4 spaces instead of a tab).
commands as functions (AHK v2 functions for AHK v1) - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 37&t=29689

Re: Re: v2.0-a079-be5df98 - Loop statements

Posted: 19 Aug 2017, 03:26
by nnnik
Yeah but if you need to read the manual for almost every new line the language is just bad.

Re: Re: v2.0-a079-be5df98 - Loop statements

Posted: 19 Aug 2017, 07:16
by derz00
I'm not sure I understand what you mean. Or am I not allowed to be that ignorant?

Re: Re: v2.0-a079-be5df98 - Loop statements

Posted: 19 Aug 2017, 09:05
by nnnik
I think I posted to the wrong topic

Re: Re: v2.0-a079-be5df98 - Loop statements

Posted: 19 Aug 2017, 09:44
by jeeswg
I think he was referring to this line by Helgef earlier:
Someone how have never programmed should read the manual, you are biased from earlier experiences. Preferences aside, there is no ambiguity.

Re: Re: v2.0-a079-be5df98 - Loop statements

Posted: 24 Aug 2017, 19:08
by jeeswg
FILEAPPEND AN ODD NUMBER OF BYTES

I have been reading up on the FileRead and FileAppend functions. It appears that AHK v2 is adding support for binary variables, and so when you read or append a binary variable, from/to a file, the size is rounded up to the nearest two bytes.

This would potentially limit the usefulness of FileAppend with binary variables, when the data has an odd length in bytes. When would anybody add an arbitrary extra null byte to the end of a file in everyday usage?

A workaround would be to add an option equivalent to m1024 for reading bytes, to specify the number of bytes to write. This would then make the FileAppend function more useful generally, you could write raw data or a string in any encoding, but limit the number of bytes.