Jump to content

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

AutoHotkey v2 Alpha Release


  • Please log in to reply
870 replies to this topic
sinkfaze
  • Moderators
  • 6367 posts
  • Last active: Nov 30 2018 08:50 PM
  • Joined: 18 Mar 2008

It's especially a horrible idea because it would bypass the short-circuit boolean evaluation that can be very important in expressions.


Just how pray tell does this bypass short circuit evaluation?

; current
if !x
  return
else if x between 4 and 10
  return

; proposed
if !x || Between(x,4,10)
  return

There's nothing about converting those traditional if [var]'s to functions that would bypass short-circuit evaluation. In fact, converting them into functions actually allows them to work with short-circuit evaluation. And there's no reason short-circuit evaluation could not be built into an And() or Or() function if such functions were desired.

guest3456
  • Members
  • 1704 posts
  • Last active: Nov 19 2015 11:58 AM
  • Joined: 10 Mar 2011
great job, great work.

some quick comments on your two OPs


PixelSearch and PixelGetColor now use RGB instead of BGR by default. (No option is provided to use BGR.)


not a fan of this. i like the option to use both RGB or BGR and use it regularly

There was some discussion about changing the syntax for var derefs from %var% to $var, $var; or ${var}. Rather than making any radical changes, I've simply removed the requirement for a deref end char.


cool, i like this a lot, even though i don't know if i will use it.

The plan indicates that numerous commands should be replaced with functions. Since I plan for a future version to make commands and functions equivalent (allowing either syntax), they will probably stay as commands for now.


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 use IfWinExist a lot, but i've tried to mentally remember to just do "if WinExist()" instead. the function notation just seems more natural and i feel like i'm relying too much on AHK quirkyness by using IfWinExist and other commands.

So far I've avoided removing auto-concat or changing the auto-concat rules, but that may change, especially if stricter syntax checking is implemented. I know there are some users who oppose the removal of auto-concat, but I think allowing variable derefs (and possibly nested expressions) in quoted strings may make up for that.


On that note - I would like to support variable derefs inside quoted literal strings. There are a number of different possibilities:
[*:35tte6ol]'%var' could contain a variable deref while "%var" is purely literal, as in v1. There's a certain logic to this: doubly-quoted strings are "twice as literal" as singly-quoted strings. [*:35tte6ol]Opposite to the above, "%var" could contain a variable deref while '%var' is purely literal. I think that Perl and Bash scripts use this convention. [*:35tte6ol]A meta-character (such as the deref character itself) could be prepended to the literal string to enable variable derefs. For example, %"the value of %key is %value". [*:35tte6ol]Both types of quote marks could be equivalent, for convenience, and both could allow variable derefs. There could be some way to "escape" all meta-characters in a string, such as r"..." (Python), @"..." (C#) or `"..." (escape char applied to opening quote mark). Additionally, there have been requests to support using the usual escape character as a means to escape double quote marks in literal strings. For example, "this is a `"quote`"". Some editors which support AutoHotkey syntax highlighting act as though this is already valid, but it isn't.


yes! i am strong against auto-concatenation, because it makes script read-ability a mess:

x := "hello" 
y := x "world"     ;// yuck, what?
z := x . "world"   ;// easier to read and understand whats going on

however, if any of these variables in strings is implemented, i wont care so much about auto concat because this feature would solve the problem. i'm not sure which i like best just yet


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.



i like this

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
I would recommend holding off on switching to v2 for any serious scripts, at least until the first non-alpha release. Just keep in mind the changes and avoid literal assignments, traditional IFs and other legacy commands. For a more exhaustive list of changes, see the github commit history. I do not plan to add any warning messages to ease the transition, but I do plan to write a conversion script.

I would like to see the functions get more tied to the object syntax,

I'd like to defer this and other ideas which won't break compatibility until after the first non-alpha release. In this case I think it could even be safely added to v1.1.

I also suggest getting rid of default listviews and treeviews (there are possibly other examples).

I can see your point, but I think that the current functions are convenient, especially for scripts that only have one ListView. Those might be the most common.

