Custom Query

Edited by Valik

Add native support for accelerator tables.

When you set accelerators to be used in a window (using GUISetAccelerators()), other windows also end up "inheriting" the accelerator table from the first window to get accelerators set. Attempting to override accelerator tables in the subsequent windows does not work as expected either.

Checking for window focus in the callback function usually works fine in many cases, but sometimes fails. For example, if keyboard shortcuts with normally "well-defined" behaviors (like {DELETE} or {ENTER} in input/edit controls) are associated with GUI window, then such an edit control in another window would never properly receive the {DELETE} or {ENTER}.

Here's a simple(ish) test script:

#Include <GUIConstantsEx.au3>

; Dialog 1 --------------
Global $Dialog1 = GUICreate("Dialog 1", 320, 240)
Global $Dummy = GUICtrlCreateDummy()

Global $Dialog1Accelerators[1][2] = [["{ENTER}", $Dummy]]
GUISetAccelerators($Dialog1Accelerators, $Dialog1)

; Dialog 2 --------------
Global $Dialog2 = GUICreate("Dialog 2", 210, 160)
Global $Edit = GUICtrlCreateEdit("", 5, 5)

Global $Dialog2Accelerators[1][2] = [["{ENTER}", $Edit]]
GUISetAccelerators($Dialog2Accelerators, $Dialog2)

; Miscellaneous ---------
GUISetState(@SW_SHOW, $Dialog1)
GUISetState(@SW_SHOW, $Dialog2)

While 1
    Switch GUIGetMsg()
        Case $GUI_EVENT_CLOSE
            Exit
        Case $Dummy
            MsgBox(0, "Dummy", "Hotkey caught by Dialog 1!")
        Case $Edit
            MsgBox(0, "Edit", "Hotkey caught by Dialog 2!")
    EndSwitch
WEnd

An (interesting?) aside: depending on situation, the second dialog might actually catch a hotkey press. If you never modify the contents of the edit control, the second window never gets catches the hotkey. After you modify the edit control, though, it manages to catch the hotkey press.

Au3Check.exe accept many invalid scripts like:

$X = "data" _
#cs
#ce