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
HotKeyIt
  • Moderators
  • 7439 posts
  • Last active: Jun 22 2016 09:14 PM
  • Joined: 18 Jun 2008
Yes, the above conditions are not met, but I still want to continue running scripts. Thanks.

 

You have to make sure that one of the conditions is met.

 

I use OnMessage for AutoHotkeyMini.dll

OnMessage(0,"Persistent")
Persistent(){
  Return
}

Otherwise I use a Hotkey but you have to place it in the end of script.

~VKFF::Return


Larctic
  • Members
  • 303 posts
  • Last active: May 10 2016 04:56 PM
  • Joined: 21 Jul 2012
Thanks. But that does not really solve the problem.
Not necessary to delete #Persistent.

I found these commands are deleted, how to replace it then?

If between/is/in/contains

Zaelia
  • Members
  • 754 posts
  • Last active: Jan 17 2015 02:38 AM
  • Joined: 31 Oct 2008

Why we need a_space and a_tab ? we can use "`t" and maybe a new "`_" or "`s" for space char, I think will be more mindset of all kind of "`r`n`%...", no ?

 

edit: oops just read http://l.autohotkey....v2-thoughts.htm

 

About mouse and click questions and naming, I think you have to plan how you will manage "touch" for tablet and multitouch screen (WM_TOUCH, WM_GESTURE, api, ie10 ...)  for to create something consistent for the next years.


"You annoy me, therefore I exist."

evilc
  • Members
  • 340 posts
  • Last active: Oct 27 2015 11:07 PM
  • Joined: 17 Nov 2005
I haven't managed to read this whole thread, so apologies if I am covering old ground, but I also would like to use this thread to express my opinons on the direction AHK needs to go.
 
I have been using AHK for many years, but it is when I discovered the AHK GUI that my love of AHK really blossomed. I tried C#, but for me the learning curve was too steep - I was capable of it, but there would be quite a lot of study involved. Once I discovered AHK I found a language that would let me do the stuff I wanted, but not require much knowledge other than of the language itself.
 
One thing that is holding AHK back though has been it's quirky syntax, so the changes I see mentioned on the v2 page are hugely welcomed, but they do not seem to address all of my concerns.
My main gripes with AHK are the way that we are sometimes forced to use globals, can't use arrays or objects with commands, or have commands call functions instead of labels.
 
We need to go the whole hog with this move towards functions with regards to these points, so that we can always encapsulate our data rather than having to pollute the global namespace. Whilst I can understand that there are reasons for not completely replacing all commands with functions, I think we need to eradicate all things which force coders into bad programming practices.
 
So, v-labels and g-labels need to support anything you throw at them.
Gui, add, edit, vmygui.tab[1].myedits[1] goption_changed(true)
 
In general, any command should be able to call a function
SetTimer, my_timer(), 1000
Hotkey, ^c, my_func()
 
With these changes, I think AHK would be a much more credible language. Having a few quirky commands is OK, as long as the rest of the code looks like a normal language. As it stands, too much of my code is dealing with the quirks of AHK, resulting in confusing and unnecessary code.
 
With changes such as these, AHK would be a thing of beauty. There are not many other languages that give you the power and simplicity that AHK does. Some of my AHK projects are applications in their own right - I am continually amazed at what you can do with it, but these niggling little issues are stopping it from realizing it's true potential.
 
Well, thats my thoughts anyway. Sorry to blab on if this topic has already been covered.


Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
I don't see the problem with using global variables with GUIs.

Allowing expressions with 'v' or 'g' is not possible while keeping within my energy budget.

Allowing functions in place of subroutines is something I've long considered; i.e. goption_changed should call the option_changed function.

Arrays and objects can only be used in expressions, and expressions can be used within %% with commands in v2.  Arrays and objects can't be used as output variables, because they aren't variables.



topsoftbe
  • Members
  • 1 posts
  • Last active: Jan 18 2016 12:07 AM
  • Joined: 11 Mar 2013

I am using Autohotkey since a few years for a lot of things but what always bothered me was the strange "old" syntax for variables.

So I hoped that finally version 2 would use strings and variables the way all other languages do:

 