it is very attractive that old version (your unicode ahkL) allow to use my own languages characters as variable (türkish)

Thank you for your feedback. I may have undervalued that capability. I think most of the languages I've used heavily have the same restrictions as v2-a001, but I see Java and JavaScript aren't as restrictive. Non-ASCII characters are prone to encoding problems, but I suppose that the users who benefit most from non-ASCII variable names are the ones who will have to deal with that. I'll relax the rules to allow non-ASCII characters, unless someone comes up with a compelling reason not to.

But the debug feather doesn't work now?

I think something was lost in translation. Would you care to restate your question?

Any plans on removing them? (especially #CommentFlag and #EscapeChar)
The ability to change syntax features in a script is a pain in the backside for IDEs to handle.

If there's no demand to keep them, I will remove them at some point. For now, #DerefChar is mainly kept to allow experimentation with the deref syntax.

Remove [Progress and SplashImage], please. You can already do that using GUIs.

I'd like to know if anyone values these commands. I suppose the easiest way to find out is to remove them, and wait for the complaints. ;)

Or instead introduce a function: Between(Value, LowerBound, UpperBound)

I prefer the idea of converting it to two checks: >= and <=.

I would replace it with a more general Eval() function.

That isn't going to happen for v2. It also wouldn't be as convenient for simply dereferencing variables. Maybe format() and format_v() will be sufficient substitutes for Transform Deref. If we provide some means to retrieve local or global variables in an array (which I believe has been requested in one form or another), the array can be passed to format_v. Similarly, you can write an object which wraps EnvGet, and pass that to format_v.

What about using (< and >) or similar?

I kind of like your original idea, (| and |). I think that either would be okay; since both "<" and "|" are ordinarily binary operators, there's no ambiguity with expressions.

Auto-concat is one of my favourite features of AHK,

It seems to be a love/hate kind of feature. The only problems I have with the current concat operator are the white-space requirement and the ambiguity with object syntax.

Why do you need octal numbers? I understand the need for binary literals

I don't on either account, which is why I ask. If binary is supported but octal is not, the number-parsing functions then needs to check IsHex (to avoid treating 0777 as octal) and IsBin every time. 0o777 was just an idea from using SpeedCrunch, mentioned for consistency with 0xFFF and 0b111.

Oh, and [the behaviour of numeric strings as keys in objects] is counterintuitive:

Yes, I fell into that trap myself, shortly after setting it up. ;) My thinking was that numeric strings allow one to bypass the array-like behaviour of Insert and Remove, but maybe that's just another case for implementing a dedicated array type (and removing the array-like behaviour from objects).

How does StrSub for StringSubstitute sound?

Are you talking about StringReplace? The fact that I even have to ask is a good reason not to use that name. Having StrSub and SubStr would be far too confusing.

I can't think of a consistant way for a single deref character to work.

I'm not sure what you mean. I can guess you mean that an ending character or something like {} must be supported, to which I'd agree. However, it's only necessary when the next character after the deref is valid in a variable name. For expressions, it only applies to double-derefs and dynamic function calls, like %prefix%_handler(). I think that %(expression) is the most intuitive and flexible solution.

There have to be restrictions on the deref characters such as: it can't be a valid variable symbol, can't be an escape character, and can't be a white space.

There are restrictions. Some are imposed specifically by #DerefChar and some are present due to the way derefs and expressions are parsed. For instance, it can't be any character which forms an expression operator or any character which is valid in a variable name. %, $, @, #, ' and \ are probably the only ones that can be used globally at the moment.

One more note, I think PixelGetColor could be replaced with a function all together.

As I noted, I won't be replacing any commands with functions at this stage. Eventually they will be interchangeable.

It appears that Windows ME and earlier are no longer supported.

Microsoft Visual C++ 2010 officially does not support targetting any platform older than Windows XP SP2. However, AutoHotkey_L is patched to work on Windows 2000 and Windows XP SP0/SP1. I've been told that Windows 2000 requires certain updates which are only available for English versions of the OS.

If not, when can we expect [an updated help file]?

