Accelerator keys lazarus / 31-LCL ---------------------------------------------------------------------- Walmir · 2014-08-01 19:20 Hi, Except for TMainMenu, the accelerator keys (with ALT) are not functioning in my applications. I noted that even in Lazarus IDE, they also don't work in some windows. Is it a bug? ---------------------------------------------------------------------- rvk · 2014-08-01 19:47 It's hard to say without more information. If you make a new application and place 2 buttons on the form with &Button and B&utton as caption and write some Showmessage in the onclick's do the Alt+B and Alt+U activate these buttons ? If they do then there is nothing wrong with the accelerator keys and there is probably something in you're code eating those keys (and we can't help you if we don't know the code). (And in what windows in the Lazarus IDE are they not working for you exactly?) ---------------------------------------------------------------------- BrunoK · 2014-08-02 06:56 Maybe what  Walmir means is that, for example, in the Lazarus (any version) Search/Replace dialog (Ctrl+F) (see attached .png), pressing : Alt+R (Replace with) beeps and does nothing, Alt+C (Case sensitive) beeps and does nothing, Alt+W (Whole words only) beeps and does nothing, etc ... Am I  correct ? ---------------------------------------------------------------------- typo · 2014-08-02 07:09 My version does not have the underlined letters and Alt+Anything beeps and does nothing. Lazarus 1.2.2 r44758 FPC 2.6.4 i386-win32-win32/win64 ---------------------------------------------------------------------- eric · 2014-08-02 07:20 All the accelerator keys in the Find/Replace dialog work correctly here (Lazarus 1.2.4, Linux 64-bit, gtk2). ---------------------------------------------------------------------- rvk · 2014-08-02 07:44 Here the underlined character only become visible after pressing the first ALT. But i did notice the Alt-keys all work with the checkbox- fields but they don't work with the radiogroup-options (while these also have underlined characters) So Ctrl+R brings up the Replace dialog but after that Alt+e does not choose the radiobutton "From beginning" while the "e" of beginning is underlined. When you use the radiogroup in your own program they too don't work !! So if Walmir meant that the accelerated keys of the radiogroup doesn't work... i can confirm this. This is on Windows 7 Professional and Lazarus 1.2.4 r45510 FPC 2.6.4 i386-win32-win32/win64 (And even though the other ALT+checkbox-letters work they do produce a beep) ---------------------------------------------------------------------- BrunoK · 2014-08-02 08:56 Here we are advancing constructively, thank you guys. So we have different behaviours depending on : OS : Linux/GTK2 or Windows Windows : versions of Windows As to the presentation maybe also in Lazarus : Tools->Options->Desktop->Language And maybe also OS Keyboard setup. So my configuration is OS         / Version                 / Lazarus        /  Desktop      / Keyboard Windows / XP Pro 32 bit SP3 / 1.2.4             / Français [fr] / Français [Suisse] The comment I posted above applies also when I work with Desktop English [en] and Deutsh [de] Synthesis to this point : typo    does not have underlined letters -> Questions : Which Windows version ? What is your desktop->langage ? eric     (Lazarus 1.2.4, Linux 64-bit, gtk2). Everything works. I'll try to update my Linux test machine and see how it works. Maybe it is GTK2 that makes the difference. (Have some difficulty connecting it to my router, I'm pretty dumb with Linux). Still, it would be interesting to know the Desktop language and the configured Keyboard. rvk      Accelerator keys work for checkboxes on Windows 7 Pro but still beep.    -> Questions to rvk who has a different mix of behaviour. Which Desktop ? Which keyboard ? At last we may get to the bottom of that thing, solve it, and put it to rest in a future version of Lazarus. Regards, Bruno K ---------------------------------------------------------------------- rvk · 2014-08-02 10:15 Quote from: BrunoK on August 02, 2014, 10:56:34 amrvk      Accelerator keys work for checkboxes on Windows 7 Pro but still beep.    -> Questions to rvk who has a different mix of behaviour. Which Desktop ? Which keyboard ? I always use English OS, English language and US keyboard layout. Windows 7 professional. Lazarus 1.2.4 r45510 FPC 2.6.4 i386-win32-win32/win64 It gets even weirder... At home my radiogroup doesn't even react to accelerated keys at all (only with a bleep) (from Lazarus IDE and my own program). At work (logged in via RDP) the radiogroup does react although the choice doesn't get selected but the focus does transfer to the chosen option (also with a bleep). I think i need to download a fresh version of Lazarus to see if it has something to do with recompilation but... yeah... there is definitely something weird going on. ---------------------------------------------------------------------- ChrisF · 2014-08-02 13:44 My own 2 cents... For Windows (since Windows 2000), keyboard indicators become visible (i.e. underlined characters) only after having pressing the 'Alt' key at least once. This is conformed to the standard Windows behaviour (see here for instance: http://blogs.msdn.com/b/oldnewthing/archive/2005/05/03/414317.aspx), and as far as I've tested, Lazarus is OK with that (i.e. UI states correctly processed). Please note that it can be changed inside the Windows control panel (I guess it's rarely the case). Invoking control accelerators (i.e. Alt+Letter) always produced a beep in Windows versions of Lazarus (both for IDE and user's programs), even if there is one (or more) valid control. IMHO this one is clearly a bug, as the beep should be present only when there is no solution for the given Alt+Letter combination. There is (at least) one bug report about this problem, though it's first main topic is not concerning it: http://bugs.freepascal.org/view.php?id=19223 (see the last note). There are a few differences between Delphi and Lazarus/FPC concerning the keyboard accelerators processing for some controls (for instance, for GroupBoxes): I guess it's difficult to say if they are bugs or (specific) features. I won't open the debate. Concerning the Find/Replace dialog taken as a sample, it's working correctly for me with the english version (Windows XP SP3 - Win32 Lazarus 1.2.4/ FPC 2.6.4). And it's also working with RadioGroups. It's another matter for the french version of the Find/Replace dialog, as too many letters are used for different controls (see capture; letter 'R' is used 3 times for instance). This could sometime falsely lead users think that the keyboard accelerator is not processed. I guess the differences found (for the common english version, I mean) with the different users could eventually be relative to Windows versions and/or Windows used themes. ---------------------------------------------------------------------- rvk · 2014-08-02 14:25 Quote from: rvk on August 02, 2014, 12:15:46 pmIt gets even weirder... At home my radiogroup doesn't even react to accelerated keys at all (only with a bleep) Ok, scratch that. It's working again (although i don't know why, I think the choice did get focus but i couldn't see the dotted focus- lines around the focused choice because tab did get me to the next control). However, the behavior for RadioGroup accelerators is not exactly standard in Lazarus (at least for Windows-OS). When pressing an accelerator for a choice in a RadioGroup the choice gets focus but does not get selected. Other programs in Windows do select the selected choice of a RadioGroup-item (besides giving it focus). Because i don't know what the standard behavior is under Linux (for RadioGroups-items) i'm also not calling this a bug (yet). Quote from: ChrisF on August 02, 2014, 03:44:38 pmThere are a few differences between Delphi and Lazarus/FPC concerning the keyboard accelerators processing for some controls (for instance, for GroupBoxes): I guess it's difficult to say if they are bugs or (specific) features. I won't open the debate. @ChrisF: If i press Alt+e in your example, "From beginning" does not get selected for me. It does get focus but i have to press space to select it. How is that for you? If it doesn't get selected with you, don't you call that a bug? ---------------------------------------------------------------------- ChrisF · 2014-08-02 14:57 @rvk: No, my own version of Lazarus doesn't react as yours concerning this trouble. But we don't have the same version of Windows: is it a possible explanation ? For any kind of radiobutton (even when located inside a radiogroup control), when the corresponding "target" (i.e. the radiobutton with the corresponding keyboard accelerator inside its caption) is reached, it's both selected AND checked. BTW, your specific (?) trouble is probably the reason of your former results for radiobutton/radiogroup. As a complement to what has been explained above concerning UI, keyboard indicators like focus rectangles are displayed only after having pressed once any tabulation keys (tab, shift-tab, arrow keys ...). I guessed it was not the case during your first tests. And as for these controls, only the focusing is changed in your case, it seems to you that there is no effect at all. Pressing a tabulation key should correct it (but doesn't solve your "not-checked" trouble). Please note that these kinds of test concerning UI (both for underlined characters and focus rectangles) could be tricky to make when done directly inside the IDE. AFAIR, the UI states of the IDE is "propagated" to the launched program. So it's preferable to do these kinds of test by directly launching the program outside the Lazarus IDE. ---------------------------------------------------------------------- howardpc · 2014-08-02 15:41 Apart from the radiobutton accelerator keys not functioning (apart from beeping) on some versions of Windows (which may be realted to theme as much as OS version), note that in the specific case of the IDE Find dialog there is a clash of accelerator key allocations. If "Replace with" is unchecked there are two "f" accelerators (From cursor, Find button). If "Replace with" is checked there are two "r" accelerators (Replace with, Replace button). Probably the dialog got extended or redesigned at some point and these clashes were overlooked. ---------------------------------------------------------------------- typo · 2014-08-02 17:46 Yes, there is a lot of overlapped letters on dialog, only the first one is accessible. ---------------------------------------------------------------------- ChrisF · 2014-08-04 19:14 I think I've found a starting point explaining (a part of) the differences between our different results concerning the keyboard accelerators trouble: working, not working. Please, have a look at this bug report: http://bugs.freepascal.org/view.php?id=26562 Feel free to comment and/or add your own test results. ---------------------------------------------------------------------- BrunoK · 2014-08-05 09:38 Back to my previous post, the request for information about : OS         / Version                 / Lazarus        /  Desktop      / Keyboard Windows / XP Pro 32 bit SP3 / 1.2.4             / Français [fr] / Français [Suisse] was not innocent. Having finally managed to install a lazarus (easy) on a reinstalled linux machine (debian+gtk2, well that installation didn't go so easy ...) I have done some tests. All the remarks above in the discussion are consistent with the behaviour of the Accelerator characters on various  Windows/LCL widget type's Summary OS / LCL widget type -> result : Win XP          / Win32/Win64     -> None works and beeps Windows 7   / Win32/Win64     -> According to  rvk on August 02, 2014, 12:15:46 pm                                                      windows 7 seems to behave like GTK2, see below. Linux            / Gtk                     -> Tested and works like I think it should work except it                                                      never beeps, at least on my machine, when there                                                       is no target for the Accelerator character. Windows      / Gtk                     -> >>>>>>>> Please can someone  test. <<<<<< QUESTIONS to rvk, Windows 7 : does it beep always when you do Alt+Valid_AccelChar (I think it shouldn't).  Does it beep always when you do Alt+INEXISTENT_AccelChar (I think it should).  Does TLabel.Caption.AccelTargetChar -> FocusControl ? How it works on GTK, except it never beeps. Tested with Linus/GTK/Laz 1.2.4/Fpc 2.6.4 & in TLabel and TLabel.FocusControl set goes to the FocusControl -> works if the Accel_char has no duplicate (in my test I have a CheckBox with the same Accel_char), probably handled in the Gtk LCL widget set. TRadioButton's and TCheckBox's -> does (handled within GTK) :   - if single target      -> set's the focus to the target and does a either a Toggle_ON, default action or Checked:=not Checked for a TCheckBox.   - more than one target -> set's the focus to the target but takes not action. The last 2 are logical because one wouldn't have a action automatically executed if there was a conflict. Since the Accelerators never worked in version of WIN/WIN up to and including XP, having duplicate targets for a single AccelChar, except for the really annoying beep, did not matter much. Nice to have guys around here willing to tackle that issue so Lazarus will not look amateruish in MS_Windows environment. For the rest, since LAZ 1.2, everything is so good that I stopped using my, quite old, versions of Delphi. Links you might follow : http://forum.lazarus.freepascal.org/index.php/topic,20249.msg116625.ht ml#msg116625 http://forum.lazarus.freepascal.org/index.php/topic,24475.msg147314.ht ml#msg147314 http://bugs.freepascal.org/view.php?id=26523 -> contains, maybe to aggressive, patches that work with MS_WIN/Win on Laz 1.2.4/FPC 2.6.4 (Reversed in my installation for testing purpose) and Laz 1.3/Fpc 2.7.1, fully functional but would need testing for different platforms. Something I haven't figured out is how to just set the focus on TRadioButton without Toggling when there are more than one AccelChar target, but I'll find way. ---------------------------------------------------------------------- howardpc · 2014-08-05 11:49 Quote from: BrunoK on August 05, 2014, 11:38:38 amSummary OS / LCL widget type -> result : ... Windows      / Gtk                     -> >>>>>>>> Please can someone  test. <<<<<< I presume you mean Windows     / Qt ...or some other OS/widget combination? ---------------------------------------------------------------------- rvk · 2014-08-05 12:21 Quote from: BrunoK on August 05, 2014, 11:38:38 amSomething I haven't figured out is how to just set the focus on TRadioButton without Toggling when there are more than one AccelChar target, but I'll find way. The TRadioButtons in a TRadioGroup behave like this for me, but even if the AccelChar is unique which is not right according to Windows- standards Quote from: BrunoK on August 05, 2014, 11:38:38 amQUESTIONS to rvk, Windows 7 : does it beep always when you do Alt+Valid_AccelChar (I think it shouldn't).  Does it beep always when you do Alt+INEXISTENT_AccelChar (I think it should).  Does TLabel.Caption.AccelTargetChar -> FocusControl ? Yes, every Alt_key (valid or not) bleeps. The Accelchar of a TLabel does set focus to the FocusControl of that TLabel. The problem i had on August 02, 2014, 12:15:46 pm is still there. But it's not that the focus doesn't go to that control (TRadioButton) but the focus-lines are not visible (sometimes). I can't put my finger on it but it does happen from time to time. This, however, is a separate problem from what we're discussing here (so you can ignore that for now). My testing now is this (consistently on 2 Windows 7 machines): Windows 7 pro 64bit, Lazarus 1.2.4 r45510 FPC 2.6.4 i386-win32-win32/win64 (Language English Keyboard US) *) All Alt + keys (valid or not) produce a bleep. (So the bleep is a bug when it comes to valid accelchars)          (probably a missing key := 0 when handled somewhere is my delphi experience) *) Pressing the accelchar for TCheckbox checks the box and sets focus on the box. (correct behavior) *) Pressing the accelchar for TRadioButton DOES NOT check the circle (select), but does set the focus on the RadioButton. (incorrect behavior for it should select the circle) *) The TCheckbox and TRadioButton within the TRadioGroup and TCheckGroup behave the same as their counterparts outside it. *) Pressing the accelchar for TLabel does give control to the FocusControl of the TLabel (again with bleep but behavior is correct) *) Pressing the accelchar for TButton does activate the onclick but does not set focus to the button. (correct) The only problem here, which isn't Windows-behavior, is that the TRadioButtons should get selected with the accelchar. Now you would need to press the space-bar to select the choice you already made with the accelchar. ---------------------------------------------------------------------- ChrisF · 2014-08-05 12:47 Quote from: rvk on August 05, 2014, 02:21:36 pmThe problem i had on August 02, 2014, 12:15:46 pm is still there. But it's not that the focus doesn't go to that control (TRadioButton) but the focus-lines are not visible (sometimes). I can't put my finger on it but it does happen from time to time. This, however, is a separate problem from what we're discussing here (so you can ignore that for now). Have you tried what I've suggested before ? When it happens, press the tabulation key (for instance) and try again: you should now see the focus rectangle. **Edit** Quote from: rvk on August 05, 2014, 02:21:36 pm*) All Alt + keys (valid or not) produce a bleep. (So the bleep is a bug when it comes to valid accelchars)  (probably a missing key := 0 when handled somewhere is my delphi experience) As explained in bug 19223, the beep is coming from the menu handler. A MNC_IGNORE value is returned by default to the received WM_MENUCHAR message, when no menu corresponds to the given mnemonic (whichever are the result for the controls themselves). And this value provokes a beep: see http://msdn.microsoft.com/en- us/library/windows/desktop/ms646349%28v=vs.85%29.aspx . ---------------------------------------------------------------------- rvk · 2014-08-05 13:06 Quote from: ChrisF on August 05, 2014, 02:47:10 pmQuote from: rvk on August 05, 2014, 02:21:36 pmThe problem i had on August 02, 2014, 12:15:46 pm is still there. But it's not that the focus doesn't go to that control (TRadioButton) but the focus-lines are not visible (sometimes). I can't put my finger on it but it does happen from time to time. This, however, is a separate problem from what we're discussing here (so you can ignore that for now). Have you tried what I've suggested before ? When it happens, press the tabulation key (for instance) and try again: you should now see the focus rectangle. Yes, with some 'tabbing' around i get the focus rectangle back. But it shouldn't loose that rectangle. I can consistently see now that when starting my app there is no focused control (which is correct because there is none set) but when using an accelchar it should set focus on the control of that accelchar. (The focus does shift to the control but i can't see it because there is no focus rectangle.) It's just like the focus rectangle only becomes visible after doing some tabbing. After that the focus rectangle usually stays visible (only once in a while i lost it again but i can't reproduce this consistently). (So there is some inconsistency with the focus rectangle. But that's a different problem from the accelchar-behavior) ---------------------------------------------------------------------- ChrisF · 2014-08-05 13:17 @rvk: As far as I understand your latest description, this is the normal behavior for Windows since Windows 2000. When you start a program: -no mnemonic letters in the caption of the controls are underlined: you'll have to press 'Alt' to see them appeared, -no focus rectangle is visible: you'll have to press a (tab,shift- tab,right,left,top,down) key first to see them. As a consequence, Alt+letter does NOT make the focus rectangle visible. Remember that making these tests within the IDE can lead to obtain false results. **Edit** Theoretically, the control which can focus and have the lowest taborder value in the group is focused when you start your program: just press the 'space' key to see it activated. But: -if the focus for the control is represented by a focus rectangle (checkbox for instance), you won't see it (see my former comment), -a radiobutton is not focused if it's not checked. Which is also true for the tabulation process: only the checked radiobutton in the group can receive the focus with the tab/shift-tab keys. If none are selected, none can receive it. You'll have to click on it, or use the arrow keys (rigth,left,down,up), or access it true accelerator (which is not working for you). Anyway, as you said, this is not the real problem concerning keyboard accelerators . ---------------------------------------------------------------------- rvk · 2014-08-05 13:49 Quote from: ChrisF on August 05, 2014, 03:17:46 pm-no mnemonic letters in the caption of the controls are underlined: you'll have to press 'Alt' to see them appeared, I do know that. Quote from: ChrisF on August 05, 2014, 03:17:46 pm-no focus rectangle is visible: you'll have to press a (tab,shift-tab,right,left,top,down) key first to see them. Yes, but pressing an Alt+key should ALSO focus that control with the focus rectangle. And that's not whats happening. I made a test-program here with ActiveControl of the form1 at a TCheckbox and when starting the program (outside the ide) there is no visible focus-rectangle. (just as if the focus rectangle isn't initialized). All the Alt+key's don't give me the focus-rectangle. Only when pressing a tab the focus rectangle appears. After that the focus rectangle shifts according to the focused control. How do i get a focus rectangle around my TCheckbox if that's the control i want my program to have control when starting that program? (I can't see what control has focus like this when starting a program and would always need to do a tab, an Alt+key doesn't work) (In the IDE it works correctly with the Find- and Print-dialog, there the Alt+key does give the correct focus rectangle directly) Even if i make a TEdit on my form my first control and press Alt+C (for the TCheckBox) the TCheckbox doesn't get the focus rectangle (but does get focus) which is very confusing. (other program's do provide direct focus rectangle) But for now i'll leave it like it is until i can browse the bugtracker for similar problems (and it seems off-topic for this discussion  ) ---------------------------------------------------------------------- ChrisF · 2014-08-05 14:46 Well, it's not completely off-topic as it can help some other people to interpret more precisely their own results concerning the keyboard accelerators issues. So, let's say just for the fun... Quote from: rvk on August 05, 2014, 03:49:46 pmHow do i get a focus rectangle around my TCheckbox if that's the control i want my program to have control when starting that program? I'm afraid you'll have to force Windows to show the focus rectangle by yourself. The LCL is hiding them by default (conformed to Windows standards). Extract of win32wsforms.pp, in TWin32WSCustomForm.CreateHandle: Code: [Select]  // Beginning with Windows 2000 the UI in an application may hide focus   // rectangles and accelerator key indication. According to msdn we need to   // initialize all root windows with this message   if WindowsVersion >= wv2000 then     Windows.SendMessage(Result, WM_CHANGEUISTATE,       MakeWParam(UIS_INITIALIZE, UISF_HIDEFOCUS or UISF_HIDEACCEL), 0) Here is one possible solution (see attached project). Extract: Code: [Select]uses   Windows, Win32proc; var   ClearUI_HideFocus_Done: boolean = false; procedure TForm1.FormActivate(Sender: TObject); begin   if not ClearUI_HideFocus_Done then     begin       if WindowsVersion >= wv2000 then         SendMessage(Application.MainForm.Handle, WM_CHANGEUISTATE, MakeLong(UIS_CLEAR, UISF_HIDEFOCUS), 0);       ClearUI_HideFocus_Done := true;     end; end; Eventually, you may also try to send an expected keyboard value to the form but I'm not sure it's working, and if it's working it'll change the control with the focus of course. ---------------------------------------------------------------------- ChrisF · 2014-08-05 15:10 Quote from: BrunoK on August 05, 2014, 11:38:38 amSummary OS / LCL widget type -> result : Win XP          / Win32/Win64     -> None works and beeps ... Since the Accelerators never worked in version of WIN/WIN up to and including XP, having duplicate targets for a single AccelChar, except for the really annoying beep, did not matter much. Not for me. As stated into my bug report (26562), on my own Windows XP configuration, IDE+LCL is working properly if the LCL has not been compiled with the '-O2' option. The current version of Lazarus (i.e. 2.6.4) directly downloaded and installed without any modification is working properly. I'm not talking of the beep issue; this one is present for everybody and every Windows versions. If I'm recompiling Lazarus with the '-O2' (let's say with the standard Optimized "IDE" profile, which includes this option) keyboard accelerators are no more working. ---------------------------------------------------------------------- rvk · 2014-08-05 15:17 Quote from: ChrisF on August 05, 2014, 04:46:55 pmI'm afraid you'll have to force Windows to show the focus rectangle by yourself. The LCL is hiding them by default (conformed to Windows standards).Alright... That works. When using the sendmessage in the FormActivate it directly shows the rectangle. (Do you have a source for the fact Windows should hide the focus rectangle at startup of a program/dialog?) I could accept (if the Windows-standard is to hide it) that the rectangle isn't visible when staring your program/dialog. But it should re-enable the focus rectangle when using the accelerator keys (the same behavior as for TAB). When entering a dialog you don't have a rectangle and if you press Alt+F for example a checkbox does get checked but you don't see what the focus is after that. Even worse, with the problem of the TRadiobutton not being selected, when using the accelchar for a TRadiobutton you loose visible focus entirely (and you wouldn't even know that you could/need press space to activate it). I've never seen a dialog in other program where that happens. They always re-enable the focus-rectangle on accelerate keys. But at least i know now how to fix half the focus rectangle problem (at startup). Now we need to add the sendmessage-code to the accelchar-code, if it's confirmed that that should be default behavior. Edit: Just tested this on Windows XP and there the selection of the TRadioButtons work correctly. Even the focus rectangle works correctly and works right away. (I did confirm compiling Lazarus with -O2 disables the shortkeys). But i found another problem. When compiling a program with Windows 7 and running it under Windows XP the accelerate keys don't work at all. (haven't tested it with the patches yet) Hurray for all the different versions of one OS ---------------------------------------------------------------------- BrunoK · 2014-08-05 15:29 @howardpc I may try to convert the 'aggressive' but working patches, to maybe an installable and more limited packet to handle the situation. I don't know anything about what combination with Qt would be but am interested in the behaviour of any of the various : OS         / Version                 / Lazarus        /LCL TYPE (new)  /  Desktop      / Keyboard combinations. Desktop and Keyboard do not look not really important now. @ChrisF on WinXP The control in its WndProc first receives a LM_SYSCHAR that after not having (I think rightly, so other actions can override the default treatment) been processed in the concerned TWinControl descendent is translated somewhere (I don't remember where)  to a LN_SYSCHAR that is send (notified) to the WndProc. In the 'aggressive' patches I submitted, that initiates the scan (in TabOrder) of all potential targets. If the user application active form has effectively processed the LM_SYSCHAR it must set the Message.result to 1 (processed). >>> If Message.result is 0 <<<, then its the APPLICATION MENU that will look if it can do something with it and if Message.result is still 0 then Windows will beep. In standard MS_win applications, it is first the ActiveControl that is asked to process the accel char and if unsuccessful the MAIN MENU. If you want to reach only the main menu you have to press and release Alt and the press the target char. That is the STANDARD. If you are courageous and have time, make a backup of the lcl directory, load from http://bugs.freepascal.org/view.php?id=26523 AccelChar.patch and modify the various lcl units. Then load and extract the udialogchar.zip to the lcl. It contains the unit udialogchar.pas unit that does the controlling of the hole operation. (Or do it in the reverse order and get a look at udialogchar.pas). This works for me both with Lazarus 1.2.4 and 1.3, but I must recognize I work on an old XP duck so I wouldn't know how it works on the newer race machines. It is 'aggressive' because it also handles Accel Char's on Tab's.Titles, TCustomGrid.Columns[].Title, TCustomGroup.Caption, TLabel.Caption, TLabeledEdit.EditLabel.Caption. The logic applied is the same as GTK, just more aggressive. Since I had problems with the RadioButton in groups, and when they are not the single target, I chose to set the focus to the active RadioButton in the group. When a TCustomTabControl has the focus or when in a TCustomGroup, pressing the AccelChar target WITHOUT Alt just sets the correct Tab or, for RadioButton, toggles it. I'll see if I can do something installable as a package and submit it here, but suspect it will defeat the linker's dead code elimination. As for the test form I used, see these three messy screen captures. Anything that has an Accel Char is reachable in a consistent way. These are not good examples to follow ... Key to avoid : those requiring shift beaus it is easy to involuntarily switch the keyboard layout. By the way, NoHideFocus.prj -> has no effect on my Win XP-Pro machine. ---------------------------------------------------------------------- ChrisF · 2014-08-05 17:46 @rvk: Well, if I've correctly understood it, the standard is not to hide the focus rectangle (and the underlined letters too) by default, when starting. In fact, it's : "when starting, do as it is configured for the current user". And by default, Windows configurations do include these 2 hidings. This behavior can be change directly by the user in: Control Panel, under Appearance, Effects, option "Hide underlined letters for keyboard navigation until I press the Alt key". Please note that this option is in fact common to the 2 sorts of hiding, though it's mentioning only one of them. You can make a few tests by yourself by modifying this option. The LCL is quite respecting the user option (well, at least for me): hidden when starting if this option is checked, not hidden (both for underlined letters and focus rectangle) in the other case. And this is quite conform to any Windows program behavior. Attached, one of my small sample programs I've quickly modified to see the effect of this option on a "standard" Windows program when it starts. As this program is not using the LCL at all (it's using directly the Windows DialogBox API) and as it doesn't modify any UI state by itself, I consider it could be a sort of "reference" of what is expected for a "standard" Windows program concerning these 2 points (underlined letters + focus rectangle when starting). The results are identical as those for the LCL. However, I've noticed one difference between the LCL and the "direct" Windows DialogBox. When the option is checked (i.e. both hidden when starting), if you press the ALT key: -for the LCL, only the underlined letters become visible; focus rectangle are not affected, -for the Windows DialogBox, both of them become visible. The second version is more logical, as you stated. But on the opposite, the first one is compatible with Delphi (at least with my own old version of Delphi). So, which one is better ? I guess the answer won't be the same one for everybody. A few links concerning your question about the focus rectangle visibility (the second one is the more interesting one; I've already included it in one of my former posts): http://msdn.microsoft.com/en- us/library/ms646335%28VS.85%29.aspx#_win32_UI_State http://blogs.msdn.com/b/oldnewthing/archive/2005/05/03/414317.aspx @BrunoK: I couldn't remember the exact order of the different Windows events (and consecutive LCL processes) when a key is pressed; that's why I've not included any more precisions about them in my comment. And you are quite right: if the focused control/form processes this keyboard event first, effectively it's quite possible in the message result (i.e. WM_SYSCHAR->LM_SYSCHAR) to tell Windows that the message has already been processed. I'm just a bit surprised it's not already the case in the LCL: when a corresponding mnemonic (Alt+Char) has been found and is valid, I mean. I've discovered lastly your own bug report; though I've not looked deeply into your code. Briefly, what his the main idea ? LZDialogChar replaces the current DialogChar method: with a specific method (i.e. overidden) for each kind of control ? Concerning your own NoHideFocus test (just another test result difference; great), which result do you get: no focus visible at all ? Never ? **Edit1** After having looked at the LCL source code again, it seems that the control mnemonics are processed in the DialogChar(var Message: TLMKey) method indeed. I guess this one is called after the menu handler, and that's why it's too late for the beep. Or ... **Edit2** @rvk: So, apparently there is definitely something different between Windows XP and Windows 7 (and probably all 8.x) concerning this issue. ---------------------------------------------------------------------- rvk · 2014-08-05 18:15 Quote from: ChrisF on August 05, 2014, 07:46:30 pmThis behavior can be change directly by the user in: Control Panel, under Appearance, Effects, option "Hide underlined letters for keyboard navigation until I press the Alt key". Yes... that works... (finaly found that option under the "Ease of access", "Make the keyboard easier to use"). It indeed determines the behavior and Lazarus correctly respects that setting. But... from your link: QuoteUnderlines are hidden until you press the Alt key, and focus rectangles are hidden until you either press the Alt key or press the Tab key. And that's where Lazarus goes wrong on Windows 7 (Windows XP it works correctly). It does not re-enable the focus rectangle when pressing the Alt. Quote from: ChrisF on August 05, 2014, 07:46:30 pmHowever, I've noticed one difference between the LCL and the "direct" Windows DialogBox. When the option is checked (i.e. both hidden when starting), if you press the ALT key: -for the LCL, only the underlined letters become visible; focus rectangle are not affected, -for the Windows DialogBox, both of them become visible. The second version is more logical, as you stated. But on the opposite, the first one is compatible with Delphi (at least with my own old version of Delphi). So, which one is better ? I guess the answer won't be the same one for everybody. Exactly what my point was. With Windows XP it behaves like the Windows DialogBox (both rectangle and underline become visible). I've never seen the other (LCL) behavior with Delphi (although i can't check right now). But every other Windows program (including Wordpad etc..) behaves like option 2 (Both become visible when Alt is pressed). (haven't tested this on Windows 8 yet.) ---------------------------------------------------------------------- ChrisF · 2014-08-06 16:13 Quote from: rvk on August 05, 2014, 08:15:18 pmQuoteUnderlines are hidden until you press the Alt key, and focus rectangles are hidden until you either press the Alt key or press the Tab key. And that's where Lazarus goes wrong on Windows 7 (Windows XP it works correctly). It does not re-enable the focus rectangle when pressing the Alt. For me, it's not working neither with Windows XP: with my own Windows XP configuration, both Lazarus and Delphi don't make the focus rectangle visible when pressing Alt. Which is quite comprehensive if you look at the concerned code. Lazarus 2.4.2 (in win32callback.inc) Code: [Select] procedure UpdateUIState(CharCode: Word); ...     case CharCode of       VK_LEFT..VK_DOWN, VK_TAB:         begin           ParentForm := FindParentForm;           if ParentForm <> nil then             SendMessage(ParentForm.Handle, WM_CHANGEUISTATE, MakeLong(UIS_CLEAR, UISF_HIDEFOCUS), 0);         end;       VK_MENU:         begin           ParentForm := FindParentForm;           if ParentForm <> nil then             SendMessage(ParentForm.Handle, WM_CHANGEUISTATE, MakeLong(UIS_CLEAR, UISF_HIDEACCEL), 0);         end; Delphi 7 (in Controls.pas) : Code: [Select]procedure TWinControl.UpdateUIState(CharCode: Word); var   Form: TCustomForm; begin   Form := GetParentForm(Self);   if Assigned(Form) then     case CharCode of       VK_LEFT..VK_DOWN, VK_TAB:         Form.Perform(WM_CHANGEUISTATE, MakeLong(UIS_CLEAR, UISF_HIDEFOCUS), 0);       VK_MENU:         Form.Perform(WM_CHANGEUISTATE, MakeLong(UIS_CLEAR, UISF_HIDEACCEL), 0);     end; end; Only one of the UI state is modified each time, depending of the keyboard key pressed. As you said, standard Windows DialogBox proceeds differently with the 'ALT' key; but at least Lazarus is "conformed" with Delphi. ---------------------------------------------------------------------- rvk · 2014-08-06 22:05 Quote from: ChrisF on August 06, 2014, 06:13:25 pmAs you said, standard Windows DialogBox proceeds differently with the 'ALT' key; but at least Lazarus is "conformed" with Delphi. You're absolutely correct. But is it a good thing Lazarus is following Delphi on this point and not the standard Windows behavior?. If i look at code from VB they reset both IDEFOCUS and HIDEACCEL on the Alt-key. I also found the following code from JVCL (in JvExForms.pas for TJvExCustomForm): Code: [Select]procedure TJvExCustomForm.CMDialogKey(var Msg: TCMDialogKey); begin   case Msg.CharCode of     VK_LEFT..VK_DOWN, VK_TAB:       SendMessage(Handle, WM_CHANGEUISTATE, MakeLong(UIS_CLEAR, UISF_HIDEFOCUS), 0);     VK_MENU:       SendMessage(Handle, WM_CHANGEUISTATE, MakeLong(UIS_CLEAR, UISF_HIDEFOCUS or UISF_HIDEACCEL), 0);   end;   inherited; end; So... yeah... TJvExCustomForm has implemented it, like i would expect (with both resetting HIDEFOCUS and HIDEACCEL). So it's just Delphi and Lazarus which behave differently. (Like i said before, I've never seen a Windows-program behave like Delphi/Lazarus do on this point) But at least we now know what the issue is (and if need be, i could correct this for myself). ---------------------------------------------------------------------- Walmir · 2014-08-12 17:34 If I have a "File" menu with an "F" accelerator key in a main form and open a modal form with a button that has the same "F" accelerator, nothing happens when pressing ALT+F in tthe modal form It seems that Lazarus is considering that a naccelerator clash, but it should not be so as long as I am in a modal form. Someone else can confirm this behavior? Lazarus 1.2.4 Windows 7 ---------------------------------------------------------------------- rvk · 2014-08-12 17:51 Quote from: Walmir on August 12, 2014, 07:34:55 pmSomeone else can confirm this behavior? Opposite confirmed. Here it works correctly. Do you have a complex form again? Try it with just a mainform with menu &File which does a showmessage and a button to open a second form. And a second form with one button &Form which does a showmessage. It works correctly. Interesting enough when doing a .Show (instead of a .Showmodal) and focus on the second form opened both events are executed and i don't get a beep. So when doing a .Show and there is a clash in accelerator keys, the accelerator of the mainmenu will also run without a beep. When doing a .Showmodal i get a beep on that form and the event is executed. (maybe that's where the beep comes from, from a missing mainmenu ) ---------------------------------------------------------------------- ChrisF · 2014-08-12 21:13 The beep is coming from the menu handler (i.e. the part of the code which is responsible of finding a corresponding main menu entry for a mnemonic). Basically, here is the current (improper) process for a mnemonic (i.e. WM_SYSCHAR/WM_MENUCHAR messages): Code: [Select]call menuhandler(mnemonic)    if valid main menu entry for the mnemonic       call the corresponding main menu entry    else       beep     call formcontromhandler(mnemonic)    if valid control for the mnemonic       call the valid control    else       do nothing     While the correct process should be instead (to comply with standard Windows rules): Code: [Select]call formcontromhandler(mnemonic)    if valid control for the mnemonic       call the valid control    else       call menuhandler(mnemonic)          if valid main menu entry for the mnemonic             call the corresponding main menu entry          else             beep   I've not included here the additional bug, which is the reason why the formcontromhandler is not always called. Details of both bugs (i.e. beep then accelerator not processed) can be found in this bug report: http://bugs.freepascal.org/view.php?id=26562