High-light state of button...
George Chow -- gchow@mercury.bc.ca
Tuesday, February 18, 1997
Environment: VC++ 4.00, Win 95
I have a problem with the high-light state of a CButton. I am using a =
modal dialog to edit a list of multi-attribute items. The users gets to =
specify where in the list to start at and he can step forward or =
backward in the list with Previous and Next buttons. My dialog contains =
various edit boxes, combo-boxes, grids et al that allows the user to =
edit one item. The dialog does *not* contain a default button.
The problem is this:
1. The user selects one item to edit and my dialog starts up. The user =
changes the values that need to.
2. He tabs to the Next buttons and hits return. My Next button's handler =
kick in and save the current item away and step to the next, filling in =
the new values and sets the focus back to the first field
3. The user edits this item
4. The user tabs to the Next button again and hits return. This time =
though, instead of my Next handler, the dialog is dismissed. I note here =
that when I tabbed into the Next button this second time around, the =
focus is on the button but the highlight state is not. I.e., I see the =
dashed rectangle around the caption of the button, in this case, the =
word Next, but there is no dark rectangle around the button itself. (I =
note that in this case, i can use the spacebar but I prefer to have =
something consistently available.)
What am I doing wrong here? Any pointers would be appreciated.
George
Arkady Elterman -- arkady@neca.com
Wednesday, February 19, 1997
I had a similar problem, and although I'm still confused as to what caused
it, I can suggest a workaround which worked for me.
On setting focus to your "Next" button call CDialog's
SetDefID(IDC_BUTTON_NEXT) to make the button the default one temporarily.
Then, on removing focus, call it again with a non-existing ID (0 probably).
Note that using SetDefID() is better than, say, ModifyStyleEx(0,
BS_DEFPUSHBUTTON) because ModifyStyleEx() will not set the extra black
border around the button, but SetDefID() will.
Arkady Elterman.
----------
From: George Chow
To: 'mfc-l@netcom.com'
Subject: High-light state of button...
Date: Tuesday, February 18, 1997 4:00 PM
Environment: VC++ 4.00, Win 95
I have a problem with the high-light state of a CButton. I am using a modal
dialog to edit a list of multi-attribute items. The users gets to specify
where in the list to start at and he can step forward or backward in the
list with Previous and Next buttons. My dialog contains various edit boxes,
combo-boxes, grids et al that allows the user to edit one item. The dialog
does *not* contain a default button.
The problem is this:
1. The user selects one item to edit and my dialog starts up. The user
changes the values that need to.
2. He tabs to the Next buttons and hits return. My Next button's handler
kick in and save the current item away and step to the next, filling in the
new values and sets the focus back to the first field
3. The user edits this item
4. The user tabs to the Next button again and hits return. This time
though, instead of my Next handler, the dialog is dismissed. I note here
that when I tabbed into the Next button this second time around, the focus
is on the button but the highlight state is not. I.e., I see the dashed
rectangle around the caption of the button, in this case, the word Next,
but there is no dark rectangle around the button itself. (I note that in
this case, i can use the spacebar but I prefer to have something
consistently available.)
What am I doing wrong here? Any pointers would be appreciated.
George
----------
petter.hesselberg -- petter.hesselberg@ac.com
Wednesday, February 19, 1997
[Mini-digest: 2 responses]
Read the chapter entitled "Dialog Box Keyboard Interface" in the Win32
Programmer's Reference. Most people think that the ENTER key activates the
default button, and that's the end of it. If there actually IS a default
button, ENTER will send a WM_COMMAND message with the identifier of that
button. If, on the other hand, there is NO default button, the WM_COMMAND
message will be sent anyway, with IDOK as the identifier. This hits the OnOK()
handler, which, if you haven't overridden it, will happily dismiss your dlg box.
As to why you don't get a default (fat) border consistently around your button
-- I don't known enough. But the previous paragraph certainly describes what
happens...
Regards,
Petter Hesselberg
Andersen Consulting, Oslo
___________________________________________________________________________________________________________________________________________________________________________________________________________________
To: mfc-l @ netcom.com ("'mfc-l@netcom.com'") @ internet
cc: (bcc: Petter Hesselberg)
From: gchow @ mercury.bc.ca (George Chow) @ internet
Date: 18-02-97 19:00
Subject: High-light state of button...
___________________________________________________________________________________________________________________________________________________________________________________________________________________
Environment: VC++ 4.00, Win 95
I have a problem with the high-light state of a CButton. I am using a modal
dialog to edit a list of multi-attribute items. The users gets to specify where
in the list to start at and he can step forward or backward in the list with
Previous and Next buttons. My dialog contains various edit boxes, combo-boxes,
grids et al that allows the user to edit one item. The dialog does *not*
contain a default button.
The problem is this:
1. The user selects one item to edit and my dialog starts up. The user changes
the values that need to.
2. He tabs to the Next buttons and hits return. My Next button's handler kick
in and save the current item away and step to the next, filling in the new
values and sets the focus back to the first field
3. The user edits this item
4. The user tabs to the Next button again and hits return. This time though,
instead of my Next handler, the dialog is dismissed. I note here that when I ta
bbed into the Next button this second time around, the focus is on the button
but the highlight state is not. I.e., I see the dashed rectangle around the
caption of the button, in this case, the word Next, but there is no dark
rectangle around the button itself. (I note that in this case, i can use the
spacebar but I prefer to have something consistently available.)
What am I doing wrong here? Any pointers would be appreciated.
George
-----From: "Dmitry A. Dulepov"
[Mailer: "Groupware E-Mail". Version 1.03.000]
> [From: George Chow
>Environment: VC++ 4.00, Win 95
>
>I have a problem with the high-light state of a CButton. I am using a modal dialog to edit a list of multi-attribute items. The users gets to specify where in the list to start at and he can step forward or backward in the list with Previous and Next buttons. My dialog contains various edit boxes, combo-boxes, grids et al that allows the user to edit one item. The dialog does *not* contain a default button.
>
>The problem is this:
>1. The user selects one item to edit and my dialog starts up. The user changes the values that need to.
>2. He tabs to the Next buttons and hits return. My Next button's handler kick in and save the current item away and step to the next, filling in the new values and sets the focus back to the first field
>3. The user edits this item
>4. The user tabs to the Next button again and hits return. This time though, instead of my Next handler, the dialog is dismissed. I note here that when I tabbed into the Next button this second time around, the focus is on the button but the highlight state is not. I.e., I see the dashed rectangle around the caption of the button, in this case, the word Next, but there is no dark rectangle around the button itself. (I note that in this case, i can use the spacebar but I prefer to have something consistently available.)
>
>What am I doing wrong here? Any pointers would be appreciated.
>
>George
It seems all is correct. What return code do you receive from DoModal() ? How can user stop working with your dialog ? Is there any EndDialog() calls in your code ?
Dmitry A. Dulepov
Samsung Electronics Co., Ltd.
Russian Research Center
Phone: +7 (095) 213-9207
Fax: +7 (095) 213-9196
E-mail: dima@src.samsung.ru
====================================
Arkady Elterman -- arkady@neca.com
Saturday, February 22, 1997
Unfortunately, Petter Hesselberg's message only explains why the dialog is
being dismissed -- because Windows sends WM_COMMAND message with IDOK
parameter to the dialog procedure. But it does not explain WHY it does so
even though the button has focus.
I wrote a simple dialog-based app which contains only a button and an a
eidt box.
No default button. The button's handler sets focus to the edit box (this
is important).
If I press Enter while on the button and then tab from the edit box back to
the button, I have that effect -- the button has focus but no heavy border,
and pressing Enter makes the dialog disappear.
I noticed that if I simply tab from control to control, the button has
BS_DEFPUSHBUTTON style after it gets focus, and BS_PUSHBUTTON after it
loses focus. However, BS_DEFPUSHBUTTON style is not removed properly in
the above scenario, that is, when the button's handler sets focus to the
edit box. If I do it myself by calling SetButtonStyle(BS_PUSHBUTTON) in
the same handler, the problem goes away.
Seems like a bug to me.
Arkady Elterman
arkady@neca.com
----------
: Read the chapter entitled "Dialog Box Keyboard Interface" in the Win32
: Programmer's Reference. Most people think that the ENTER key activates
the
: default button, and that's the end of it. If there actually IS a default
: button, ENTER will send a WM_COMMAND message with the identifier of that
: button. If, on the other hand, there is NO default button, the WM_COMMAND
: message will be sent anyway, with IDOK as the identifier. This hits the
OnOK()
: handler, which, if you haven't overridden it, will happily dismiss your
dlg box.
:
: As to why you don't get a default (fat) border consistently around your
button
: -- I don't known enough. But the previous paragraph certainly describes
what
: happens...
:
: Regards,
: Petter Hesselberg
: Andersen Consulting, Oslo
:
petter.hesselberg -- petter.hesselberg@ac.com
Monday, February 24, 1997
You didn't, by any chance, use SetFocus() in your button handler?
If you did, check out CDialog::GotoDlgCtrl(). It is defined as follows (in
afxwin2.inl):
_AFXWIN_INLINE void CDialog::GotoDlgCtrl(CWnd* pWndCtrl)
{ ASSERT(::IsWindow(m_hWnd)); ::SendMessage(m_hWnd,
WM_NEXTDLGCTL, (WPARAM)pWndCtrl->m_hWnd, 1L); }
Better yet, check out the WM_NEXTDLGCTL message, which actually explains the
issues involved. Also note that GotoDlgCtrl does a SendMessage, which may or
may not be a good thing. Here's part of the online docs:
"The effect of this message differs from that of the SetFocus function because
WM_NEXTDLGCTL modifies the border around the control.
Do not use the SendMessage function to send a WM_NEXTDLGCTL message if your
application will concurrently process other messages that set the focus. Use
the PostMessage function instead. "
(Any MFC insiders care to comment on that last one? Why SendMessage instead of
Postmessage?)
Regards,
Petter Hesselberg
Andersen Consulting, Oslo
___________________________________________________________________________________________________________________________________________________________________________________________________________________
To: mfc-l @ netcom.com @ internet
cc: (bcc: Petter Hesselberg)
From: arkady @ neca.com ("Arkady Elterman") @ internet (Mailed by: arkady @
neca.com ("Arkady Elterman") @ internet)
Date: 22-02-97 07:54
Subject: Re: High-light state of button...
___________________________________________________________________________________________________________________________________________________________________________________________________________________
Unfortunately, Petter Hesselberg's message only explains why the dialog is
being dismissed -- because Windows sends WM_COMMAND message with IDOK
parameter to the dialog procedure. But it does not explain WHY it does so
even though the button has focus.
I wrote a simple dialog-based app which contains only a button and an a
eidt box.
No default button. The button's handler sets focus to the edit box (this
is important).
If I press Enter while on the button and then tab from the edit box back to
the button, I have that effect -- the button has focus but no heavy border,
and pressing Enter makes the dialog disappear.
I noticed that if I simply tab from control to control, the button has
BS_DEFPUSHBUTTON style after it gets focus, and BS_PUSHBUTTON after it
loses focus. However, BS_DEFPUSHBUTTON style is not removed properly in
the above scenario, that is, when the button's handler sets focus to the
edit box. If I do it myself by calling SetButtonStyle(BS_PUSHBUTTON) in
the same handler, the problem goes away.
Seems like a bug to me.
Arkady Elterman
arkady@neca.com
----------
: Read the chapter entitled "Dialog Box Keyboard Interface" in the Win32
: Programmer's Reference. Most people think that the ENTER key activates
the
: default button, and that's the end of it. If there actually IS a default
: button, ENTER will send a WM_COMMAND message with the identifier of that
: button. If, on the other hand, there is NO default button, the WM_COMMAND
: message will be sent anyway, with IDOK as the identifier. This hits the
OnOK()
: handler, which, if you haven't overridden it, will happily dismiss your
dlg box.
:
: As to why you don't get a default (fat) border consistently around your
button
: -- I don't known enough. But the previous paragraph certainly describes
what
: happens...
:
: Regards,
: Petter Hesselberg
: Andersen Consulting, Oslo
:
Paul B -- Paul.B.Folbrecht@JCI.Com
Monday, February 24, 1997
You didn't, by any chance, use SetFocus() in your button handler?
If you did, check out CDialog::GotoDlgCtrl(). It is defined as follows
(in
afxwin2.inl):
_AFXWIN_INLINE void CDialog::GotoDlgCtrl(CWnd* pWndCtrl)
{ ASSERT(::IsWindow(m_hWnd)); ::SendMessage(m_hWnd,
WM_NEXTDLGCTL, (WPARAM)pWndCtrl->m_hWnd, 1L); }
Better yet, check out the WM_NEXTDLGCTL message, which actually
explains the
issues involved. Also note that GotoDlgCtrl does a SendMessage, which
may or
may not be a good thing. Here's part of the online docs:
"The effect of this message differs from that of the SetFocus function
because
WM_NEXTDLGCTL modifies the border around the control.
Do not use the SendMessage function to send a WM_NEXTDLGCTL message if
your
application will concurrently process other messages that set the
focus. Use
the PostMessage function instead. "
(Any MFC insiders care to comment on that last one? Why SendMessage
instead of
Postmessage?)
-------------------------------------------------------------------
Because SendMessage() calls the window proc directly (synchronously),
and anything you do might be undone from the message handler you
started it. PostMessage() puts a message in the queue that will be
processed sometime after the current business is finished.
-Paul Folbrecht
Compuware Corp.
petter.hesselberg -- petter.hesselberg@ac.com
Tuesday, February 25, 1997
I'm well aware of the difference between SendMessage and PostMessage.
My question was why MFC has chosen to implement CDialog::GotoDlgCtrl() using
SendMessage rather than PostMessage, even though the documentation of
WM_NEXTDLGCTL states that this may not be the safest thing to do. It is more
than conceivable that somebody might try to call GotoDlgCtrl from a SetFocus or
KillFocus handler, which would not be a terribly good idea.
I'm still curious.
Regards,
Petter.Hesselberg @ ac.com
_____________________________
To: mfc-l @ netcom.com @ internet
cc: (bcc: Petter Hesselberg)
From: Paul.B.Folbrecht @ JCI.Com @ internet
Date: 25-02-97 12:58
Subject: Re[2]: High-light state of button...
_____________________________
You didn't, by any chance, use SetFocus() in your button handler?
If you did, check out CDialog::GotoDlgCtrl(). It is defined as follows
(in
afxwin2.inl):
_AFXWIN_INLINE void CDialog::GotoDlgCtrl(CWnd* pWndCtrl)
{ ASSERT(::IsWindow(m_hWnd)); ::SendMessage(m_hWnd,
WM_NEXTDLGCTL, (WPARAM)pWndCtrl->m_hWnd, 1L); }
Better yet, check out the WM_NEXTDLGCTL message, which actually
explains the
issues involved. Also note that GotoDlgCtrl does a SendMessage, which
may or
may not be a good thing. Here's part of the online docs:
"The effect of this message differs from that of the SetFocus function
because
WM_NEXTDLGCTL modifies the border around the control.
Do not use the SendMessage function to send a WM_NEXTDLGCTL message if
your
application will concurrently process other messages that set the
focus. Use
the PostMessage function instead. "
(Any MFC insiders care to comment on that last one? Why SendMessage
instead of
Postmessage?)
-------------------------------------------------------------------
Because SendMessage() calls the window proc directly (synchronously),
and anything you do might be undone from the message handler you
started it. PostMessage() puts a message in the queue that will be
processed sometime after the current business is finished.
-Paul Folbrecht
Compuware Corp.
Become an MFC-L member
| Вернуться в корень Архива
|