Control Creation
I am working on a project that wraps the windows API in C++ classes. It is very similar to MFC but im doing it purely as a learning exercise as I have explored many new ares of C++ and the Win32 API.
At the moment, when I create the controls for a window, I do it whenever the user calls 'AddControl(W32Control* NewControl)' from the window class. This creates the control and adds it to the window just fine but I am NOT creating the control in the window's WM_CREATE message. Whats the difference between creating it in the WM_CREATE message and creating it after the window is created? They both result in a valid control being in the window.
At the moment, when I create the controls for a window, I do it whenever the user calls 'AddControl(W32Control* NewControl)' from the window class. This creates the control and adds it to the window just fine but I am NOT creating the control in the window's WM_CREATE message. Whats the difference between creating it in the WM_CREATE message and creating it after the window is created? They both result in a valid control being in the window.
There's no difference and it is perfectly valid. Usually, you create your INITIAL controls in WM_CREATE, but if during the course of your program you need to show more data, you are allowed to add more controls to the main window as you see fit.
It is my experience that few C++ newcommers realize that the Win32 Api is already extremely object oriented. Perhaps the reason for this is that the Api was created before C++ came into widespread use. At the time the Api was taking shape, that is, in the mid 80s, the ideas central to OOP existed, and in terms of the Win Api they were implemented in C - not C++.
I think this idea is alien to modern C++ coders, that is, the idea that OOP can be done in C. Nonwithstanding this, it can be. The Windows Api is proof of it.
You have to first realize that the WM_CREATE message a parent Window receives at the time of a CreateWindow() call is essentially a call of the Window's constructor. My own style of programming is to create all child window controls within the constructor of the parent window, and so I do them in a message handler for the WM_CREATE message, i.e.,...
I have seen other styles where child window controls are created in the same procedure as CreateWindow() calls on the parent, and naturally, the CreateWindow() call returns a HWND to allow for this. However, stylelistically, I prefer creating child windows of a parent as part of and within a constructor of the parent, because I'm a believer in OOP principles.
However, because I also am a believer in efficiency, performance, and small program size with a minimum of application dependencies, I do not create C++ wrappers around the Win32 Api as you are doing. I prefer dealing with it on its own terms in terms of its inherent C based OOP design.
In that design one attaches objects to the Window Class, i.e., child window controls and memory allocations for memory required by instances of the class, either through .cbWndExtra bytes allocated at class registration time, or through Window Properties accessable by GetProp() / SetProp() Apis.
In this programming technique there is ABSOLUTELY, ABSOLUTELY no room for the existance of globally allocated data, because, under the principles of OOP design, all data must be associated with an object, and should not be accessable from objects not having a right to that data.
Don't know if I'm answering your question, but I'm trying.
I think this idea is alien to modern C++ coders, that is, the idea that OOP can be done in C. Nonwithstanding this, it can be. The Windows Api is proof of it.
You have to first realize that the WM_CREATE message a parent Window receives at the time of a CreateWindow() call is essentially a call of the Window's constructor. My own style of programming is to create all child window controls within the constructor of the parent window, and so I do them in a message handler for the WM_CREATE message, i.e.,...
|
|
I have seen other styles where child window controls are created in the same procedure as CreateWindow() calls on the parent, and naturally, the CreateWindow() call returns a HWND to allow for this. However, stylelistically, I prefer creating child windows of a parent as part of and within a constructor of the parent, because I'm a believer in OOP principles.
However, because I also am a believer in efficiency, performance, and small program size with a minimum of application dependencies, I do not create C++ wrappers around the Win32 Api as you are doing. I prefer dealing with it on its own terms in terms of its inherent C based OOP design.
In that design one attaches objects to the Window Class, i.e., child window controls and memory allocations for memory required by instances of the class, either through .cbWndExtra bytes allocated at class registration time, or through Window Properties accessable by GetProp() / SetProp() Apis.
In this programming technique there is ABSOLUTELY, ABSOLUTELY no room for the existance of globally allocated data, because, under the principles of OOP design, all data must be associated with an object, and should not be accessable from objects not having a right to that data.
Don't know if I'm answering your question, but I'm trying.
I appreciate freddie1's answer. Probably because I agree with him.
To see exactly how WM_CREATE works, do this simple example --
1. Create your window.
2. From WITHIN the WM_CREATE statement in your main window proc, do a simple MessageBox().
3. Now, IMMEDIATELY AFTER your CreateWindow() function in the calling routine, set another MessageBox().
You will discover that the first MessageBox() in the WM_CREATE statement displays before the other one which is yet IMMEDIATELY AFTER your CreateWinodow().
In other words, statements within the WM_CREATE procedure get executed BEFORE most/all others.
To see exactly how WM_CREATE works, do this simple example --
1. Create your window.
2. From WITHIN the WM_CREATE statement in your main window proc, do a simple MessageBox().
3. Now, IMMEDIATELY AFTER your CreateWindow() function in the calling routine, set another MessageBox().
You will discover that the first MessageBox() in the WM_CREATE statement displays before the other one which is yet IMMEDIATELY AFTER your CreateWinodow().
In other words, statements within the WM_CREATE procedure get executed BEFORE most/all others.
I know what order round they are called @ the last comment.
Freddie i understand where you are coming from, it makes alot of sense. Like i said, this is more of a 'fictional' project as it had no real direction, just to keep the C++ ball rolling.
My question has been answered, creating controls after the window is a legitimate thing to do. Thanks for your input.
Freddie i understand where you are coming from, it makes alot of sense. Like i said, this is more of a 'fictional' project as it had no real direction, just to keep the C++ ball rolling.
My question has been answered, creating controls after the window is a legitimate thing to do. Thanks for your input.
Topic archived. No new replies allowed.