Expect an updated help file by the first non-alpha release. Nothing is final yet, so keeping the documentation up to date would be a burden - unless someone else volunteers.

The following changes/plans are not good:

You are wrong. :)

Okay, so it's a matter of perspective. You haven't explained yours. In particular, I want to know: Are you unhappy that #, @ and $ have been outlawed in variable names, or just non-ASCII characters? Are you unhappy with = becoming exclusively a comparison, or with `= as the current form of literal assignment? Keeping = as literal assignment goes against the very purpose of v2.

Wouldn't it be a little more convenient to just convert them to functions?

I personally think they don't have enough value as functions to be built-in. However, I could remove them and let you convert them to functions. ;)

I think functions like [And() and Or()] would save space and improve readability in code, IMO.
...
And there's no reason short-circuit evaluation could not be built into an And() or Or() function if such functions were desired.

I don't see how they would save space, and I disagree about readability. To support short-circuit evaluation, they would need to be internally handled as operators, which would be counter-intuitive and not worth the added complexity.

And since you had pondered using the same syntax style that is used in the RegExReplace function for dereferencing (${var})

Actually, I wasn't pondering that. I merely mentioned that it was discussed. Using the same syntax as RegExReplace could be misleading, and inconvenient if var derefs are supported in strings. More to the point, %(var) seems like a better choice to me.

would it be possible to make the blocks a special case deref for supporting [UPPER/lower/Title case conversions] conversions?

I don't believe it would be worth the added complexity. With my earlier proposals, this would be possible:
MsgBox [color=darkred]%StrLower(verb)[/color], [color=darkred]%StrUpper(subject)[/color]! ; hello, WORLD!

I agree with [...] removing (Transform Deref), and instead replacing its functionality with variable derefs inside quoted literal strings.

I think you're misunderstanding the purpose of Transform Deref. This can't be done with variable substitution in literal strings:
Transform value, Deref, % Chr(37) . ComputeVariableName()
To further clarify, the following would be exactly equivalent at run-time:
x := "y is %y"
x := "y is " . y

i.e. y := "red" in "a,b,c,d" would compare to the single complete string "a,b,c,d" and not split it.

Are you suggesting that it should be equivalent to InStr("a,b,c,d", "red")? That might be convenient.

We have objects and arrays now, there's no need to introduce additional syntax to handle what they are designed to offer.

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.

BUT when the *deref NumGet equivalent is found in an expression, {NumGet(deref,0,"chr") I think} translate it behind the scenes (i.e. unknown to the user) to use the faster method that *deref uses.

My opinion is that it wouldn't be worth the added complexity. The performance difference isn't very significant, and the deref operator is probably rarely used to begin with.

i like the option to use both RGB or BGR and use it regularly

I'll consider adding a "BGR" option, but is there some reason you can't write a simple conversion function to be used like PixelSearch, x, y, ..., % RGB(bgr_value)? The other commands which accept colour values don't support a BGR option.

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

i like the option to use both RGB or BGR and use it regularly

I'll consider adding a "BGR" option, but is there some reason you can't write a simple conversion function to be used like PixelSearch, x, y, ..., % RGB(bgr_value)? The other commands which accept colour values don't support a BGR option.


yeah that will have to be the solution. currently i'm using this when the occasion arises:

;// http://www.autohotkey.com/forum/post-200921.html#200921

FlipBlueAndRed(c) ; takes RGB or BGR and swaps the R and B
{
   return (c&255)<<16 | (c&65280) | (c>>16)
}


some other thoughts:

1. any consideration as to requiring the same deref char for the DEFINITION of variables? sort of like PHP (which uses $):

%var := "hello"
%var2 := "%var world"

2. when learning AHK, i always found the ahk_id, ahk_class, etc syntax very confusing. especially the optional space inbetween the ahk_id and the variable. i wonder if anyone has any ideas on how to improve that.

jaco0646
  • Moderators
  • 3165 posts
  • Last active: Apr 01 2014 01:46 AM
  • Joined: 07 Oct 2006
I think I agree with everything fincs wrote. Here's my own list of ideas as well.

