Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Radio Button Lockup with Tab Control

49 views
Skip to first unread message

Timothy Dean

unread,
Feb 23, 2009, 6:59:15 PM2/23/09
to
I have a tab control on the page (CFormView) that is a WS_EX_CONTROLPARENT.
Outside of the tab control I have radio buttons. When I click on any of the
radio buttons, the app locks up. When I remove WS_EX_CONTROLPARENT from the
tab control, the lockup doesn't happen. Of course then I can't tab into the
tab control and tab through the child controls. Any idea what would cause
this? Thanks.

Timothy Dean


David Lowndes

unread,
Feb 23, 2009, 7:41:42 PM2/23/09
to

Timothy,

Spy++ may be able to help you identify what's happening - it's
probably some message repeatedly being processed.

It may be that the tab control appears to be part of the radio button
grouping - try adding the WS_GROUP style to the tab control.

Dave

Ajay Kalra

unread,
Feb 23, 2009, 7:55:18 PM2/23/09
to
I dont recall completely but there was a redraw problem some time ago with
this(or was it property page/sheet). Google brings something on this if used
with XP themes.

--
Ajay

"David Lowndes" <Dav...@example.invalid> wrote in message
news:0eg6q4pr7fi7ut143...@4ax.com...

Joseph M. Newcomer

unread,
Feb 24, 2009, 3:57:53 AM2/24/09
to
Make sure that the first control following the radio buttons (in tab order) has the
WS_GROUP flag set. This should solve the problem. It appears that the code might be
locking up trying to find the WS_GROUP that delimits the radio buttons.

One way to do this is to create a "Group Box" and set its tab order to be one past the
last radio button, and set its WS_GROUP attribute.

It sounds like you have hit a serious bug in how radio buttons are being handled, but the
fix I suggest here should avoid that bug. You might consider reporting this to Microsoft,
because it is a Really Bad Idea that it should happen.

Radio buttons work as follows
(*) WS_TABSTOP, WS_GROUP
( )
( )
( )
Whatever follows the radio buttons: WS_GROUP, and if an active control, WS_TABSTOP.

When you click a radio button, it races backwards in the tab order to the WS_GROUP control
that indicates the start of the radio group, and races forwards in the tab order to the
first WS_GROUP control that indicates that it is NOT part of the radio button set. The
button you click on is set, the other buttons are cleared (this is for
AutoRadioButton-style controls). It sounds like it is getting lost on the forward scan.
joe

Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Timothy Dean

unread,
Feb 24, 2009, 11:42:42 AM2/24/09
to
Yep. Thats what it was. A pretty nasty Microsoft bug. If I add any
control after the final radio button with the WS_GROUP style, the problem is
solved. My first radio button always had the WS_GROUP style set. The funny
thing is that if I set the tab control to have WS_GROUP, it stilll locks up.
My current project is compiled in VS 2005. I wonder if it is fixed in VS
2008. Thanks.

Timothy Dean

"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:nbd7q4l5m9b037il6...@4ax.com...

David Lowndes

unread,
Feb 24, 2009, 2:40:20 PM2/24/09
to
>My current project is compiled in VS 2005. I wonder if it is fixed in VS
>2008. Thanks.

I'd doubt it's anything to do with MFC - more likely just the way
Windows is.

Dave

Joseph M. Newcomer

unread,
Feb 24, 2009, 5:12:33 PM2/24/09
to
This is not VS-specific; it is how the autoradiobuttons work in the kernel control
support.
joe
0 new messages