Passing shift + key to wow client in background

I'm currently trying to configure hotkeynet to pass certain shift + key combos to various WoW windows. I use PiP with 2 windows in each bottom corner of my main window. I have modifiers key (backslash and numpad5) bound to mouse buttons 6 and 7 respectively so when I hold one of those mouse buttons down on the mouse and press say the "1" key, the key press of "1" is send to a specific WoW instance. This all works well, see below.

Code:

<Label lw1 Local SendWinM w1> <Label lw2 Local SendWinM w2> <Label lw3 Local SendWinM w3> <UseKeyAsModifier Oem5> <UseKeyAsModifier Clear> <Hotkey Oem5 ScrollLockOn 0-9, Q, E, Minus, Plus, F, G, T> <If ActiveWinIs w1> <sendlabel lw2> <Key %Trigger%> <Else If ActiveWinIs w2> <sendlabel lw1> <Key %Trigger%> <Else If ActiveWinIs w3> <sendlabel lw2> <Key %Trigger%> <Else> <SendFocusWin> <Key %Trigger%> <Hotkey Clear ScrollLockOn 0-9, Q, E, Minus, Plus, F, G, T> <If ActiveWinIs w1> <sendlabel lw3> <Key %Trigger%> <Else If ActiveWinIs w3> <sendlabel lw1> <Key %Trigger%> <Else If ActiveWinIs w2> <sendlabel lw3> <Key %Trigger%> <Else> <SendFocusWin> <Key %Trigger%>

The part that doesn't seem to function, is when I try and pass a shift + 1 for example, through to a specific client. So e.g. hold button 6 on mouse down, and then press shift + 1 seems to either execute shift + 1 on the main wow window, or it just sends a "1" with no shift to the intended wow instance.

Code:

<Hotkey Oem5 ScrollLockOn Shift 0-9, Q, E, Minus, Plus, F, G, T> <If ActiveWinIs w1> <sendlabel lw2> <Key shift %Trigger%> <Else If ActiveWinIs w2> <sendlabel lw1> <Key shift %Trigger%> <Else If ActiveWinIs w3> <sendlabel lw2> <Key shift %Trigger%> <Else> <SendFocusWin> <Key shift %Trigger%>

I do recall reading in the hotkeynet notes that there can be issues with sending modifed keystrokes to wow in the background, but i saw in the FTL hotkeynet guide, the code appears to do precisely that?

Any ideas what I'm doing wrong?

When you press that hotkey, HotkeyNet displays messages saying which keystrokes it's sending. Which keystrokes does it say?

Quote:

Originally Posted by 'Freddie',index.php?page=Thread&postID=154721#post 154721

When you press that hotkey, HotkeyNet displays messages saying which keystrokes it's sending. Which keystrokes does it say?

Ok, found one problem, which was that I should have been using %TriggerMainKey% so that my extra mouse button modifier keys don't get sent through. After making that change, the shifted buttons still don't seem to work. Here's the output from hotkeynet.

Code:

From this pc: <SendWinM w2><Key Shift E> <SendWinM w2> completed: Window found. Target set to 0x203A2 "w2" <Key Shift E> completed

based on the modified code of

Code:

<UseKeyAsModifier Oem5> <Hotkey Oem5 ScrollLockOn Shift E> <If ActiveWinIs w1> <sendlabel lw2> <Key Shift %TriggerMainKey%> <Else If ActiveWinIs w2> <sendlabel lw1> <Key Shift %TriggerMainKey%> <Else If ActiveWinIs w3> <sendlabel lw2> <Key Shift %TriggerMainKey%> <Else> <SendFocusWin> <Key Shift %TriggerMainKey%>

I just get normal lower case coming through.

Quote:

I just get normal lower case coming through.

well in the documentation of SendWinM it says, that its converting all chars to lowercase, so are you sure that you don't actualy get: shift + e ?

Olipcs is correct. If you want a program to receive an uppercase E you need to use SendWinS for that character. (You can make a second label for that purpose.) Just because WoW receives a Shift and then receives an E doesn't necessarily mean WoW will interpret the E as uppercase. Background keystroke injection is more complicated than that.

Anhvariel, what "mouse button modifier keys" are you talking about? The only modifier I see in your script is Shift.

