Detect a right click or modifier key in XY scripting menus

[klownboy]

Hi Don, would it be possible to get a get 'trigger type' capability for a scripting menu item. In other words, be able to detect if the user has pressed a right mouse button in lieu of the normal left click. It would make scripting XY menus so much more powerful and open it up to so many new possibilities. If a right click of a mouse button detection is not possible or a coding nightmare, an alternative would be to detect if the user had a modifier key (e.g., control or shift etc.) held down while they clicked a mouse button. Essentially someone could program via scripting dual actions for a menu item similarly to what we can currently do with a CTB and get trigger, but this would expand that functionality way beyond that. For example a script could very easily program actions to simulate the actions of the user CTBs and XY built-in buttons for the both left and right mouse clicks simply by the mouse button clicked.

I know this is a big wish and this topic has been touched upon before, but I think it would be a such a very powerful addition to XY's scripting capability that it deserves to resurface again.
http://www.xyplorer.com/xyfc/viewtopic. ... 10#p103468
http://www.xyplorer.com/xyfc/viewtopic. ... 15#p119286
Thanks,
Ken

[TheQwerty]

I am against right-click detection within menus via Get('Trigger') - frankly I think Trigger should be removed, but that's a different topic.

I approve of the idea of Get('TriggerModifierKeys') (or similar) returning info about any combination of Shift/Ctrl/Alt that were held when a script was started.

Since we still do not have bit-operators I don't think it should return an OR-ed bit flag but rather a string of characters representing which buttons were held down. It could mimic SendKeys and use '+' (Shift), '^' (Ctrl), and '%' (Alt) or AutoHotkey which uses '!' for Alt instead and adds '#' for WinKey.


If the ability to retrieve modifier keys is added I am also okay if XY converted right-click triggers into Ctrl+Left-Click (or similar). While this still encourages developers to break standards to have different left/right-click menu actions it limits the damage they can do.

I feel this is a good compromise...
1) It allows for the real intent triggering multiple actions from a single menu item.
2) It limits the total number of actions in a single item to 8 rather than 16 (or more if other mouse buttons were added).
3) It doesn't encourage script authors to entirely ignore mouse or keyboard users - all actions are still accessible via either.

[klownboy]

I'd be thrilled if we got even one modifier key, especially Ctrl since it's most easily accessed though I'm not convinced that right clicking a menu item is a such bad thing and certainly not get('trigger') on a CTB. I'd hate to see the right click or trigger in general go away for CTBs - too many scripts out there that utilize it. I think most people could handle either a left or right click on a CTB and have to use a modifier on an menu especially since many of the menus don't necessarily involve the use of a CTB anyway. It makes practical sense though if we did have the capability to use a modifier key on a CTB, then the modifier would already be held down to use it on a menu item.

[PeterH]

A comment of how to return info: I would not like to return pressed modifier keys by some characters.
For me they might be returned in binary, but with "digits" "o" and "l" (often used in boolean logic), or even in decimal.
I can provide a "Subroutine" converting a decimal number to a binary string with "ol" (and to hexadecimal). Needed it sometimes.
(Restriction: 32 bit length)

I think querying modifier-keys by bit position (in a string) is better than testing for different characters.


By the way: "Subroutine" in quotes, as we still don't have userdefined Functions and Subroutines
So values have to be sent and received by Global Variables

[nerdweed]

Agreed that XY doesn't have bitwise operators and I would love to have them. However; that doesn't mean that the function can't return bit values. Almost all functions return bit values in XY - we don't have to compute what are held as the bit values for the held keys are already known

Code: Select all

+ Scripting got a new function.
      Name: GetHeldKeys
      Action: Returns a bit value for keys held
      Syntax: heldKeys = GetHeldKeys()
        returns:
			0 = No keys held
			1 = Ctrl
			2 = Alt
			3 = Ctrl + Alt
			4 = Shift
			5 = Ctrl + Shift
			6 = Alt + Shift
			7 = Ctrl + Alt + Shift

[TheQwerty]

Code: Select all

+ Scripting got a new function.
      Name: GetHeldKeys
      Action: Returns a bit value for keys held
      Syntax: heldKeys = GetHeldKeys()
        returns:
			0 = No keys held
			1 = Ctrl
			2 = Alt
			3 = Ctrl + Alt
			4 = Shift
			5 = Ctrl + Shift
			6 = Alt + Shift
			7 = Ctrl + Alt + Shift

Yeah... I don't know what I was thinking. I'm okay with this.

Though I think it's a parameter of Get (Get('HeldKeys')) since we are not looking for the modifier keys at this particular point in time but rather those that were being held when the script was triggered.

[TheQwerty]

I'm not convinced that right clicking a menu item is a such bad thing and certainly not get('trigger') on a CTB.

1. It creates menu items with commands that are completely inaccessible via the keyboard and thus encourages script writers to forget about keyboard accessibility.
2. It's really non-standard behavior.
3. It's bad to hide functionality from the user.*
4. With modifier keys it results in the ability to cram 8 additional actions into a single item for each mouse button that is added to Get('Trigger'). Too many choices is a big problem, too many hidden choices an even bigger one.

* For what it's worth this is the same reason that Microsoft gives when telling developers not to change a menu item's action based on which modifier keys are being held.

I'm not crazy about modifier keys for many of the same reasons, but at least they don't completely preclude one of the two most common input methods.

I'd hate to see the right click or trigger in general go away for CTBs - too many scripts out there that utilize it.

I never said the ability to trigger a right-click script should go away for CTBs.

However, there is no reason for Get('Trigger') to exist and I believe Don made a mistake adding it in the first place. I'd like to see it deprecated and eventually removed rather than have it continue to be used unnecessarily.

