Sign in to follow this  
johnnyBravo

How to route a button's messages to main msgproc?

Recommended Posts

Hi, I've got a 'button' whos parent is a 'static' who's parent is the main window. mainWindow<-static<-button How would I get the "button's" messages to goto the main msgproc that has been assigned to the main window? Thanks

Share this post


Link to post
Share on other sites
Maybe you have to Attach the button to the main window ? You will need to Detach the button first.

Share this post


Link to post
Share on other sites
Quote:
Original post by Skizz
When you create the button, make its parent mainWindow, then do:
SetParent (button, static);

Skizz


i have, i say:
buttonHwnd = createwindow("button".....mainHwnd....);
SetParent(buttonHwnd,staticHwnd);

It works fine with the "edit" control, but when I use buttons, it sends no messages.

Share this post


Link to post
Share on other sites
Hmmm. Nothing like a bit of consistancy there then. I guess you're left with either subclassing the static control or subclassing the button itself. I'd go with the former.

It does say in the SDK that buttons are designed to be used in dialog boxes and that their use anywhere else may lead to 'behaviour in a nonstandard fashion'.

Skizz

Share this post


Link to post
Share on other sites
You wouldn't have any spare example programs that you have done with that?

I've tried so many examples on the net, and they are never complete or explain it well enough.

Share this post


Link to post
Share on other sites
It's not that difficult really:

1) Creation of window
a) swnd = CreateWindow ("static");
b) oldproc = GetWindowLong (swnd, GWL_WNDPROC)
c) SetWindowLong (swnd, GWL_WNDPROC, static_proc_handler)
d) SetWindowLong (wndmain, GWL_USERDATA, oldproc) // or some other window related variable. A global may not be enough.

2) The static_proc_handler

LRESULT CALLBACK static_proc_handler (HWND wnd, UINT m, WPARAM w, LPARAM l)
{
HWND parent = get the parent window
switch (m)
{
case BN_CLICK:
// and any other messages
SendMessage (parent, m, w, l);
break;

default:
proc = GetWindowLong (parent, GWL_USERDATA);
CallWindowProc (proc, wnd, m, w, l);
break;
}
}

3) Tidying up:
a) old_proc = GetWindowLong (wndmain, GWLUSERDATA)
b) SetWindowLong (swnd, GWL_WNDPROC, old_proc)

Skizz

Share this post


Link to post
Share on other sites
Errr, what is everyone smoking today?

First, why is the button's parent the static control? The parent of a control receives messages relating to children. You make the parent be the containing window so you *don't* have to subclass the intermediary windows! It is ridiculous to subclass a static control for this rason. The parent window acts as the mediator between the various UI objects. (Yes, just like the pattern, we can dance around knowing that we used a design pattern!) It is even more ridiculous to make windows children of the static control when a static control is usually just used as a place holder or a label. Make the main window the parent of the control and things will be a lot more sane.

Second, the reason there aren't many tutorials on this is cause its covered *very* well by Petzold's Win32 Programming book. Don't even touch Win32 without it nearby.

Third, this is in MSDN:
Contents:
User Interface Design and Development
- Windows Controls
- - Individual Control Information
- - - Button Controls

Fourth, the notification message is a WM_COMMAND with a notification code of BN_CLICKED. I'll let you look up how to determine where it is coming from.

Share this post


Link to post
Share on other sites
Quote:
Original post by johnnyBravo
I'm just curious why its necessary to restore the old msgproc?

I suppose that you don't need to do that, I guess I do it for the general tidyness of it.

antareus
Of course I know BN_CLICK is delivered through a WM_COMMAND, but that code was only to show general behaviour:

HWND parent = get the parent window

is not valid C/C++.

And making controls children of statics makes plenty of sense - they all move together and show/hide at the same time. It makes the code a bit more compact and maintainable, i.e. when you add a new control, you don't need to find and update all the places where the parent is moved / shown / hidden.

Skizz

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this