Hi Folks,
we have a TAdvMainMenu on a TAdvToolbar on a TAdvDockpanel. The Dockpanel is tied to a TAdvToolbarOfficeStyler with a corresponding TAdvMenuOfficeStyler. All menu entries are tied to actions in a TActionManager.
When VCL Styles are enabled with a custom style, the following strange things happen:
If you click on a menu entry with the mouse, the action is already triggered on the mouse down event and not when the mouse is released.
Keyboard navigation through the menu is broken. Example
Press Alt+F to select the file menu. Left or right arrow don't move to the next top menu entry.
Arrow up/down select the last/first entry in the File menu. Now it is possible to move left/right, but only once, because it looks like the focus gets lost.
If you move up/down again, you can move left/right afterwards.
If you leave the mouse hovering over the area where the menu would pop up if you press Alt+F, the menu highlight immediately moves to the mouse position. The mouse steals the cursor somehow!
all this only happens in the same application when custom VCL Styles are used
TStyleManager.TrySetStyle('Our Fancy Style'); -> strange things happen
TStyleManager.TrySetStyle('Windows'); -> Menu behaves as expected
This is not only unexpected behaviour, it also breaks our automated test system, because Keyboard navigation doesn't work.
Any ideas how we (or you) can solve this problem?
Just because it happened to me right now: Do you know that it is not funny to receive a "your session has expired" error after having written a lengthy post? :(
Regards
L?bbe
I have been unable to reproduce this.Perhaps there is something specific in your custom style. Can you isolate this and provide some sample source app with which we can reproduce this here?
Thanks for your reply. I can try to strip down my test application and send it to you
Any news on this subject using the test application that I sent you?
Is it possible that there is an interference with the vcl-styles-utils that are used by the application?
One problem (Menu trigger on mouse down) was indeed a problem of the vcl-styles-utils (https://github.com/RRUZ/vcl-styles-utils/issues/217) and could be solved by the hint given in github ticket.
Clearly,VCL styles itself breaks things. We have at this time not been able to find workarounds for issues actually broken by VCL styles itself.
Thanks for your reply. That's bad news for us.After my post yesterday I tried wih and without vcl-styles-utils and the problem persisted. So the culprit was either vcl-styles or tms adv mainmenu.
How exactly can this be reproduced without VCL styles? We are not aware of any issues when no VCL styles are used. Please provide a sample source project and exact steps for how to reproduce this here.
Sorry Mr. Fierens, I think that was a misunderstanding on your part. I wrote with/without vcl-styles-utils (by Rodrigo Ruz) above.
- VCL styles are required to trigger the problem. No VCL styles, no problem.
- vcl-styles-utis are used to fix some drawing problems when VCL Styles are active, but they don't trigger the keyboard navigation problem.
I understand then that the vcl-styles-utils (by Rodrigo Ruz) help (at least partially) solve the problem?
vcl-styles-utils make the main menu (and other components) pick up the vcl styles better, but they don't solve all of the drawing issues.
vcl-styles-utils don't have any influence on the keyboard navigation problem in the TMS AdvManMenu
I added a standard delphi main menu to my test application and left-right keyboard navigation between menu entries works there when styles are enabled
Left-right keyboard navigation doesn't work in the TMS menu on the same form when styles are enabled.
So I guess there is some kind of problem in the TMS menu concerning keyboard navigation when vcl-styles are enabled.
I will send you the updated test application via the support channel.