Remove the following:[*:2bl5tbm0]#HotkeyInterval
Set it at 1000 and let #MaxHotkeysPerInterval do the work. There isn't a need to manipulate the same thing from both ends.
[*:2bl5tbm0]SetBatchLines
Set it at -1. It's been the de facto setting for years. Plus, we still have a bunch of commands for more fine-grained control: SetControlDelay, SetKeyDelay, SetMouseDelay, SetWinDelay, and probably more that I'm not thinking of.
[*:2bl5tbm0]#CommentFlag, #DerefChar and #EscapeChar
Eliminate them all. They're rarely used and more confusion than they're worth.
[*:2bl5tbm0]Transform
Remove the command entirely. This may be the most "legacy" feature in AHK, and what an uncohesive mess to begin with. Anything that is missed can be added in some other form in the future (e.g. Eval()).
[*:2bl5tbm0]Progress / SplashImage
These should be created via GUI, as fincs noted.
Possibly remove the following. Are any of these used enough to justify their existence?[*:2bl5tbm0]#MaxThreads
[*:2bl5tbm0]#WinActivateForce
[*:2bl5tbm0]#HotkeyModifierTimeOut
[*:2bl5tbm0]#UseHook
[*:2bl5tbm0]SetStoreCapslockMode
Other random ideas:[*:2bl5tbm0]#SingleInstance
Should this be the default?
[*:2bl5tbm0]SetTimer
Should this make scripts automatically #Persistent?
[*:2bl5tbm0]ListLines, Off
Should this be the default? Chris mentions that it increases performance.
[*:2bl5tbm0]GuiClose
Should ExitApp be the default? It's definitely the most common behavior for the GUIs I've written.
Other changes that v2 should make:[*:2bl5tbm0]Dynamic variables in functions should not reference globals, to eliminate this "common source of confusion."
[*:2bl5tbm0]The two Tab controls should be consolidated, by somehow merging their different behaviors.
Thoughts on Lexikos' specific questions:[*:2bl5tbm0]The string literal "0" should not be considered true.
[*:2bl5tbm0]Loop changes
Would this allow the use of OTB style blocks with all loops? That sounds nice.
[*:2bl5tbm0]WinMenuSelectItem := MenuSelectItem
[*:2bl5tbm0]Continuation sections
Possibly escaped parentheses? `(...`)
[*:2bl5tbm0]File extension
How about .ahk2? I don't think three-character extensions are required.
[*:2bl5tbm0]Octal / Binary
No to both.
[*:2bl5tbm0]x:=
No.
[*:2bl5tbm0]SubStr() offset change
Yes.
[*:2bl5tbm0]Deref end character.
Please leave it as is. I wish this can of worms had not been opened.
[*:2bl5tbm0]Blanks in math operations should be consistently treated as zeros.
And finally, one bigger question.

Is the elimination of command syntax a goal of v2? I think for consistency the goal should be either that we have only functions with no corresponding commands, or else a corresponding command for every function. The current mix-and-match is messy and a little confusing.

And just to see how many people howl, how about eliminating GoTo?

sinkfaze
  • Moderators
  • 6367 posts
  • Last active: Nov 30 2018 08:50 PM
  • Joined: 18 Mar 2008

Wouldn't it be a little more convenient to just convert them to functions?

I personally think they don't have enough value as functions to be built-in.


If they're not valuable enough to be built-in functions I would question their value as operators, which to me is far more complex to understand. Full disclosure: I use In(), Between() and Contains() functions in my production scripts very frequently, particularly in my file loops.

I don't see how they would save space...


After looking at it saving space is negligible, but as far as readability I think they're much cleaner:

if   !x || (x > 3 && x < 16)

if   Or(!x, And(x < 3, x > 16))

Probably biased because I work with Excel too much.

I don't believe it would be worth the added complexity. With my earlier proposals, this would be possible:

MsgBox %StrLower(verb), %StrUpper(subject)! ; hello, WORLD!


I worry that the function names, even as abbreviated as they are, just stretch the code out to the point of nuisance. Possibly a compromise?

MsgBox %[color=red]L[/color](verb), %[color=red]U[/color](subject)! ; hello, WORLD!


