Hello,
This is a tricky, and surprising, one. Might be a windows design hole.
Tested under Windows 2000 SP1.
The application have a accelarator (F6 or TAB) to switch pane focus. By example, it is used in a file browser where the focus have to switch between a tree control (displaying directories) and a list control (displaying files). To implement this I wrote :
afx_msg void OnNextPane();
afx_msg void OnPreviousPane();
afx_msg void OnUpdateNextPane(CCmdUI* pCmdUI);
afx_msg void OnUpdatePreviousPane(CCmdUI* pCmdUI);
Methods for both tree and list, with in the message map :
ON_COMMAND(ID_NEXT_PANE,OnNextPane)
ON_COMMAND(ID_PREV_PANE,OnPreviousPane)
ON_UPDATE_COMMAND_UI(ID_NEXT_PANE, OnUpdateNextPane)
ON_UPDATE_COMMAND_UI(ID_PREV_PANE, OnUpdatePreviousPane)
And in the accelerator table you have :
ID_NEXT_PANE VK_F6
ID_NEXT_PANE VK_TAB
ID_PREV_PANE Shift + VK_F6
ID_PREV_PANE Shift + VK_TAB
OnUpdate basically enable the command everytime because there is no reason to disable this. On*Pane will get a pointer to the tree or the list depending if 'this' is the tree or the list, and call ->SetFocus() with this pointer.
The Focus is 'correctly' changed, eg., the highligth of tree and list selected items change, and the arrow key stroke goes to the correct view, *but*, accelerator calls still go to the previously activated view.
A simple example is, if you have the tree activated and select some directory, then use the accelerator tab to switch the focus to the list, select and item within the list and press F2 (accelerator for edit), then the item which *should* be edited is the item of the list, *but*, the accelerator of the tree control derived class is called instead, thus you edit the directory selected in the tree.
I try to add a call to ->SetActiveWindow() after the ->SetFocus() call, but this doesn't help. I also add assertion check on this->GetFocus() and this->GetActiveWindow(), and see that the focus changed but not the active window (?!).
Documentation about accelerator 'focus' is welcome, I found nothing in MSDN. Workaround also wellcome of course.
Nasty bug, no ? David Burg,
Ahead Software AG
This is a tricky, and surprising, one. Might be a windows design hole.
Tested under Windows 2000 SP1.
The application have a accelarator (F6 or TAB) to switch pane focus. By example, it is used in a file browser where the focus have to switch between a tree control (displaying directories) and a list control (displaying files). To implement this I wrote :
afx_msg void OnNextPane();
afx_msg void OnPreviousPane();
afx_msg void OnUpdateNextPane(CCmdUI* pCmdUI);
afx_msg void OnUpdatePreviousPane(CCmdUI* pCmdUI);
Methods for both tree and list, with in the message map :
ON_COMMAND(ID_NEXT_PANE,OnNextPane)
ON_COMMAND(ID_PREV_PANE,OnPreviousPane)
ON_UPDATE_COMMAND_UI(ID_NEXT_PANE, OnUpdateNextPane)
ON_UPDATE_COMMAND_UI(ID_PREV_PANE, OnUpdatePreviousPane)
And in the accelerator table you have :
ID_NEXT_PANE VK_F6
ID_NEXT_PANE VK_TAB
ID_PREV_PANE Shift + VK_F6
ID_PREV_PANE Shift + VK_TAB
OnUpdate basically enable the command everytime because there is no reason to disable this. On*Pane will get a pointer to the tree or the list depending if 'this' is the tree or the list, and call ->SetFocus() with this pointer.
The Focus is 'correctly' changed, eg., the highligth of tree and list selected items change, and the arrow key stroke goes to the correct view, *but*, accelerator calls still go to the previously activated view.
A simple example is, if you have the tree activated and select some directory, then use the accelerator tab to switch the focus to the list, select and item within the list and press F2 (accelerator for edit), then the item which *should* be edited is the item of the list, *but*, the accelerator of the tree control derived class is called instead, thus you edit the directory selected in the tree.
I try to add a call to ->SetActiveWindow() after the ->SetFocus() call, but this doesn't help. I also add assertion check on this->GetFocus() and this->GetActiveWindow(), and see that the focus changed but not the active window (?!).
Documentation about accelerator 'focus' is welcome, I found nothing in MSDN. Workaround also wellcome of course.
Nasty bug, no ? David Burg,
Ahead Software AG