"This is a string" is a string and a Variable is everything else that is not in quotes and is not a label or a function or a command.

 

But now I see that you are repeating the same mistakes as in the old version and are using %variables% again.

 

Is there a reason for that?  

 

Another question: is the dot "." still used for concatenation? I hope so, there was no reason to change that.

 

 

 

 



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

If you don't like the %variable% syntax, don't use it.  There is no need to with v2.

 

Changing the language to be like "all other languages" is not the purpose of v2, and not in the least bit interesting to me.  Anyone is free to take the functionality of AutoHotkey and attach it to some other language, but no one has, so apparently no one cares that much.  Ultimately all it takes is motivation.  If you don't know C++, you can learn, like I did when I started AutoHotkey_L.

 

It is naive to suggest that strings and variables are the same across all other languages.
 
Some people dislike dot for concatenation.  Some people dislike AutoHotkey's auto-concatenation.  Both are here to stay.


evilc
  • Members
  • 340 posts
  • Last active: Oct 27 2015 11:07 PM
  • Joined: 17 Nov 2005

I don't see the problem with using global variables with GUIs.
Allowing expressions with 'v' or 'g' is not possible while keeping within my energy budget.
Allowing functions in place of subroutines is something I've long considered; i.e. goption_changed should call the option_changed function.
Arrays and objects can only be used in expressions, and expressions can be used within %% with commands in v2.  Arrays and objects can't be used as output variables, because they aren't variables.

It's not really a problem per se, it just makes the code more awkward.
If you have 20 rows of gui items with 10 columns each, that's 200 variables (One of my apps, UJR, has ~350 GUI items), and if you want to access something you often have to use temp variables and/or concatenate strings together to arrive at the variable name you need.
If we were allowed to use arrays or objects for GUI items, it would make everything much simpler.



SAPlayer
  • Members
  • 403 posts
  • Last active: Apr 11 2014 04:45 PM
  • Joined: 06 Nov 2012

That's true, I'd like that too (e.g. "Gui, Add, Text, vGuiText[20], abc")



chaz
  • Members
  • 192 posts
  • Last active: Oct 01 2015 02:42 AM
  • Joined: 26 Mar 2013

@evilc: I ran into that problem too, when I found that I had so many global variables (where normally I have none) that I was having to name them gui_preview_chkbox_8, and that is honestly a pain. So being able to specify a function to call instead of a subroutine is something I really welcome.


Find me at the other forum as timeFlies.


Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
If using the associated variables isn't convenient, don't do it. There are other ways to identify and manipulate controls that might be more suitable for scripts with large numbers of controls.

I don't understand how having it call a function would solve your problem. All it saves is writing a 3 line subroutine to wrap the function. Are you (erroneously) assuming that the function would have parameters passed to it beyond what the sub can already access via built-in variables?

evilc
  • Members
  • 340 posts
  • Last active: Oct 27 2015 11:07 PM
  • Joined: 17 Nov 2005

I am not familiar with an alternative to g-labels. Maybe I should do a bit more reading...

 

I can appreciate that a generic g-label plus A_ThisHotkey can be a substitute for a function that is passed something, but when you have user-defined dynamic hotkeys, this just adds another one of those layers of complexity - the code would have to perform a lookup to a table of defined hotkeys to decide what action the user just requested.

 

Don't get me wrong, I applaud and appreciate the work you are doing, it's just that I feel AHK would be a lot more accessible if it threw off more of these strange quirks.

If AHK were more conventional in it's syntax, I would maybe go as far as to say that it was the perfect language to learn as your first programming language - very few other languages allow you to actually do something *useful* with a hello-world length snippet of code. V2 moves closer to that, but IMHO v and g-labels are one thing that causes it to fall short in this regard.

 

On the subject of user-defined dynamic hotkeys, is there any hope of an upgrade for the hotkey gui item? The ability to detect all buttons supported by AHK would be nice ("Special" keys, mouse buttons, joystick buttons). At the moment, I need to use 5 gui items (A modded hotkey box for keyboard keys, a dropdown for mouse buttons, plus ctrl, alt, shift checkboxes) to give the user a reasonable choice of hotkeys to use. Unless of course you know of a way to hack in the functionality to our existing efforts.



