id summary reporter owner description type status milestone component version severity resolution keywords cc 219 Accelerator tables and multiple GUI windows Ultima Jon "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 ; 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." Bug closed 3.2.11.10 AutoIt 3.2.11.9 None Fixed accelerator table child