30 replies to this topic

[Raccoon]

I would like to suggest that AutoHotkey permit duplicate Hotkeys and Labels by calling each in sequence when duplicates are present.

For example, if you have two different #includes each with an OnClipboardChange: label, AHK should trigger both labels in sequence.

Same would apply if there are two occurrences of ~LButton:: hotkey.

I can see no drawbacks or incompatibility in permitting this addition, and it could greatly improve the power of Libraries and other #includes.

Discuss and consider. Thanks.

[RaptorX]

i do not see the need for duplicate #includes, i do hate the "duplicate label" error though.

[Raccoon]

well, I didn't say duplicate #includes. So let me give an Example:

;Main.ahk
#SingleInstance, Force
#NoEnv
SetBatchLines, 0
RETURN ; End Auto-execute section.

#include GenericHotkeys.ahk
#include MultipleClipboards.ahk
#include ClipboardLogger.ahk
#include ... etc etc

;MultipleClipboards.ahk
;Stores multiple clipboards.

OnClipboardChange:
  ; code for storing multiple clipboards
  Return

;ClipboardLogger.ahk
;Logs clipboard contents to file.

OnClipboardChange:
  ; code for logging clipboard contents
  Return

In the above example, two unique modular scripts (#includes) contain a call to the same label event OnClipboardChange: which performs different tasks. Sure, the two scripts could be merged together to form a single script that shares the same label, but this seems wholly unnecessary if AHK would simply trigger each label in sequence.

[Tuncay]

I had made a similar wish (in fact, near 3 years before). Chris wrote, that he adds this to his notes. Actually he is not really working on ahk anymore, so no hope for now.

That idea applies to other things like OnExit also. May be a new command could be added like: #NoDublicateLabels or #AllowDublicateLabels

Posted: Sun Oct 07, 2007 9:31 pm Post subject: [ Allowing duplicate labels ]

[HotKeyIt]

I think this would create more confusion than help.

Imagine a OnClipboardChange would change clipboard so second label would not work as expected.

Also OnExit could Free some libraries and second OnExit would still require these (e.g. COM). Also ExitApp of first OnExit label would be called before second label.

Additionally when you use GoSub or GoTo, both labels would be called, so it would be not possible to call only one label, especially the script you include was surely not designed to call both labels.

[Tuncay]

If you use all features to try to confuse any user, then you can do this easily. A function can be designed in a way, which a user would not expect it. Does that mean that we should not create functions for other users?

I mean, only because a feature CAN make confusion, is it not useful in some other scenarios? After allowing duplicate labels (may be with a special command to explicitly activate, for preventing unwanted behavior), designer / programmer can take advantage of that feature.

In fact about OnClipboardChange you are right. I was talking about general custom labels.

[HotKeyIt]

Can you show an example where it could be useful?

[Raccoon]

I think I just did.

And BTW. The OnClipboardChange: event does not change the clipboard; it notifies you of a change. There's no reason why multiple scripts being interpreted by the same AHK.exe process couldn't benefit. It's the same as running 2 scripts from the same process.

Consider ~LButton: multiple times in the same script file. There's no reason you shouldn't be able to. There's nothing confusing about it.

~LButton::
Do some stuff.
Return

~RButton::
Do some stuff.
Return

...

~LButton::
Do more stuff. yeay!
Return


There is absolutely NO WAY anyone could get confused by this. And if they could, well then, they won't attempt to try it will they. No harm no foul. No confusion added.

[Lexikos]

If two labels in the same #IfWin context can be executed by one keypress, what about two labels in different, overlapping contexts? For instance, #IfWinActive Post a reply and #IfWinActive your-browser or #IfWinActive (no params, i.e. the global context). I think it wouldn't make sense to execute multiple labels in one context and not execute labels in an equally-relevant context, but executing every label in every relevant context would often be undesired.

Hotkeys and hotstrings are essentially exempt from the rule that label names must be unique; they must be for #IfWin to work. I can see why you might argue duplicate hotkeys should be allowed, but what possible good could come from allowing duplicate labels (or virtually grouping them together)?

OnExit currently allows only one "on exit" label throughout the script, but this has nothing to do with uniqueness of label names and therefore probably isn't really relevant to this topic. For that sort of usage, I think a far better solution would be for scripts to register interest in an event a la addEventListener or attachEvent, providing a function or label to call when the event occurs. OnClipboardChange, OnMessage, OnExit and any other interesting events could be supported through the same, consistent mechanism, all offering the ability to register one or more labels or functions.

Consider ~LButton: multiple times in the same script file.

Consider ~LButton:: occurring once in the script but performing multiple actions. That's no less functional, but its purpose is much clearer.

There's no reason you shouldn't be able to.

There's no reason you should need to. It would add arguably little benefit at the cost of more complication.

There's nothing confusing about it.

Maybe to you.

And if they could, well then, they won't attempt to try it will they.

Not intentionally...

[Raccoon]

Lexikos: I think we're pretty much on the same page here. But perhaps one thing might make my intentions more clear. I believe Hotkeys and Labels should be treated as signals are. For every reason that signals are useful, I challenge that sequentially triggering duplicate hotkeys and labels is valid.

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. You can use #IfWinActive Notepad, multiple times throughout the script (eg, even across several #includes).

OnExit currently allows only one "on exit" label throughout the script, but this has nothing to do with uniqueness of label names and therefore probably isn't really relevant to this topic. For that sort of usage, I think a far better solution would be for scripts to register interest in an event a la addEventListener or attachEvent, providing a function or label to call when the event occurs. OnClipboardChange, OnMessage, OnExit and any other interesting events could be supported through the same, consistent mechanism, all offering the ability to register one or more labels or functions.

Consider ~LButton: multiple times in the same script file.

Consider ~LButton:: occurring once in the script but performing clearermultiple actions. That's no less functional, but its purpose is much .

There's no reason you shouldn't be able to.

There's no reason you should need to. It would add arguably little benefit at the cost of more complication.

There's nothing confusing about it.

Maybe to you.

And if they could, well then, they won't attempt to try it will they.

Not intentionally...

#include A.ahk
#include B.ahk

The point here is that each modular include is a self-contained entity without the need for handlers or group delegation to further sub-divide the love from OnClipboardChange or ~LButton:: or whatever. That sub-division should be handled quietly and internally, allowing us to use the Labels we are already familiar with, and for them work to even when the include.ahk is ran stand-alone or in a collection.

This allows multiple tiny scripts to be ran from a single Autohotkey.exe process, even if two of them share identical hotkeys or events.

Kid:  Can I have a cookie?
Baker:  Here, you may have two.
  Kid:  But they look the same!  Duplicate cookie?  What do I do?
Baker:  Eat one, and then eat the other.
  Kid:  Are you sure I shouldn't wrap both cookies in a napkin first?
Baker:  Just eat them!
  Kid:  I'm scared.

[RaptorX]

Raccoon, i apologize, I didnt understand the proposition the first time.

Now that brings up an interesting issue, at least on my mind.

lets say file A.ahk contains a label that performs some changes on the clipboard, now lets also say that file B.ahk contains the same label name which also works on the clipboard but it depends on the original contents of the clipboard to do its work...

let me clarify, A.ahk changes whatever was on the clipboard to numbers, while file B.ahk is going to change all "s" in to "S".

Now you create your own onclipboardchange label, and we now have 3 happy labels that are the same.

when you run your script you get no warning/error and your script executes fine, but your onclipboardchange is not working as you want.

main issue here is that you are aware of the label on file A.ahk but not the one of file B.ahk.... further more those two included files were written by someone else, and they are not small.... ok im stretching the story here... but let me show you how the includes of one of my current script looks like:

;+--> 
; ---------[Includes]---------
#Include *i %a_scriptdir%\extlib ; Current Library
#Include httpQuery.ahk
#Include klist.ahk
#Include xpath.ahk
#Include hkSwap.ahk
#Include sc.ahk
;-

My current script is like 2000 lines of code with like 100 labels... if there is for some annoying reason two labels that are the same and provoke changes that interfere with each other in any form, finding the error will be a real pain in the arm...

I still hate that i cannot run a script that has a duplicate label. There should be a warning or something but the script should run.

[Tuncay]

Yes that would be the solution RaptorX. AutoHotkey behaves on thread (subroutines, labels) so that all settings like SetBatchLines are fresh default (depending on autoexecution). That means if a hotkey changes the SendMode for itself, then other hotkey are not affected by the hotkey.

If two definitions of same hotkey would be allowed, then they could do action after the first defintion is over with its work. They do have their own "settings environment".

Because it is an error at current stage, no existing script would be broken by that.

let me clarify, A.ahk changes whatever was on the clipboard to numbers, while file B.ahk is going to change all "s" in to "S".

With the OnClipboardChange, I am not sure how to solve. Recovering the clipboard as a virtual clipboard for next call of OnClipboard only would not work; which clipboard to use then? You have two different results, but you need one only.

[Raccoon]

Um... I really don't see the problem in the above example with OnClipboardChange.

The effect should be the SAME, whether both labels are in the same script, or if they are in separate scripts running in separate processes.

As Tuncay pointed out, every 'thread' starts off with its fresh set of defaults and variables. Eg, those would be reset after one OnClipboardChange thread ends, and the next one begins. There should be no cross-over with the implementation I recommend, and this shouldn't be a problem to implement. Even if the first event makes changes to Clipboard, the waiting thread should still see the old version.

As far as duplicate custom named labels; that's simply up to you to decide how you name your labels, and whether you want duplicate names or not. Since this was never permitted before, there are no existing scripts that would be affected negatively.

[Tuncay]

Racoon, the problem with the clipboard is that:
1. Before OnClipboardChange A is called, the clipboard is saved to virtual clipboard by AutoHotkeys internal backup system.

2. A would "replace" all single `n to `r`n.

3. OnClipboardChange B waits until A is over.

4. After A is over, AutoHotkey call B with backed up clipboard.

5. B would "replace" the first 5 characters to space.

6. After B is over, then the two functions could do their work. But what to do then?Which result should have the final clipboard? Or did I understand something incorrectly?

[Raccoon]

Tuncay: 2 choices can be made here.

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

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

Option A would perhaps be more true to my overall opinion of the implementation and how it should apply toward all Hotkeys and Events.

Option B would perhaps be chosen specifically for OnClipboardChange to enhance scripting capabilities. Though I'm not specifically interested in this method of sharing modifications to Clipboard from first procedure to the next, it may be of use and worth discussion.