User (Old forums)MemberJanuary 23, 2008 at 4:04 pmPost count: 23064
I have an MDI application that uses a DockLayoutManager with two ToolWindows. When one of my MDI child forms is active, any time a focused control receives an “Enter” keypress, the ability to tab through the controls on the active form goes away. Instead, the DockLayoutManager creates a MDI child menu and the tab key cycles between the two ToolWindow options on the menu until I press the “Control” key, at which time that selected ToolWindow is made active and focus shifts to a control on said ToolWindow.
It doesn’t matter whether the control on the form is an Xceed control or a stock WinForm control. I can only surmise that the “Enter” keypress is being registered by the DockLayoutManager as a cue to open the ToolWindow menu. I can see how this would be useful feature but consider the following scenario which is expected by my users:
1) Enter input onto a textbox
2) Press the Enter key to start a process
3) Tab to the next input control
Instead of the next input control receiving focus, the DockLayoutManager menu pops up and will not go away until the user presses “Control” (which is not intuitive), or the user uses the mouse to give input to some control in the application (which means more mouse clicks). Even if the user makes the menu go away by clicking on a control, the “Tab” key will continue to open the menu until the user presses the “Control” key (very unintuitive considering the menu doesn’t have to be open).
Is it possible to suppress this functionality? I don’t think the users would benefit from having access to the menu, so I’d just as soon never let them see it. The only related property I found on DockLayoutManager was called “ShowMenuOnCtrlTab,” which doesn’t seem to have an effect on my problem. In fact, it doesn’t even seem to work as described because the “Control+Tab” combination still opens up the menu whether the property is true or false.
Am I missing something? Thanks for any help you can offer.
Xceed.DockingWindows.dll version: 2.0.7559.11410
Framework: .NET 2.0
Target OS: Windows XP
Imported from legacy forums. Posted by Christopher (had 6689 views)User (Old forums)MemberJanuary 25, 2008 at 2:31 pmPost count: 23064
We have fix another issue that most likely will also fix this issue. It will be available in our next service release, that should be out in the next couple weeks. You can monitor the following page to be informed when it is actually the case :
Imported from legacy forums. Posted by André (had 657 views)User (Old forums)MemberJanuary 31, 2008 at 5:44 pmPost count: 23064
Could you email me when this is fixed? It currently is causing my company to not release our software because of this undesired functionality.
Imported from legacy forums. Posted by hharris (had 632 views)User (Old forums)MemberFebruary 1, 2008 at 4:58 amPost count: 23064
Well, I have the same unexpected behavior. But it seems to be a problem not in DockLayoutManager related classes, rather in TabbedMdiManager,
Because, as I see, when ShowMenuOnCtrlTab is ON, any edits on any simple control cause window menu to crash. Also, when ShowMenuOnCtrlTab is OFF,
Ctrl+Tab combination is still working, changes over Mdi windows, but Active Mdi Tab Header remains unchanged 🙁
So, we cannot use TabbedMdiManager in any case!
PS: one more surprising ‘feature’: when setting ‘dockLayoutManager.ShowMenuOnCtrlTab = false’, it’s easily changed back to ‘true’ when moving any docked ToolWindow! 🙂
PPS: yet another problem: when starting app with some docked windows and the only Mdi window, Ctrl+Tab menu unexpectedly shows only that Mdi window in the list, and no one of docked windows.
All other windows appear to be listed in menu only after Mdi windows quantity became more than one.
Moreover, ‘Mdi Window’ submenu items are duplicated in ‘Docking Window’ submenu (as they are all ToolWindow instances?).
Imported from legacy forums. Posted by Serge (had 963 views)User (Old forums)MemberFebruary 1, 2008 at 6:48 amPost count: 23064
Sorry, I’ve forgotten about one more thing: imagine that there’re some floating windows opened in an application, and also some tabbed or docked windows.
First, set active one of docked or tabbed windows. Then set active any floating window, and close that floating window.
‘dockLayoutManager.ActiveToolWindow’ property became NULL. And now there’s the bug: mouse clicks on the LAST ACTIVE tabbed/docked window do not set ‘dockLayoutManager.ActiveToolWindow’ to appropriate value, the property remains NULL 🙁
Imported from legacy forums. Posted by Serge (had 7104 views)User (Old forums)MemberFebruary 12, 2008 at 4:44 pmPost count: 23064
Where is this update?????
Imported from legacy forums. Posted by hharris (had 902 views)User (Old forums)MemberFebruary 13, 2008 at 3:31 pmPost count: 23064
The release was postponed, but it should be out by the end of the month.
We apologize for the inconvenience.
Imported from legacy forums. Posted by André (had 690 views)
- You must be logged in to reply to this topic.