Further to child windows...

[Guest]

Further to my last post, I have managed to get a child window to display. But its messages are routed to the same WNDPROC that the main window's messages are routed to - what is the way of identifying from the lParam or wParam whether the message came from a child window or the parent? And what if the message uses some other data in the wParam or lParam? Is it better to use one wndproc for the parent window, and one wndproc for all child windows of the same type

Also I am having an issue whereby the child window doesn't seem to be able to gain the focus - i.e. have its caption bar blue instead of grey. But I suspect this is due to its sharing of the wndproc.... is it

 

[Igor Tandetnik]

Further to my last post, I have managed to get a child window to

display. But its messages are routed to the same WNDPROC that the main
window's messages are routed to

The messages are routed to whatever function you specified in WNDCLASSEX
structure when calling RegisterClassEx. If you create two windows from
the same window class, or use the same window proc in two window
classes, then of course messages will come to the same proc.

- what is the way of identifying from the lParam or wParam whether the

message came from a child window or the parent?

What's wrong with HWND parameter?

And what if the message uses some other data in the wParam or lParam?

Is it better to use one wndproc for the parent window, and one wndproc
for all child windows of the same type?

Yep, that's the idea. You use the same proc for all windows that behave
similarly, and different procs for windows that should behave
differently.

Also I am having an issue whereby the child window doesn't seem to be

able to gain the focus - i.e. have its caption bar blue instead of grey.
But I suspect this is due to its sharing of the wndproc.... is it?

A child window is not supposed to have a caption. When it does, it never
gets active. Except in MDI - are you maybe trying to create an MDI
interface?
--
With best wishes,
Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken

 

[Bonj]

Thanks for posting Igor...

What's wrong with HWND parameter?

Oh yes. Forgot that. A case of not seeing the wood for the trees I think!

A child window is not supposed to have a caption. When it does, it never
gets active.

OK then - what about the sort of window that you get when you click 'Tools,
Options' or 'Project, Settings' in Visual Studio, is that not a child window
with a caption that is active?

Except in MDI - are you maybe trying to create an MDI
interface?

Yes, I think I am. Basically I wrote some generic code that performs the
very basic function of encapsulating the process of creating a window into a
class, and it seemed to work quite well for the program that I'm developing,
but was generic enough to be reusable - so I posted in on
planetsourcecode.com (C++ under 'ClassDialog') for others to look at. But
it's only designed for a single window, in a single threaded application...
somebody emailed me to ask him to help with his efforts at using it in a
project of his. What it seems like he's trying to do is to create a main
window, then create some child windows in different threads. What he's done
is basically copied and pasted the WNDCLASSEX-registering code from the
class into a thread function, which I thought was a bad idea generally both
from a maintenance point of view because there's no point in wrapping the
code in a class and then just duplicating it somewhere else. So I decided to
try to get the class to be able to instantiate a child window (using the
same class that the parent was itself), and putting the code that
instantiates the extra classes for the child windows in a thread function...
but with regards to the threads issue, I thought it seemed a bit 'cramped' -
I didn't like the sound of several threads accessing the same wndproc router
at the same time, aswell as the fact that the window appeared to be having
to kind of 'bootstrap' itself - it needed a pointer to itself and that just
didn't seem good to me. So I tried a different approach today, I created a
separate class for the child windows, and kept it as one thread. The child
window class registered its own WNDCLASSEX, but used the same wndproc - and
it worked (even though the child window never got focus as I expected - but
see my previous paragraph as to this). However, I am in two minds as to
whether the downloader of my code is using extra threads because he
genuinely needs separate UI threads - or just because he happens to like
multithreading, possibly because he believes it always improves an app's
performance, and as such makes it one of the first things he codes at the
start of any application as a matter of course. I originally wanted to post
back to him a working example that uses child windows in their own threads
from the same class. But I guess it's probably going to be different classes
for the child windows, and single threaded - with a note that he should
perhaps evaluate the threading needs of the application more thoroughly and
that an extra UI thread is a whole different beast from an extra worker
thread, and that it might make cleaner code to only use threads for specific
long operations.

So to cut a long story short, my class has fulfilled its purpose for the
program I intent to write - but it's led onto "well what if I wanted it to
do x, y and z aswell?" !
So I guess I would really like to know something about the difference
between (and how to create) a window that is like an options dialog
(possibly non-modal, but confined to the application) and a window that is
an MDI window....
any pointers?

 

[Igor Tandetnik]

OK then - what about the sort of window that you get when you click 'Tools,
Options' or 'Project, Settings' in Visual Studio, is that not a child window
with a caption that is active?

No, it's a popup window, with WS_POPUP style. Just check with Spy++. A
child window is the one having WS_CHILD style. Typically, a dialog is a
popup window, controls are its children.

What it seems like he's trying to do is to create a main
window, then create some child windows in different threads.

Very, very, very bad idea. Don't do that. If at all possible, keep all
UI in a single thread. In some cases, it may be useful to keep
independent top-level windows in different threads. But having a child
window and its parent window in different threads is simply a recipe for
deadlock.

So I guess I would really like to know something about the difference
between (and how to create) a window that is like an options dialog
(possibly non-modal, but confined to the application)

What do you mean, confined? A dialog is not confined within its parent.
You can drag it outside - just try it.

and a window that is
an MDI window....

They are different, the same way apples and oranges are different. I'm
not sure I understand this question.
--
With best wishes,
Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken

 

[Bonj]

No, it's a popup window, with WS_POPUP style. Just check with Spy++. A

child window is the one having WS_CHILD style. Typically, a dialog is a
popup window, controls are its children.

Right, thanks. This is the information I was looking for.

Very, very, very bad idea. Don't do that. If at all possible, keep all
UI in a single thread. In some cases, it may be useful to keep
independent top-level windows in different threads. But having a child
window and its parent window in different threads is simply a recipe for
deadlock.

I thought so, and have advised him of this.

What do you mean, confined? A dialog is not confined within its parent.
You can drag it outside - just try it.

No, I suppose it's not....if that isn't the expected behaviour of them then
I suppose there's little point trying to make one confined.

They are different, the same way apples and oranges are different. I'm
not sure I understand this question.

Yes, I see that now, thanks. I thought that all windows other than top level
windows had WS_CHILD style, and they each had extra code to handle the
behaviour typical of popup windows and MDI-child windows. I've since
discovered an example that indicates that MDI children are created with
separate API functions, and learned from you that WS_POPUP is the style to
use for an options dialog, so I guess I'm content with that... cheers for
your help.