Jump to content

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

Permit duplicate Hotkeys, Labels, Hotstrings, etc.


  • Please log in to reply
30 replies to this topic
RaptorX
  • Members
  • 751 posts
  • Last active: Feb 19 2015 02:47 AM
  • Joined: 19 Feb 2010
onclipboardchange:
msgbox % clipboard := regexreplace(clipboard, "\w+", "123456789")
return

onclipboardchange:
msgbox % clipboard := Regexreplace(clipboard, "s", "S") ; <---- this obviously will never run
return

onclipboardchange:
if clipboard contains s
    msgbox, the clipboard contains an s ; <---- this line will not be run as well
return

In the above code one of the labels is messing with the other two.
Granted that this is just a silly example but what if something similar or God forbids more complicated and more difficult to spot (like most programming bugs are).

The problem here is that it will make debugging a pain in the ass since first you will have to know which files contain the duplicate labels.

Again, doing everything silently might cause more problems that we already have, I suggest making it a warning instead and showing which files have the label, but still run the code.

Raccoon
  • Members
  • 178 posts
  • Last active: Oct 06 2014 05:58 PM
  • Joined: 02 Jan 2008
My suggestion implies that all 3 instances SHOULD run, in sequence.
Posted Image

Need help right away? Get live support on IRC.
Already have an IRC client installed? /join #ahk

RaptorX
  • Members
  • 751 posts
  • Last active: Feb 19 2015 02:47 AM
  • Joined: 19 Feb 2010
thats the reason the second onclipboardchange will do nothing.
the regex will try to find any "s" and replace it but guess what? the previous call to onclipboardchange converted the clipboard text to numbers.

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

Lexikos: I think we're pretty much on the same page here.

Far from it.

I'm not entirely sure what points you were driving at with different #IF-scopes. But I think it's obvious that only scope-relevant Hotkeys and Labels would fire, as usual.

My point was that multiple different scopes may be relevant. Many existing scripts rely on one taking precedence over all of the others, even if it's not necessarily the only relevant one. This behaviour is easiest to understand and deal with, but is inconsistent with what you're proposing.

I challenge that sequentially triggering duplicate hotkeys and labels is valid.

I think I didn't emphasize enough my earlier point,

It would add arguably little benefit at the cost of more complication.

I see no feasible way to implement it without sacrificing performance and/or bloating the code.

Again, doing everything silently might cause more problems that we already have, I suggest making it a warning instead and showing which files have the label, but still run the code.

I'm against adding any such "warnings" as they're rather disruptive. I also think it sends a mixed message, like "we'll go out of our way to let you do this but you really shouldn't do it."

A). Procedure used should produce results identical to if both instances were running in separate processes.

Impossible. Two script threads cannot execute simultaneously within the one script process.

B). Procedure used could allow two instances to piggy-back eachother for a collaborative effort.