And when you say Shift 1 or Shift E isn't getting received, how are you judging that? What bindings in the game are you expecting Shift 1 and Shift E to trigger?

Quote:

Originally Posted by 'Freddie',index.php?page=Thread&postID=155025#post 155025

Olipcs is correct. If you want a program to receive an uppercase E you need to use SendWinS for that character. (You can make a second label for that purpose.) Just because WoW receives a Shift and then receives an E doesn't necessarily mean WoW will interpret the E as uppercase. Background keystroke injection is more complicated than that.

And when you say Shift 1 or Shift E isn't getting received, how are you judging that? What bindings in the game are you expecting Shift 1 and Shift E to trigger?

Ahh the problem seems to be that using bartender 4, and my hotbars use shift as a modifier to toggle a secondary bar, which doesn't seem to work with hotkeynet, so i tested shift + y and that worked fine as a direct keybind already defined to bring up the achievements window.

Quote:

Anhvariel, what "mouse button modifier keys" are you talking about? The only modifier I see in your script is Shift.

I didn't really explain that terribly well.

Code:

<UseKeyAsModifier Oem5> <Hotkey Oem5 ScrollLockOn Shift E>

Oem5=the backslash on my keyboard, and is set to be used as a modifier key. I have a logitech G7 mouse, which has 2 extra buttons that are normally used to increase/decrease mouse sensitivity. I have reprogrammed one of those buttons using the logitech software to execute the backslash keystroke. I have used an if statement to send commands only to wow window number 2 if the Oem5 modifier key is being pressed, so by holding down that button on the mouse i can basically use the rest of my hotkeys as though wow 2 was actually my main window, i.e. keystrokes that are pressed only go to it and not the main window.

Anyway, it would appear my problem is with how bartender handles the shift modifier when receiving keystrokes, so I'll need to figure out a workaround, sadly bartender works so well for classes such as druids when it provides a hotbar for each form etc.

Thanks for your help both of you, and thanks freddie for an outstanding piece of free software :)

Thanks for the kind words. Is HotkeyNet feeding its output into Bartender as Bartender's input, or is it the other way around?

Edit: Nvm, you said Bartender is between HotkeyNet and WoW. I just woke up. :)

My workaround solution is to simply assign keybinds to the shift-paged bar. so even though shift pages from bar 1 to 3, i also bind shift +1 to button 1 on bar 3, shift +2 to button2 on bar 3 and so on. normally not necessary, due to shift paging but fixes the problem after a fashion.

Now I'm a little more awake and read this again. :) Grats on figuring it out. If somebody can provide some details about how Bartender gets (reads) keystrokes maybe I can suggest something else.

Quote:

Originally Posted by 'Freddie',index.php?page=Thread&postID=155206#post 155206

Now I'm a little more awake and read this again. :) Grats on figuring it out. If somebody can provide some details about how Bartender gets (reads) keystrokes maybe I can suggest something else.

It seems to be something to do with the fact that bartender treats shift key almost in the fashion that you have movement key, I.e. when you hold shift down, it toggles over to the switched hotbar, and then when you press the actual hotkey, "1" for example, it activates the hotkey, so the hotkey isn't actually triggered by a shift+1, but a simple "1" while the shift button has the hotbars swapped over.

I think having shift configured as a movementhotkey when sending to a wow window other than main would fix the problem. Is there any way to prevent shift from being seen as a modifier, and simply using it as a standard movement hotkey?

hi, as far as i know, this is not directly possible as shift is predifiened as modifier and therefor can'T be used as a hotkey allone.
Only workaround i could imagine is defining a other key as an movement key and letting it broadcast shift like:

Code:

<MovementHotkey y> <SendLabel w1,w2> <Key shift>

Olipcs is right. Just to clarify, the restriction is that Shift can't be used as a trigger by itself. This restriction has no effect on output. Hotkeys can take any action you like including sending Shift by itself.

I made this restriction to try to prevent certain user errors. I'm planning to remove it before the end of the beta.

Please let me know if Olipc's Y hotkey solves the problem. If so I'll raise "removing the restriction" up higher on the to do list.

(I'm sure you realize Y can be any main key or combination of keys.)

Olyipcs suggestion works fine, but as i said, the workaround i used was to simply keymap each shifted combination hotkey and that's been fine. Using another key such as "y" doesn't really work for my key layout.