flak
  • Members
  • 283 posts
  • Last active: Jan 01 2012 06:20 PM
  • Joined: 02 Oct 2009

2. when learning AHK, i always found the ahk_id, ahk_class, etc syntax very confusing. especially the optional space inbetween the ahk_id and the variable. i wonder if anyone has any ideas on how to improve that.

Maybe something like
WinExist({ahk_class: "class", wintitle: "title"})


Learning one
  • Members
  • 1483 posts
  • Last active: Jan 02 2016 02:30 PM
  • Joined: 04 Apr 2009
@Lexikos: I'll try to explain it a little bit better;
[*:1hvelx4w]I'm very unhapy with non-ASCII characters being outlawed in variable names. My alphabet has some non-ASCII characters, and the same case is with many other users. It's a bad feeling when you can't use all characters in your alphabeth. Imagine that someone restricted you like this: "Lexikos, you can use all characters in your alphabet, except a,b,c,d - they are outlawed." Bad feeling, isn't it? That's how we feel. So please allow us to use non-ASCII characters. Concerning #,@ and $, it would be nice if you could make them legal, like in AHK_L. Make legal at least # - I like to use it in variable names. [*:1hvelx4w]I think that X `= Y as the current form of literal assignment should be removed. Don't have any strong arguments, but - I simply don't like it, looks strange. [*:1hvelx4w]Please keep auto-concat. Although it seems to be a love/hate kind of feature, it seems there are much more people who love it, than hate it. I like it very much.

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

any consideration as to requiring the same deref char for the DEFINITION of variables?

My gut reaction is absolutely not. My next reaction is that it cannot be done, since %var := 1 already has an important function: it assigns to the variable whose name is stored in var.

SetBatchLines
Set it at -1. It's been the de facto setting for years.

That's news to me. The current default prevents scripts from hogging the CPU, particularly if it's not interacting with any controls or windows, or the keyboard or mouse. However, it's probably not a big problem to begin with, and scripts which are prone to do that can simply Sleep occasionally. Changing the default to -1 would allow hotkey and timer subroutines to completely more quickly, which might be better in the long run. I suppose that the sooner I make the change, the sooner any problems which it might cause can be found.

Transform
Remove the command entirely.

I plan to. Currently only Transform HTML and Transform Deref remain. As I reasoned earlier, Transform Deref probably isn't necessary anymore. Transform HTML can be scripted, if anyone needs it.

Anything that is missed can be added in some other form in the future (e.g. Eval()).

As I mentioned, I think that Eval() would be inconvenient as an alternative to Transform Deref.

Possibly remove the following. Are any of these used enough to justify their existence?

I've seen a couple cases where #MaxThreads has been necessary to increase the limit from 10. Increasing the thread limit to the current absolute maximum supported by #MaxThreads would increase the memory usage of all scripts by about 45KB on 32-bit builds and 55KB on 64-bit builds. (Currently 184 or 224 bytes per potential thread.)

I've seen some cases where #WinActivateForce is necessary to prevent the taskbar buttons from flashing. Are you suggesting that this functionality be removed, or that the forcible method should be used by default?

I always use #UseHook, since I tend to run into odd and annoying behaviour with registered hotkeys. However, that doesn't mean I'm okay with abolishing registered hotkeys.

I didn't even know #HotkeyModifierTimeout existed. According to the documentation, this directive need not be used if the keyboard hook is installed. Therefore, it's of no use to me.

I've encountered problems caused by Send's automatic toggling of CapsLock, so I can see that SetStoreCapslockMode might be needed in some cases. However, in my case it would've solved one problem only to create another (keys in the wrong case). Perhaps it can be removed. Chris seemed to think it should be kept, judging by the v2 document.

SetTimer
Should this make scripts automatically #Persistent?

Perhaps. Otherwise the auto-execute section needs to continue running for as long as the timer is enabled. However, I'm against this if it means that any reference to SetTimer makes the script persistent. Related: see the link below.

GuiClose
Should ExitApp be the default? It's definitely the most common behavior for the GUIs I've written.