What benefit does this provide over simply merging the subroutines or leaving them in separate scripts? Aside from OnClipboardChange (which I personally think should've never been implemented as a label), I can only see allowing duplicate labels as a maintenance/debugging nightmare in addition to being counter-intuitive.

1. Before OnClipboardChange A is called, the clipboard is saved to virtual clipboard by AutoHotkeys internal backup system.

What gave you that idea?

Clipboard is a built-in variable that reflects the current contents of the Windows clipboard if those contents can be expressed as text.

In the above code one of the labels is messing with the other two.

If the two (sub)scripts have conflicting functionality, it doesn't make sense to try to use both at once. Whether you use them in different scripts, merge them into one label or (hypothetically) use duplicate labels in one script isn't relevant.

Tuncay
  • Members
  • 1945 posts
  • Last active: Feb 08 2015 03:49 PM
  • Joined: 07 Nov 2006

1. Before OnClipboardChange A is called, the clipboard is saved to virtual clipboard by AutoHotkeys internal backup system.

What gave you that idea?

I should be clearer by what I write. This was an idea how different OnClipboardChange functions could be implemented.

No signature.


RaptorX
  • Members
  • 751 posts
  • Last active: Feb 19 2015 02:47 AM
  • Joined: 19 Feb 2010

Again, doing everything silently might cause more problems that we already have, I suggest making it a warning instead and showing which files have the label, but still run the code.

I'm against adding any such "warnings" as they're rather disruptive. I also think it sends a mixed message, like "we'll go out of our way to let you do this but you really shouldn't do it."

Well, the current ahk code has the same disruptive behavior. It actually shows the warning message *and* stops the script instead. I am just saying it would be better if I get a message saying:

Warning
ahk found duplicate label "MyLabel" on files:
a.ahk:
Line#
053: some context code
---->050: MyLabel
051: some more code
052: some more code

b.ahk
Line#
199: some context code
----> 200: MyLabel
201: some more code
202: some more code


but the script ran anyways, that way if theres is any undesired results then you know where to look at. I say "if" because I think most code would run fine when run sequentially if the duplicated labels dont change any shared resource.

In the above code one of the labels is messing with the other two.

If the two (sub)scripts have conflicting functionality, it doesn't make sense to try to use both at once. Whether you use them in different scripts, merge them into one label or (hypothetically) use duplicate labels in one script isn't relevant.

Thats exactly my point. But if they dont have conflicts then running them sequentially wouldnt cause any issues, and the concept of merging or running labels sequentially is without doubt a good idea.

The problem is ahk cant and shouldnt determine if duplicate labels are conflicting but it can warn you with as much info as possible so in case there are undesired results you dont have to crack your head figuring out which label is the problem and which include file is the one that contains that label.

So, in all I do think that the current ahk method is annoying not only for duplicate labels but when you pass too many/too few parameters to a function or when a byref variable is empty since those not only warn you but they also stop the execution of the script, when some times the script can run perfectly fine with those "errors".

So again, the warning message should stay, the stopping the script part should be removed.

If is too many parameters to a function that last parameter should be ignored, if is an empty byref, then it should be made blank and if it is a duplicated label then they should be run in sequence. Thats my opinion.

--EDIT

it seems to be that empty byref variable messages give you the warning but exits the current thread, which is almost what I would say should be the global behavior because i get the information but if i dont get any undesired results then Im good to go. In case there is a problem i was already warned and i know where to look for the error.

some annoying oranges:

MyLabel:
msgbox 1
return

MyLabel:
msgbox 2
return
; this would run completely fine if ran sequentially

returns:

---------------------------
Sm1zZ4nQ.ahk
---------------------------
Error at line 24.

Line Text: MyLabel
Error: Duplicate label.

The program will exit.
---------------------------
OK
---------------------------


myfunction(var)
return

myfunction(){
return 0
}
; this should be ignored

instead we get:

---------------------------
KMLCvZdV.ahk
---------------------------
Error: Too many parameters passed to function.

Specifically: myfunction(var)

Line#
---> 020: myfunction(var)
021: Return
023: {
024: Return,0
025: }
027: ExitApp
029: Return

The program will exit.
---------------------------
OK
---------------------------


msgbox % %var%
; this var should be made blank instead of exiting the current thread

instead we get this and exit the current thread:

---------------------------
P2rnnQ3F.ahk
---------------------------
Error: This dynamic variable is blank. If this variable was not intended to be dynamic, remove the % symbols from it.

Specifically: %var%

Line#
004: SendMode,Input
005: SetBatchLines,-1
007: sec := 1000
008: min := sec * 60
009: hour := min * 60
---> 020: MsgBox,%var%
022: ExitApp
024: Return
024: ExitApp
---------------------------
OK
---------------------------



Tuncay
  • Members
  • 1945 posts
  • Last active: Feb 08 2015 03:49 PM
  • Joined: 07 Nov 2006

So again, the warning message should stay, the stopping the script part should be removed.

Then we have the html web someday. If ahk would tolerate such a thing, then it leads to (most of ahk users arent programmers i think) bad style. "Say this day I do not want correct this problem, I do it someday, because it works now." Others share the code and say it has the warning, but you can ignore it. Detailed warning messages are ok, but do not encourage bad style.

No signature.


RaptorX
  • Members
  • 751 posts
  • Last active: Feb 19 2015 02:47 AM
  • Joined: 19 Feb 2010
Tuncay

I perfectly understand your point, but we are talking about duplicate labels, which will allow #include files that contain same label/hotkey names as the script that is making the #include calls.

The others are just examples of the behavior that i was describing and are mainly my opinion.

ex.
last few days I have been working on a wrapper for libcurl and there is that one annoying function that allows infinite amount of parameters.

It does that with the help of the va_list typedef and the va_start/end/arg macros, so you can over load a function and still use the macro to check how many parameters they were and stuff.

I was trying to imitate the behavior but guess what? i got the error message as soon as i put one more parameter there, and there is no way around it, which is senseless.

I do believe we dont need to encourage bad style but overloading functions and running duplicate labels sequentially have nothing to do with bad styles.

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

Well, the current ahk code has the same disruptive behavior. It actually shows the warning message *and* stops the script instead.

I consider that a fatal error rather than a warning. Do you want to have to click through a bunch of warnings every time you launch a script designed that way? If it needs to bring up a warning message, it's probably a bad idea to allow it in the first place.

I am just saying it would be better if I get a message ... but the script ran anyways

Well, that's your point of view. I prefer it the way it is.

... the concept of merging or running labels sequentially is without doubt a good idea.

It should be fairly clear by now that I doubt it is a good idea.

The problem is ahk cant and shouldnt determine if duplicate labels are conflicting

AutoHotkey shows an error message specifically because they are conflicting.

So, in all I do think that the current ahk method is annoying not only for duplicate labels but when you pass too many/too few parameters to a function or when a byref variable is empty since those not only warn you but they also stop the execution of the script, when some times the script can run perfectly fine with those "errors".

I wouldn't want it any other way. Generally all of those are errors on the script author's part. Some of these errors must terminate the process since AutoHotkey isn't designed to work under those circumstances. Aside from that, if the function isn't designed to accept that number of parameters, passing that number of parameters is necessarily an error. Continuing execution of the script when there is known to be an error would be unwise, especially considering some of the things AutoHotkey can do. ByRef parameters are validated under a similar principle, though I agree it would sometimes be useful to be able to pass either a variable reference or a value.

If is too many parameters to a function that last parameter should be ignored,

In that case, what was the point of passing the last parameter at all? It's actually allowed for dynamic function calls since the author can't necessarily know in advance how many parameters will be needed and there's currently no way to pass a variable number of parameters.

it seems to be that empty byref variable messages give you the warning but exits the current thread, which is almost what I would say should be the global behavior because i get the information but if i dont get any undesired results then Im good to go.

Run-time errors such as that exist only because they can't be (or at least aren't) detected at load-time. I personally prefer to be notified of errors in the script before it runs and potentially does stupid things.

