When I create radiobuttons inside a groupbox, the radiobutton messages and events are ignored.
Does the groupbox need its own WindowProc as if it were a window?
; Create Groupbox
invoke CreateWindowEx,0,!ControlType6,NULL,WS_VISIBLE+WS_CHILD+BS_GROUPBOX,0,0,200,200,[OBMain],113,[!hinstance],NULL
mov dword [Frame],eax
;...
; Create radiobutton "in" groupbox
invoke CreateWindowEx,0,!ControlType19,NULL,WS_VISIBLE+WS_CHILD+BS_AUTORADIOBUTTON,0,0,80,30,[Frame],114,[!hinstance],NULL
mov dword [RadioButton1],eax
Does the groupbox need its own WindowProc as if it were a window?
Maybe you should create the other buttons over the groupbox, instead of inside it?
The GroupBox is a neutral control, it will not necessarily relay the messages to it's parent. I am assuming that you are making the RBs children of the group box. Try using a subclass to relay the messages if you really want to create the RadioButtons as children of the GroupBox instead of the main window. At any rate I think that the problem is that the RBs are sending their messages to the groupbox which is not relaying them to it's parent.
PS: you might try setting the WS_EX_CONTROLPARENT style of the GroupBox, it should relay the messages iirc. This should not create problems as long as you don't indicate a tabstop for the GroupBox. <-Nope doesn't work
PS: you might try setting the WS_EX_CONTROLPARENT style of the GroupBox, it should relay the messages iirc. This should not create problems as long as you don't indicate a tabstop for the GroupBox. <-Nope doesn't work
Sephiroth3,
Maybe you should create the other buttons over the groupbox, instead of inside it?
If I do this, the radiobuttons will be in the same group as all of the other buttons on every other groupbox (or anywhere else on the main window).
All of the GUI packages I,ve worked with allow creating controls as children of a groupbox. I just don't know how to do it with Win32 API.
Maybe you should create the other buttons over the groupbox, instead of inside it?
If I do this, the radiobuttons will be in the same group as all of the other buttons on every other groupbox (or anywhere else on the main window).
All of the GUI packages I,ve worked with allow creating controls as children of a groupbox. I just don't know how to do it with Win32 API.
You can set the WS_GROUP style for the first control of a group and clear it for each other control. That will create groups of radio buttons. Windows will consider each control part of the group until it finds a control with the WS_GROUP style set, it searches the controls by tab order.
If you really must have the group box as the parent for the radio buttons you can use a very simple subclassing routine that will relay the messages to the parent. This routine is re-usable for any parent as it gets the handle of the parent programatically.
invoke SetWindowLong,hGroupBox,GWL_WNDPROC,OFFSET GBSProc
mov OldGBProc,eax
GBSProc PROC uses ebx esi edi hWin:HWND,uMsg:UINT,wParam:WPARAM,lParam:LPARAM
.IF uMsg==WM_COMMAND || uMsg==WM_NOTIFY
invoke GetParent,hWin
invoke PostMessage,eax,uMsg,wParam,lParam
.ENDIF
invoke CallWindowProc,OldGBProc,hWin,uMsg,wParam,lParam
ret
GBSProc endpJust as a last note about this, I tested the examples and sent my program into an infinte loop. I searched the knowledge base (it couldn't have been me after all :) ) and found this, you will have to take this into consideration when using BS_AUTORADIOBUTTON. The problem does not seem to have been resolved in any version of Windows I tested (98SE, 2KSP3,2KSP4 and XP)
http://support.microsoft.com/default.aspx?scid=kb;en-us;261192
http://support.microsoft.com/default.aspx?scid=kb;en-us;261192
Hi Donkey,
I assume (having read the Microsoft advisory) that you were referring to the fix you discovered earlier using 'WS_GROUP".
I couldn't have used that approach anyway because this is compiler generated code based on what a user "draws". This user cannot be expected to know which is the first button in a group, and if he did, it could change by deleting a radiobutton etc.
If I were to use that approach (I haven't had a chance yet today), I would make every control with WS_GROUP except subordinates. Still won't work if the user deletes the one that has WS_GROUP in a radiobutton set.
I will try your subclass solution tonight.
As always, thanks!.
BTW The sk.b program I sent you this week has a precise example in it that we have been talking about here (ref: RadioButton1 thru RadioButton5). Notice that RB1 created on the main window works fine both for WM_COMMAND as well as the ctlcolor stuff while RadioButton1-5 have no color and make no command event.
Also, I have not gotten into the Tab (or Notebook) control as yet, but assume it would also be nice to create child windows with a tab as parent.
I assume (having read the Microsoft advisory) that you were referring to the fix you discovered earlier using 'WS_GROUP".
I couldn't have used that approach anyway because this is compiler generated code based on what a user "draws". This user cannot be expected to know which is the first button in a group, and if he did, it could change by deleting a radiobutton etc.
If I were to use that approach (I haven't had a chance yet today), I would make every control with WS_GROUP except subordinates. Still won't work if the user deletes the one that has WS_GROUP in a radiobutton set.
I will try your subclass solution tonight.
As always, thanks!.
BTW The sk.b program I sent you this week has a precise example in it that we have been talking about here (ref: RadioButton1 thru RadioButton5). Notice that RB1 created on the main window works fine both for WM_COMMAND as well as the ctlcolor stuff while RadioButton1-5 have no color and make no command event.
Also, I have not gotten into the Tab (or Notebook) control as yet, but assume it would also be nice to create child windows with a tab as parent.
Exactly, you can create a child window for each tab and then it is simply a matter of setting the ws_visible flag when you switch tabs. Each tab child window requires that the DS_CONTROL style is set to relay events to the main window, and the tab control has the WS_EX_CONTROLPARENT style set. Those are the main things to keep in mind for tab controls at any rate.
Donkey,
A variation of the subclassing works fine both for command and ctlcolor events. Thanks!
I had posted a thread last week concerning combobox using GetWindowLong on a combobox's GWL_USERDATA. Nobody made a comment on this problem. (QvasiModo made a suggestion for an alternate solution). My question now is will a combobox allow modifying and retrieving the GWL_WNDPROC data? I would hope so, but after spending hours on the combobox's GWL_USERDATA problem, I'm a little gun shy.
A variation of the subclassing works fine both for command and ctlcolor events. Thanks!
I had posted a thread last week concerning combobox using GetWindowLong on a combobox's GWL_USERDATA. Nobody made a comment on this problem. (QvasiModo made a suggestion for an alternate solution). My question now is will a combobox allow modifying and retrieving the GWL_WNDPROC data? I would hope so, but after spending hours on the combobox's GWL_USERDATA problem, I'm a little gun shy.
I'll find the original thread and take a look. Combo boxes are a little special in my view because they are essentially two controls but GWL_USERDATA works. The GWL_USERDATA field is never used or altered by Windows for any control, it is reserved for your use only.