I think not. However, it might be feasible to implement more complex logic in place of the current on/off "persistence" setting. That is, if you haven't used #Persistent and AutoHotkey determines there's no way any more subroutines can launch (no visible Gui, message monitors, active timers, hotkeys, custom tray menu items, etc.), the program exits. See GUI without persistence (my comments are on the second page).

#SingleInstance
Should this be the default?

I think that the current default, which is based on whether the script is persistent, is the most suitable default. However, if the more complex "script persistence" logic I mentioned above is implemented, maybe #SingleInstance will need to be the default.

Dynamic variables in functions should not reference globals, to eliminate this "common source of confusion."

What if globals have been declared or the function is assume-global? To support global declarations, a list of such declarations would need to be stored for each function. That leads me to something else I've been considering:

Currently variable declarations and derefs are parsed at an earlier stage than the remainder of expressions. This duplicates some logic and code, and makes a few things (i.e. potential new features) more difficult, so I'd like to change it. However, it would require each function to keep a list of "global" declarations. Additionally, it would cause variable declarations to apply to the entire function, not just the lines below the declaration. I haven't decided whether that's good or bad.

The two Tab controls should be consolidated, by somehow merging their different behaviors.

The help file reads: "The original Tab control is retained for backward compatibility because Tab2 puts its tab control after its contained controls in the tab-key navigation order. New scripts should use Tab2 whenever possible." Thus, I suppose that "Tab2" should become the new "Tab".

Loop changes
Would this allow the use of OTB style blocks with all loops?

That could probably be done, but I don't see how it's related to the changes I've suggested. The current behaviour means there's no ambiguity; i.e. for a registry key name or filename ending in "{", or (more likely) "{" as a parsing delimiter. (I think the only exception is that Loop %filename% { is OTB since it's not known until runtime that filename isn't a number.)

Deref end character.
Please leave it as is.

As it is in which version? If you mean that a deref end char should always be required, I have to disagree.

Blanks in math operations should be consistently treated as zeros.

I disagree, for many of the reasons Laszlo mentioned when that discussion took place.

Is the elimination of command syntax a goal of v2?

No.

I think for consistency the goal should be either that we have only functions with no corresponding commands, or else a corresponding command for every function.

See the third paragraph in my second post.

If they're not valuable enough to be built-in functions I would question their value as operators, which to me is far more complex to understand.

My meaning was that they are of less value as functions because they are less readable.

as far as readability I think they're much cleaner

You're comparing apples to oranges.
if !x or x < 3 and x > 16
Maybe you don't find that any more readable, in which case, yes, you work with Excel far too much.

I worry that the function names, even as abbreviated as they are, just stretch the code out to the point of nuisance. Possibly a compromise?

That's rediculous. I won't stop you from defining your own L() and U(), but I won't make them built-in.

I'm very unhapy with non-ASCII characters being outlawed.

That's all I needed to know. I'd already made the decision to allow non-ASCII characters (again).

Concerning #,@ and $, it would be nice if you could make them legal, like in AHK_L.

I disagree. I cringe every time I see one of those used in a variable name. Furthermore, I'd like to reserve them for possible future use as operators.

I think that X `= Y as the current form of literal assignment should be removed.

I think that literal assignment in any form should be removed.

Although it seems to bee a love/hate kind of feature, it seems there are much more people who love it, than hate it.

What are you basing that on? A gut feeling? Do you have any comments about my thought that "allowing variable derefs (and possibly nested expressions) in quoted strings may make up for" the removal of auto-concat?

fragman
  • Members
  • 1591 posts
  • Last active: Nov 12 2012 08:51 PM
  • Joined: 13 Oct 2009
Two more things:

I would definitely keep auto concat. I also like to use it very much.

I think I'm currently using HTML Transform in one or two places, but I agree that it could be moved into a script. How about supplying the removed commands/functions together with the executable, such as SplashImage, Progress, etc...?

tank
  • Administrators
  • 4345 posts
  • AutoHotkey Foundation
  • Last active: May 02 2019 09:16 PM
  • Joined: 21 Dec 2007

If a future version will make it possible to call a command using function syntax, I think it would be best to rename the String commands (now rather than in that future version). For instance, StringUpper and StringReplace are inconsistent with StrLen and SubStr. I am considering simply dropping the "ing". Any objections or suggestions?

Do it

Chris indicated that removing Progress and SplashImage "would be quite a big reduction in code size." However, it actually appears to reduce the uncompressed exe size by only 5KB. Other reasons Chris gave to consider removing them were that their syntax is a bit clumsy and maintaining them might be a burden due to "changes in Vista and future OSes." If someone is keen to write a replacement for these, I'd consider removing them; but it doesn't seem worth much trouble.



I use both regularly we at least need a repacement if removed

At least two notable forum members have expressed a desire to remove literal assignment (var `= value) entirely. I like this idea. Do you?