msgbox % %var%
; this var should be made blank instead of exiting the current thread

How would you then know there is an error in your code? (An error it almost certainly would be.)

I was trying to imitate the behavior but guess what? i got the error message as soon as i put one more parameter there, and there is no way around it, which is senseless.

There's no way to access the excess parameters, so passing them is senseless.

... and running duplicate labels sequentially have nothing to do with bad styles.

I disagree.

Raccoon
  • Members
  • 178 posts
  • Last active: Oct 06 2014 05:58 PM
  • Joined: 02 Jan 2008
I guess my total viewpoint boils down to this basic thought...

If *I* am able to perform the following interpretation:

; Before
~LButton:: Enable_Window_Under_Cursor()
~LButton:: Show_Custom_Cursor("Click", 250)

; After
~LButton::
  Enable_Window_Under_Cursor()
  Show_Custom_Cursor("Click", 250)
  Return

Why can't AutoHotkey figure out that same interpretation for me?

I would prefer not having to modify all of my tiny self-contained scriptlets because AHK doesn't want to merge these labels together for me.

PS. I completely agree that Labels like OnClipboardChange should be Functions instead. But that's not a huge issue for me anymore (you can always wrap any Label in a nonsense Function).
Posted Image

Need help right away? Get live support on IRC.
Already have an IRC client installed? /join #ahk

RaptorX
  • Members
  • 751 posts
  • Last active: Feb 19 2015 02:47 AM
  • Joined: 19 Feb 2010
Lexikos quoting you is a pain because of how you quote each sentence that you want to answer to. :lol:

ok, I understand your explanations and yes I agree that a script that shows a warning every time it starts will become obnoxious at some point.

So basically we either fix the things manually or (hypothetically) let autohotkey do the merge silently and hope everything will be fine, which more often than not will NOT be fine and there will be tons of hours spent on debugging (on those extreme cases of course) because we dont know which is the duplicate label or where it is.

The thing with the function overload was just an example of the same behavior im not actually proposing to remove it. I was just pointing out that i couldnt simulate the behavior of the va_list typedef because I couldnt even overload the function parameters which is what va_list allows you to do.

Well, the current ahk code has the same disruptive behavior. It actually shows the warning message *and* stops the script instead.

I consider that a fatal error rather than a warning. Do you want to have to click through a bunch of warnings every time you launch a script designed that way? If it needs to bring up a warning message, it's probably a bad idea to allow it in the first place.

I am just saying it would be better if I get a message ... but the script ran anyways

Well, that's your point of view. I prefer it the way it is.

... the concept of merging or running labels sequentially is without doubt a good idea.

It should be fairly clear by now that I doubt it is a good idea.

The problem is ahk cant and shouldnt determine if duplicate labels are conflicting

AutoHotkey shows an error message specifically because they are conflicting.

So, in all I do think that the current ahk method is annoying not only for duplicate labels but when you pass too many/too few parameters to a function or when a byref variable is empty since those not only warn you but they also stop the execution of the script, when some times the script can run perfectly fine with those "errors".

