Tab key doesn't work right
-
Using Visual C++ 6, service pack 6 on XP. I have a set of COlePropertyPages controlled by an OCX embedded in a dialog box. On one property page I have 10 edit controls. I want the user to be able to jump from control to control using the Tab button. However, when the focus is in a control and the user hits the tab button, the focus jumps to the OK button in the dialog box. From that point on, repeatedly pressing the Tab button merely jumps between the Help, OK, and Cancel buttons on the dialog box. Trapping the WM_KEYDOWN message in the property page doesn't help, the code isn't reached. I tried subclassing one of the edit controls. Even when that edit control has the focus, and the Tab button is pressed, the WM_KEYDOWN message isn't reached. I tried using PreTranslateMessage() in the subclass, the code isn't reached (I tested all these using a break point.) How can I make it so that the Tab button jumps from edit control to edit control? Thanks!
-
Using Visual C++ 6, service pack 6 on XP. I have a set of COlePropertyPages controlled by an OCX embedded in a dialog box. On one property page I have 10 edit controls. I want the user to be able to jump from control to control using the Tab button. However, when the focus is in a control and the user hits the tab button, the focus jumps to the OK button in the dialog box. From that point on, repeatedly pressing the Tab button merely jumps between the Help, OK, and Cancel buttons on the dialog box. Trapping the WM_KEYDOWN message in the property page doesn't help, the code isn't reached. I tried subclassing one of the edit controls. Even when that edit control has the focus, and the Tab button is pressed, the WM_KEYDOWN message isn't reached. I tried using PreTranslateMessage() in the subclass, the code isn't reached (I tested all these using a break point.) How can I make it so that the Tab button jumps from edit control to edit control? Thanks!
There should be two ways of fixing this. One way is to go to Layout -- Tab Order. This will show all of the controls in the dialog in numerical order. To change them you just click the order in which they are to be tabbed through. Then, if some of the controls are not being tabbed to and you want them enabled, go into the resource's properties and set the Tab Stop property to true. Secondly, you can directly modify the resource file (*.rc) by moving the resources within the dialog. The order in which they are scripted is their tab stop order. Setting WS_TABSTOP as one of the controls properties identifies it as a resource to be tabbed to.
Josh Davis
This is what plays in my head when I finish projects. -
There should be two ways of fixing this. One way is to go to Layout -- Tab Order. This will show all of the controls in the dialog in numerical order. To change them you just click the order in which they are to be tabbed through. Then, if some of the controls are not being tabbed to and you want them enabled, go into the resource's properties and set the Tab Stop property to true. Secondly, you can directly modify the resource file (*.rc) by moving the resources within the dialog. The order in which they are scripted is their tab stop order. Setting WS_TABSTOP as one of the controls properties identifies it as a resource to be tabbed to.
Josh Davis
This is what plays in my head when I finish projects.Thanks for your efforts, Josh, but you don't seem to understand the question. As I mentioned, this case involves property pages embedded in the dialog box using an OCX. (Maybe the correct term is ActiveX control?) So there is an rc file for the property pages in the OCX and a separate rc file for the dialog box in my main program. The tab order for the property page in the OCX rc file is already set up to go from edit control to edit control. This tab order is ignored. No matter which one of the ten edit controls has the focus, pressing the tab button causes the focus to jump to the OK button in the dialog box. Clearly the tab order for the dialog box in the rc file of the main program is the one used by the system. In the rc file for the dialog box, there are the three buttons, OK, Help, Cancel and a Tab Control in which the OCX property pages are embedded. I can set the Tab Stop property of the Tab control to TRUE, then the tab button causes the focus to jump between the three button and the title tab of the property page open. But I don't know how to make the tab button jump between the edit controls as desired.
-
Using Visual C++ 6, service pack 6 on XP. I have a set of COlePropertyPages controlled by an OCX embedded in a dialog box. On one property page I have 10 edit controls. I want the user to be able to jump from control to control using the Tab button. However, when the focus is in a control and the user hits the tab button, the focus jumps to the OK button in the dialog box. From that point on, repeatedly pressing the Tab button merely jumps between the Help, OK, and Cancel buttons on the dialog box. Trapping the WM_KEYDOWN message in the property page doesn't help, the code isn't reached. I tried subclassing one of the edit controls. Even when that edit control has the focus, and the Tab button is pressed, the WM_KEYDOWN message isn't reached. I tried using PreTranslateMessage() in the subclass, the code isn't reached (I tested all these using a break point.) How can I make it so that the Tab button jumps from edit control to edit control? Thanks!
The tabbing magic handled by the IsDialogMessage[^] function; it sounds like this is being called correctly because the tab key does alter the focus. Read this[^] blog entry and the comments for some insight. To me it sounds like your problem may be related to the
DS_CONTROLandWS_EX_CONTROLPARENTstyles, see here[^] to learn more about these. EDIT: You may also want to read about the PSM_ISDIALOGMESSAGE[^] message since we're talking about property pages.Steve
modified on Wednesday, September 29, 2010 2:51 PM
-
The tabbing magic handled by the IsDialogMessage[^] function; it sounds like this is being called correctly because the tab key does alter the focus. Read this[^] blog entry and the comments for some insight. To me it sounds like your problem may be related to the
DS_CONTROLandWS_EX_CONTROLPARENTstyles, see here[^] to learn more about these. EDIT: You may also want to read about the PSM_ISDIALOGMESSAGE[^] message since we're talking about property pages.Steve
modified on Wednesday, September 29, 2010 2:51 PM
Thanks for your reply. Your references are to the point; although maybe not since none of them seem to apply to property pages embedded with an OCX. In the dialog box, I set the Tab Control to WS_EX_CONTROLPARENT with WS_TABSTOP, but it made no difference. The property pages are embedded in the Tab Control using CoCreateInstance to get a ISpecifyPropertyPages pointer, which is used to get a CAUUID, which is used to get an array of IPropertyPage pointers from more calls to CoCreateInstance, one for each property page. Probably what I need to do is trap the Tab message in the dialog box, then somehow see if the property page with the edit controls is open, see if the focus is in an edit control, and if it is, send the Tab message to the property page. I don't know how to do that yet, but your answer stimulated some thinking. It seems like a lot of work for an apparently simple task..
-
Thanks for your reply. Your references are to the point; although maybe not since none of them seem to apply to property pages embedded with an OCX. In the dialog box, I set the Tab Control to WS_EX_CONTROLPARENT with WS_TABSTOP, but it made no difference. The property pages are embedded in the Tab Control using CoCreateInstance to get a ISpecifyPropertyPages pointer, which is used to get a CAUUID, which is used to get an array of IPropertyPage pointers from more calls to CoCreateInstance, one for each property page. Probably what I need to do is trap the Tab message in the dialog box, then somehow see if the property page with the edit controls is open, see if the focus is in an edit control, and if it is, send the Tab message to the property page. I don't know how to do that yet, but your answer stimulated some thinking. It seems like a lot of work for an apparently simple task..