Quote:
I note that it would be possible to have one windows procedure servicing an entire application, even if it had 5 or 6 windows/toolbars/forms or whatever, all with different functionalities. (Well, the base functionality of the window would be the same, but we could switch the w/lParams in the WM_COMMAND message handler so each control has different functionality.) I assume to keep things straightforward and logically encapsulated (not to mention create different controls per window in the WM_CREATE handler,) that this is not a typical architecture and that one should usually have one windows procedure for each window in the application?
I personally don't use an architecture such as you describe for the following reason - its simpler to to have a seperate Window Procedure for every top level application window. As you've no doubt gleaned by now complexity is the killer in application development. One must in every good application one writes come up with ways of handling complexity so that one can use the 'divide and conquer' approach to allow one to isolate functionality into smaller and smaller manageable piecies, so that one can fully grasp each particular small part and 'get it right' before moving on to another part of a program. That's basically what the RegisterClass/CreateWindow Apis allows one to do; each specific window in a large application has some particular purpose apart from all others. By Registering a Window Class for each top level window/form/dialog in a program that necessitates providing an address to WNDCLASSEX::lpfnWndProc for that window. In that manner, the functionality and code specific to that window type is isolated from all other windows in an application by the Window Procedure specific to that Window Class. And if each Window Procedure along with the message handlers pertaining to that Window Procedure are put in a seperate code file (*.cpp, *.h), then one has an important modularization technique available for conquering complexity in large application development scenarios. The situation is really no different from the design philosophy underlying C++ Classes, i.e., create a seperate class for each functionality you need, and don't conflate/conflict things together. So when I provided that previous example of mine with a Dialog for Form1, and then that Form2 and Form3, with seperate Window Procedures for all three, I was basically showing a simplified 'model' of how I design very large 'enterprise' scale applications. There are no doubt other way to go about it, but what I have shown is what I have personally found effective.