Jump to content


Photo

[Solved] #InputLevel preventing tray menus from updating


  • Please log in to reply
8 replies to this topic

#1 rbrtryn

rbrtryn
  • Members
  • 818 posts

Posted 10 May 2012 - 05:25 PM

I noticed that when I run the following script the custom tray menus for the other scripts that are running no longer update properly. If I remove #InputLevel 1 the tray menus again operate as they should.

The tray menu seems to get stuck displaying the same menu for all of the running scripts.

#NoEnv
#NoTrayIcon
#Warn
#LTrim
#SingleInstance force
SendMode Input
SetWorkingDir %A_ScriptDir%

#InputLevel 1
RButton & LButton:: Click Middle
$RButton:: Click Right



#2 rbrtryn

rbrtryn
  • Members
  • 818 posts

Posted 08 August 2012 - 09:24 PM

This problem still exists in ver 1.1.08.01. Has anyone had time to look into this?
Any info greatly appreciated! :D

#3 Lexikos

Lexikos
  • Administrators
  • 8850 posts

Posted 09 August 2012 - 08:01 AM

#InputLevel merely sets a global variable in the script. This variable is copied into a property of each Hotkey or Hotstring. This property affects which keyboard or mouse events can trigger the hotkey. It seems impossible that #InputLevel alone would cause problems with script menus, but it may be possible in combination with your specific RButton hotkey, which performs a simulated click. However, this may be a design problem of your script rather than an error in AutoHotkey.

I don't really understand what you claim the problem to be. Can you provide a simple script (or two) which reproduces the problem? (The script you have provided is not sufficient, as it clearly does not have a custom tray menu.)

#4 rbrtryn

rbrtryn
  • Members
  • 818 posts

Posted 09 August 2012 - 03:27 PM

Well it looks like it was my error. :roll: Apparently in this context I must select a tray icon by left clicking on it before I can display its context menu by right clicking on it. A slight change to the script fixes the problem. Sorry for my confusion.

For reference, here is the fixed script:
#NoEnv
#NoTrayIcon
#SingleInstance force
#InputLevel 1
SendMode Input

RButton & LButton:: Click Middle

RButton::
	Click
	Click Right
return


#5 rbrtryn

rbrtryn
  • Members
  • 818 posts

Posted 09 August 2012 - 06:00 PM

Actually that doesn't quite work either. This is the final version:
#NoEnv
#NoTrayIcon
#SingleInstance force
#InputLevel 1
SendMode Input

RButton & LButton:: Click Middle

RButton::
	MouseGetPos, , , WinId
	WinActivate ahk_id %WinId%
	SendPlay {Click Right}
return


#6 Lexikos

Lexikos
  • Administrators
  • 8850 posts

Posted 09 August 2012 - 10:18 PM

For what purpose are you using #InputLevel?

I couldn't find it mentioned in the help file, but it appears that SendPlay bypasses the keyboard hook, and therefore never triggers hotkeys regardless of #InputLevel or SendLevel. If you don't want to trigger any hotkeys, you could have used SendLevel 0 prior to Send. By default, the hotkey subroutine uses a send level equal to the input level of the hotkey.

I've done some testing, and have some information about this problem:

As the prefix key in a custom combination can be used in many hotkeys, under many different (#if) conditions, with many different input levels, it isn't feasible for #InputLevel to apply to the prefix key. Instead, the prefix key x in x & y:: acts as though it is at #InputLevel 0. If the key is only used in custom combinations, any simulated event at SendLevel 1 or higher will be blocked as if it was a physical event.

The real problem is that when a hotkey x:: is also present with #InputLevel 1, key-up events at SendLevel 1 or lower are "ignored" by the hotkey (which fires only on key-up) - but are also ignored by the prefix key, so they pass through to the active window. It seems that if you send a right click-up event to the system tray, it will pass the message along to whichever icon last had a click-down event, rather than the icon under the cursor.

#7 rbrtryn

rbrtryn
  • Members
  • 818 posts

Posted 10 August 2012 - 12:54 AM

For what purpose are you using #InputLevel?

I have another running script, DirMenu, which captures middle mouse button clicks. If I don't have my mouse with me, I want to be able to use the right and left buttons on my touchpad to simulate the middle mouse button.

Without #InputLevel 1, DirMenu won't see my simulated mouse clicks.

SendPlay bypasses the keyboard hook, and therefore never triggers hotkeys regardless of #InputLevel or SendLevel.

That is why I used SendMode Input for the key combination and overrode it with SendPlay {Click Right} for the right click.

As the prefix key in a custom combination can be used in many hotkeys, under many different (#if) conditions, with many different input levels, it isn't feasible for #InputLevel to apply to the prefix key. Instead, the prefix key x in x & y:: acts as though it is at #InputLevel 0. If the key is only used in custom combinations, any simulated event at SendLevel 1 or higher will be blocked as if it was a physical event.

You seem to be saying that middle clicks simulated by the script above will not be captured by DirMenu because it uses #InputLevel 1. I know that is not the case because I am using the script above right now to fire the hotkey defined in DirMenu. If I change the line to #InputLevel 0, the hotkey is no longer activated.

The real problem is that when a hotkey x:: is also present with #InputLevel 1, key-up events at SendLevel 1 or lower are "ignored" by the hotkey (which fires only on key-up) - but are also ignored by the prefix key, so they pass through to the active window. It seems that if you send a right click-up event to the system tray, it will pass the message along to whichever icon last had a click-down event, rather than the icon under the cursor.

Luckily SendPlay {Click Right} seems to avoid this problem, probably because #InputLevel is being ignored.

#8 Lexikos

Lexikos
  • Administrators
  • 8850 posts

Posted 10 August 2012 - 03:37 AM

Without #InputLevel 1, DirMenu won't see my simulated mouse clicks.

#InputLevel is intended for controlling which events trigger the hotkey, and affects the default SendLevel only as a secondary effect. If you don't need to change the input level of the hotkey, use SendLevel 1 prior to Click Middle instead. (Use a multi-line hotkey.)

You seem to be saying that middle clicks simulated by the script above will not be captured by DirMenu because it uses #InputLevel 1.

I said nothing about DirMenu or middle clicks, only about the prefix key in a custom combination. Are you using MButton as a prefix key? I also noted that the key-up event is passed through (not blocked) in specific cases.

#9 rbrtryn

rbrtryn
  • Members
  • 818 posts

Posted 10 August 2012 - 04:13 AM

Posted Image Ok, I see my mistake.

So the script should be like this:
#NoEnv
#NoTrayIcon
#SingleInstance force
SendMode Input

RButton & LButton::
	SendLevel 1
	Click Middle
return

RButton::Click Right
_________________________
Composed/Posted with WYSIWYG BBCode Editor