Relayer
  • Members
  • 122 posts
  • Last active: Jun 22 2015 09:21 PM
  • Joined: 24 Nov 2008

Here is a good way to avoid all of the different gLabels.  It is neat and structured and puts all of the definitions in one place.  Thanks go to Robert Ryan for this technique in his script "Dirmenu.ahk".  In fact the example below is from his script with some mods for my purposes. -Relayer

 

I used a class but you can just do it by brute force in your script if you want.

class callTable
{
	__New()
	{
	}
	
	add(key, function)
	{
		this[key] := Func(function)
	}
}

Where "key" is either the vVariable defined by the GUI, Add or it is the text/caption for the gui control if vVariable is not specified.  "function" is the name of the service routine.

 

The script then initializes the callTable and creates the gui using the same gLabel, gGuiCall, for each control:

c := New callTable()

c.add("MyList", "UpdateButtons")
c.add("&Add", "Add")
c.add("&Remove", "Remove")
c.add("&Modify", "Modify")
c.add("&Separator", "Separator")
c.add("Move &Up", "MoveUp")
c.add("Move &Down", "MoveDown")
c.add("Sort", "SortIt")
c.add("&OK", "OK")
c.add("&Cancel", "Cancel")
c.add("Re&vert", "LoadListView")
c.add("About", "About")
c.add("Edit Custom Menu", "ShowGUI")
c.add("Edit This Menu", "ShowGUI")
c.add("Add This Folder", "AddThis")

Gui, 4: Add, ListView
    , xm w350 h240 Count15 -Multi NoSortHdr AltSubmit vMyList gGuiCall
    , Name|Path
Gui, 4: Add, Button, x+10 w75 r1 gGuiCall, &Add
Gui, 4: Add, Button, w75 r1 gGuiCall, &Remove
Gui, 4: Add, Button, W75 r1 gGuiCall, &Modify
Gui, 4: Add, Button, w75 r1 gGuiCall, &Separator
Gui, 4: Add, Button, w75 r1 gGuiCall, Move &Up
Gui, 4: Add, Button, w75 r1 gGuiCall, Move &Down
Gui, 4: Add, Button, w75 r1 gGuiCall, Sort
Gui, 4: Add, Button, xm+85 w75 r1 gGuiCall Default, &OK
Gui, 4: Add, Button, x+20 w75 r1 gGuiCall, &Cancel
Gui, 4: Add, Button, x+20 w75 r1 gGuiCall, Re&vert
Gui, 4: Show

Then calls are made using:

GuiCall:
	Call[A_GuiControl].()
return

This also works with menus.  Here the gLabel would be gMenuCall for every menu item.

MenuCall:
	Call[A_ThisMenuItem].()
return


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

I am not familiar with an alternative to g-labels. Maybe I should do a bit more reading...

 

Did I say something about g-labels?  You don't need to use global variables; just call a function.  Actually, in theory, I think you can use a local label (new in v2) and static variables.

 

I can appreciate that a generic g-label plus A_ThisHotkey can be a substitute for a function that is passed something, but when you have user-defined dynamic hotkeys, this just adds another one of those layers of complexity - the code would have to perform a lookup to a table of defined hotkeys to decide what action the user just requested.

 

It doesn't sound very complicated to me.  Having done it before, I'd say associative arrays make it easy.

 

On the subject of user-defined dynamic hotkeys, is there any hope of an upgrade for the hotkey gui item?

 

Only if someone else does it.  Currently we just use a standard Windows hotkey control.
 
V2 moves closer to that, but IMHO v and g-labels are one thing that causes it to fall short in this regard.

 

I don't believe allowing varray[whatever] helps the situation.  I think the whole concept (setting a place for the GUI to "submit" the control's value into) is weird.  But since revising the GUI commands would be a lot of work and I haven't even thought of a better system, I plan to leave it for a post-v2 release.



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

Then calls are made using:

 

Thanks for posting.  However, that calling code won't work in v2.  This should work on v1.1.07+ and v2:

f := Call[A_GuiControl], %f%()

This should work on v2:

%Call[A_GuiControl]%()