I wouldn't want it any other way. Generally all of those are errors on the script author's part. Some of these errors must terminate the process since AutoHotkey isn't designed to work under those circumstances. Aside from that, if the function isn't designed to accept that number of parameters, passing that number of parameters is necessarily an error. Continuing execution of the script when there is known to be an error would be unwise, especially considering some of the things AutoHotkey can do. ByRef parameters are validated under a similar principle, though I agree it would sometimes be useful to be able to pass either a variable reference or a value.

If is too many parameters to a function that last parameter should be ignored,

In that case, what was the point of passing the last parameter at all? It's actually allowed for dynamic function calls since the author can't necessarily know in advance how many parameters will be needed and there's currently no way to pass a variable number of parameters.

it seems to be that empty byref variable messages give you the warning but exits the current thread, which is almost what I would say should be the global behavior because i get the information but if i dont get any undesired results then Im good to go.

Run-time errors such as that exist only because they can't be (or at least aren't) detected at load-time. I personally prefer to be notified of errors in the script before it runs and potentially does stupid things.

msgbox % %var%
; this var should be made blank instead of exiting the current thread

How would you then know there is an error in your code? (An error it almost certainly would be.)

I was trying to imitate the behavior but guess what? i got the error message as soon as i put one more parameter there, and there is no way around it, which is senseless.

There's no way to access the excess parameters, so passing them is senseless.

... and running duplicate labels sequentially have nothing to do with bad styles.

I disagree.



jethrow
  • Moderators
  • 2854 posts
  • Last active: May 17 2017 01:57 AM
  • Joined: 24 May 2009
2 cents...

I agree that there are certain situations where it would be nice to have duplicate labels, but I also agree that would be bad coding on the authors part.

If we were to change it so the script would allow duplicate labels, shouldn't we also change it so we can have duplicate function definitions? So each time you call a function, all the function definitions will execute?

Tuncay
  • Members
  • 1945 posts
  • Last active: Feb 08 2015 03:49 PM
  • Joined: 07 Nov 2006

I agree that there are certain situations where it would be nice to have duplicate labels, but I also agree that would be bad coding on the authors part.

Allowing duplicate labels is not for one source only, but for different sources, where the scripts are acting on its own.

I guess my total viewpoint boils down to this basic thought...

If *I* am able to perform the following interpretation:

; Before
~LButton:: Enable_Window_Under_Cursor()
~LButton:: Show_Custom_Cursor("Click", 250)

; After
~LButton::
  Enable_Window_Under_Cursor()
  Show_Custom_Cursor("Click", 250)
  Return

Why can't AutoHotkey figure out that same interpretation for me?

I would prefer not having to modify all of my tiny self-contained scriptlets because AHK doesn't want to merge these labels together for me.

AutoHotkey should do exactly this. But I understand the problems what Lexikos describes. Like I always do ( :D ) I suggest a new thread based keyword for this. Without the keyword Ahk acts as always. A merge process (I call it merge, its just a question of definition) is only allowed, if the keyword exist in the two labels. So the coder marks merging does not hurt and then no message or warning is displayed. Would this not solve our problem?

No signature.


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

Lexikos quoting you is a pain because of how you quote each sentence that you want to answer to. :lol:

I use quotes the way they should be used: to establish context for what I'm going to say. If the quote doesn't do that or deliver some sort of message, it has no real purpose other than to waste space and the time of anyone reading your post. Much like double-posting. If you don't understand this, please don't quote my posts.

The thing with the function overload was just an example of the same behavior im not actually proposing to remove it.

I think you were:

If is too many parameters to a function that last parameter should be ignored,


Why can't AutoHotkey figure out that same interpretation for me?

My point boils down to: Why should it? I've yet to see a compelling reason.

majkinetor
  • Moderators
  • 4512 posts
  • Last active: Jul 29 2016 12:40 AM
  • Joined: 24 May 2006
Because of

Allowing duplicate labels is not for one source only, but for different sources, where the scripts are acting on its own.


That is perfectly good reason. For instance, lets say that different authors map F1 to some cool hotkey action:


//VeryCoolActionModule.ahk
F1::
     if WinActive Notepad
         do some very cool action
return 


//WordModule.ahk
F1::
    if WinActive Word
         do some office action
return 

//User.ahk
#include WordModule
#include VeryCoolActionModule

F1::
    MouseGetPos, x, y
    tooltip % x " " y
return


However, I see bunch of additional things that must be implemented in order for this to be pro. You would also want to "continue down the chain" or "stop at the current hotkey method and prevent subsequent ones to run" (could be achieved by adding argument to return for hotkeys and keeping script compatibility). Also , HotKey command would need to be in sync with this, i.e. it will need to have "+" and "-" operation similar to C# delegates.

While we are at this, for OnMessage can be said the same, and its probably more important. Actually, I already proposed this to Lexikos some long time ago.

So, this requires some careful redesign but its usefulness is without doubt for few of us :)
Posted Image