Since 2009 in version 8.40.0102 it was possible to define a CTB with left and right click scripts.
Which means there was never any reason for the script to need to ask which button triggered it.

Left-Click:

Code: Select all

Global $TRIGGER = 'Left';Load 'script.xys';

Right-Click:

Code: Select all

Global $TRIGGER = 'Right';Load 'script.xys';

Script.xys:

Code: Select all

"Main"
  Global $TRIGGER;
  Echo 'You ' . $TRIGGER . '-clicked the button!';

The amount of work that Get('Trigger') saves is minuscule. It really adds nothing but confusion over why it doesn't work outside of CTBs.

[highend]

Mh, is it really an improvement when context menus deliver the modifier with which they were clicked? How long must be the name of a menu item to give the user a hint what happens when he uses, e.g. alt or ctrl (or shift, or win...) when he clicks on it? And if the name isn't helpful enough should we be able to remember 4-5 different actions per item depending on any modifiers? I'm scared! xD

[klownboy]

Hi TheQwerty, I know right click of a CTB would not go away with get trigger departing, but some of us have used 'trigger' in a number of scripts, so it does mean back tracking to change who know how many scripts. Get trigger was also originally suppose to cover the middle mouse button, but Don said it would come later that can't be accomplished with the current CTB edit dialog box. As a fatter of fact the help has states: "MiddleClick = 4 (planned)"
I don't think it's all that confusing to people who have been scripting for any length of time that get trigger is used for CTBs only though Don should make that clear in the help file. I agree with most of what you are saying, but I don't think it's hurts anything to simply leave it alone.

Hi highend, I agree that that any more than 1 or possibly 2 modifiers will get out of hand and difficult to manage. If available, I'd probably only use one and that's if and when needed. I was initially only after "right" click detection in an XY menu, but a modifier key would work also. I could do

[L] Jump the Gun [R] Swallow the Pill

but how do you satisfactorily explain 4 or 5 choices in a menu item.

[TheQwerty]

Hi TheQwerty, I know right click of a CTB would not go away with get trigger departing, but some of us have used 'trigger' in a number of scripts, so it does mean back tracking to change who know how many scripts.

And when it is deprecated you will know to begin modifying those scripts.

Get trigger was also originally suppose to cover the middle mouse button, but Don said it would come later that can't be accomplished with the current CTB edit dialog box. As a fatter of fact the help has states: "MiddleClick = 4 (planned)"

There's no reason the CTB dialog itself cannot be expanded to allow for a Middle Click script, which would open up this capability to much more than just those writing complex scripts.

... but I don't think it's hurts anything to simply leave it alone.

I disagree because of your very first statement. Leaving it alone means its unnecessary use can grow making it more difficult to remove later. Plus, it leaves this can of worms open about how it can be expanded.

It should be marked for deprecation in the change log and the documentation.
The authors of "who know how many scripts" can go about updating those scripts.
The authors of future scripts will know to avoid it.
If/When it is actually deleted those that did not pay attention will be bitten.

We've been here before and it really wasn't a problem except for the fact that someone did not give us any warning or notice before the actual removal.

[nerdweed]

Options of plenty doesn't mean that you have to use them all.

Let me give some examples where it would fit in bits and pieces

The HotList/HitList script - Currently, it gives a menu option to choose goto/copy to /move to - It can be modified to goto the location when nothing is held, copy to when ctrl is held and move if alt or shift is pressed

A handful rename scripts bundled together in a script - Can use shift for upper casing or Ctrl+Shift for title casing

A script that list paper folders - can be activated when nothing is held, selected items are added to the clicked paper folder when alt is pressed

There may be scenarios where a script with 10 subscripts has only one or two subscripts that will make use of it - which is absolutely fine

[klownboy]

First of all They're all good arguments. Obviously you don't like get ('trigger') and there are other ways to accomplish the same thing, but in the end I don't see why Don would elect to break or remove a command that's been out there and used successfully for 2 years unless leaving it in actually conflicts with something else in XYplorer. Most importantly, it doesn't pass the common sense test. The argument that there are other ways to accomplish it and expanding the CTB edit dialog are all valid, but let's face it, there are many different ways to accomplish the same things in XY. I'm not trying to be argumentative...just mentioning counter views. again

You're right nerdweed we don't have to use them (all) just because the options are there. But then again, I don't want to overwhelm Don to a point where he just doesn't think the programming time is worth it when all most people really need is one or two modifiers. Obviously, I haven't thought out all the potential uses for it the modifiers though.

[TheQwerty]

After playing with the new PFADefaultOpenFolders tweak a bit, I came to realize that having it enabled meant losing the ability to Shift+Left-Double-Click to open a folder in a new tab.

So here's a bump for retrieving the modifier keys in a script, which would at least allow those of us living dangerously with Folder PFAs to regain this ability and then some.


EDIT: I'm slightly warming up to detecting which mouse button triggered the script thanks to this feature too. Though I still don't like it for menu-based scripting.

[klownboy]

Cool Don, thank you for this and thanks TheQwerty for resurfacing the wish. A quick test script works like a champ...not thoroughly test but this works.

Code: Select all

"Control Panel All Tasks|:conf" run "%windir%\explorer.exe shell:::{ED7BA470-8E54-465E-825C-99712043E01C}"
"CFI or Customized TB [w ctrl}|:cfi"
  if(get("shift") == "2") {#603}
  else {#653;}
"CFA or CKS [w shift]|:cks"
  if(get("shift") == "1") {#602}
  else {#604;}

Edit: This change will be a big plus when simulating both a left and right click of toolbar buttons in scripts like vTB such that the same menu item for your CTB can now run either the left or right click assigned program or menu of that particular CTB depending on the modifier you have held down.