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?