Oh god If there were ever anything i felt passionate about. All assignments should be expression mode. yes this is rigid but it does solve confusion

If a future version will make it possible to call a command using function syntax, I think it would be best to rename the String commands (now rather than in that future version). For instance, StringUpper and StringReplace are inconsistent with StrLen and SubStr. I am considering simply dropping the "ing". Any objections or suggestions?

yes

Type(Value) returns one of the following strings: String, Integer, Float, Object, FileObject, ComObject.

Thanks

Either way, "URI" or "URL" seems unnecessary.

aggree

and omitting all parameters can turn it off - like the ToolTip command.

yes

Chris suggested that the Loop command (and sub-commands) might benefit from parameter reordering and disambiguation. I'm not sure how the parameters should be reordered, but I think disambiguation would require two new sub-commands: Loop File and Loop Reg. Alternatively, I've considered Loop, LoopFile, LoopParse, LoopRead and LoopReg.

Why i wonder should these not be like winset and winget. and it keep a command parameter

If there is demand, I might change it to ".ah2" as suggested in the plan.

not doing so will become a reasl source of confusion i think

Should x:= with no expression be tolerated? Currently it is (as in v1), but if it is combined with another expression (such as y:=1, x:=), it is an error (it causes stack underflow).


since there are numerous syntax changes and this is just good practice (even if i have committed this crime in numerous scripts)Please do it is my feeling

Should SubStr(str, -1)

change it this has always driven me nuts

Escaping a quote `" is a great idea.

yep
Never lose.
WIN or LEARN.

hughman
  • Members
  • 192 posts
  • Last active: Feb 14 2016 06:59 AM
  • Joined: 11 Feb 2007

Characters made illegal in variable names: non-ASCII characters, #, @ and $.


Oh, no, it's not a good idea. Many old scripts or libaray functions contain variable named starting from $. I also like to name globle variable with $ as prefix.

Multi-statement comma now returns the result of its rightmost sub-statement instead of its leftmost sub-statement.

Then return a:=1, b:=2 will return 2, not 1?

fragman
  • Members
  • 1591 posts
  • Last active: Nov 12 2012 08:51 PM
  • Joined: 13 Oct 2009

Multi-statement comma now returns the result of its rightmost sub-statement instead of its leftmost sub-statement.

Then return a:=1, b:=2 will return 2, not 1?


Actually I don't really see a point in supporting such syntax. Where is it of any use?

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

any consideration as to requiring the same deref char for the DEFINITION of variables?

My gut reaction is absolutely not. My next reaction is that it cannot be done, since %var := 1 already has an important function: it assigns to the variable whose name is stored in var.


yeah, hadn't thought of that. then this might be confusing for people migrating from other languages. because of that, i agree with jaco and will likely not use the one char to deref a var, i will continue using the default with the ending char as well. but this will still be great:

var := '%hellovar% world'

i also like ".ahk2" extension, but know nothing about the 3 char standard or not

fincs
  • Moderators
  • 1662 posts
  • Last active:
  • Joined: 05 May 2007
I've found some problems with derefs:
#DerefChar %;

; This is not caught at all:
SetWorkingDir, %A_WorkingDir%

; This is caught at runtime instead of at load-time:
foo := "bar"
bar := "Hello"
baz := %foo% ; invalid (The variable name contains an invalid character)