- Forum
- Windows Programming
- Single window procedure for all windows
Single window procedure for all windows
I am creating a financial software that will contain many different modules. Each module will have a menu and a bunch of forms. The menu will change according to the module and it will be attached to the application main window that will be the parent window of the forms in that specific module (I hope I am clear enough). So, each one of those forms is a child window of the main application window and each one has its own functionality and customization.
My questions are:
How to create the window procedures for each of those forms? I need the best practice to do this and to avoid hard-coding as much as I can knowing that I'll have around 70-80 forms (i.e. windows) as the application is growing up. Is there a way to have a single window procedure for all the forms? Then this single window procedure will invoke the specific procedures for each form by its own. Is this applicable?
My questions are:
How to create the window procedures for each of those forms? I need the best practice to do this and to avoid hard-coding as much as I can knowing that I'll have around 70-80 forms (i.e. windows) as the application is growing up. Is there a way to have a single window procedure for all the forms? Then this single window procedure will invoke the specific procedures for each form by its own. Is this applicable?
Without knowing the specific detail of the forms it's difficult to say,
But if you are talking about forms that act lke standard paper forms, it should be easy enough to create a windows class that can handle a dynamically configurable set of entries (mostly static and edit controls, and dropdowns?)
You might find that it's the case that you can handle most forms this way, but a few need special trestment.
In addition, if you have a repeated set of entrier for multiple forms, you could possibly code custom controls (either ground up or by extending existing controls).
Have you decided which GUI toolkit you're going to use?
But if you are talking about forms that act lke standard paper forms, it should be easy enough to create a windows class that can handle a dynamically configurable set of entries (mostly static and edit controls, and dropdowns?)
You might find that it's the case that you can handle most forms this way, but a few need special trestment.
In addition, if you have a repeated set of entrier for multiple forms, you could possibly code custom controls (either ground up or by extending existing controls).
Have you decided which GUI toolkit you're going to use?
Last edited on
Single window procedure for all windows |
No way. Whether you use the SDI (Single Document Interface) or MDI (Multiple Document Interface) model, you need a separate Window Procedure for every 'class' of form/dialog/window that has some unique functionality.
It depends on the GUI toolkit or classes you use.
Some GUI toolkits, for example, have only a single actual window (in the WIN32 sense, with an associated HWND and window proc). The windows you see on the screen are handled by the frameworks's own drawing code. Two frameworks which use this approach are Stingray (by Rogue Wave) and FLTK (FLTK only registers a single Window class by default; it's own code handles the window drawing and behaviour. You can also derive from the FLTK classes).
(Note: it's been a while since I've worked with Stingray, but that's what it did 5 years ago. It meant that our existing GUI test tools failed to work as they couldn't find the "controls", which is normally done by enumerating child windows).
I have also worked on a couple of application which use this approach. The more recent dsplayed a number of apparent "windows" which were assembled out of a set of standard components configured by XML, much in the same way that XAML (WPF) and XUL (Mozilla) work, but with custom C++ components. Again there was only a single actual WIN32 window. (Dynamic updating of the GUI objects was allowed after the components had been assembled).
The XML plus stock components approach just might be appropriate here if most of the forms are all made up a relatively limited set of subcomponents.
The objects in the GUI layer were connected to the objects in the business layer by "URLs", which also allowed the business objects to reference the correct data records.
With this approach, most of the unique code is found in the business layer, not the GUI layer. The majority of the GUI objects are standard button, edit fields, dropdowns, ...
Even though this was a single application, there were well defined GUI, business, and data layers.
Some GUI toolkits, for example, have only a single actual window (in the WIN32 sense, with an associated HWND and window proc). The windows you see on the screen are handled by the frameworks's own drawing code. Two frameworks which use this approach are Stingray (by Rogue Wave) and FLTK (FLTK only registers a single Window class by default; it's own code handles the window drawing and behaviour. You can also derive from the FLTK classes).
(Note: it's been a while since I've worked with Stingray, but that's what it did 5 years ago. It meant that our existing GUI test tools failed to work as they couldn't find the "controls", which is normally done by enumerating child windows).
I have also worked on a couple of application which use this approach. The more recent dsplayed a number of apparent "windows" which were assembled out of a set of standard components configured by XML, much in the same way that XAML (WPF) and XUL (Mozilla) work, but with custom C++ components. Again there was only a single actual WIN32 window. (Dynamic updating of the GUI objects was allowed after the components had been assembled).
The XML plus stock components approach just might be appropriate here if most of the forms are all made up a relatively limited set of subcomponents.
The objects in the GUI layer were connected to the objects in the business layer by "URLs", which also allowed the business objects to reference the correct data records.
With this approach, most of the unique code is found in the business layer, not the GUI layer. The majority of the GUI objects are standard button, edit fields, dropdowns, ...
Even though this was a single application, there were well defined GUI, business, and data layers.
Last edited on
Well, anything is possible using pure Windows API. The restrictions are very few. You CAN have a single window procedure for many window classes, as the class needs only the address of the window procedure and I have never heard it must be unique among window classes. Having said that, a single window procedure that handles 70+ different forms is bound to grow complex.
Sooooo, is it really a gain to have 1 WP to many window classes? Most likely it is not.
But andy seems to be right on the money, though. Andy proposes that you build generic "construction" logic into a single window class that is clever enough to construct itself depending on the business object it represents. This is probably your best approach.
Sooooo, is it really a gain to have 1 WP to many window classes? Most likely it is not.
But andy seems to be right on the money, though. Andy proposes that you build generic "construction" logic into a single window class that is clever enough to construct itself depending on the business object it represents. This is probably your best approach.
why not just have an enum of different window types, then keep an std::vector<int> to keep track of open windows & just do a switch in your WndProc?
First, sorry for late reply.
Anyway, my forms will be just as Andy described. Each will be
WebJose, you had said:
Please explain further.
Anyway, my forms will be just as Andy described. Each will be
a window that will handle a dynamically configurable set of entries (static, edit control, dropdowns, buttons...). But could this be done with 1 window procedure for all those forms? Could the window procedure be a member function of the window class knowing that my window class is a custom object in which I use CreateWindowEx to create each form and its controls.WebJose, you had said:
build generic "construction" logic into a single window class that is clever enough to construct itself depending on the business object it representsPlease explain further.
My feeling is that you are unlikely to get away with just a single window class.
But, if your forms can be grouped into categories, you will hopefully be able to handle the forms with a limited number of windows; that is one per category. Probably along with a few special windows for the more difficult forms.
If you are using WIN32 ground up to code your windows, which your mention of CreateWindowEx suggests, there are issues about using classes to handle the windows messages. I would probably leave these as standard function. but they could be made static class member functions.
If you are using Visual C++ Professional or greater,, you could look at WTL for your purpose. (Or MFC, another GUI library). This would provide you with a window class to use as your starting point, but the need for custom mesage routing, etc would not be removed.
But the construction of a set of dynamic controls means that you are going to have to do some custom processing of messages. If you are just working with edit controls, comboboxes, and the common contols, you will need to handle a relatively limited range of messages (WM_COMMAND, WM_NOTIFY, ...) so custom routing might not be too painful.
But, if your forms can be grouped into categories, you will hopefully be able to handle the forms with a limited number of windows; that is one per category. Probably along with a few special windows for the more difficult forms.
If you are using WIN32 ground up to code your windows, which your mention of CreateWindowEx suggests, there are issues about using classes to handle the windows messages. I would probably leave these as standard function. but they could be made static class member functions.
If you are using Visual C++ Professional or greater,, you could look at WTL for your purpose. (Or MFC, another GUI library). This would provide you with a window class to use as your starting point, but the need for custom mesage routing, etc would not be removed.
But the construction of a set of dynamic controls means that you are going to have to do some custom processing of messages. If you are just working with edit controls, comboboxes, and the common contols, you will need to handle a relatively limited range of messages (WM_COMMAND, WM_NOTIFY, ...) so custom routing might not be too painful.
Last edited on
When I say build a generic construction logic, I mean that you will have to provide building metadata to your window. The metadata will tell your window that you will be representing an object of a certain type with X amount of configurable values, that value 1 can be edited in free form and has X maximum characters (meaning you create a textbox for it), that value 2 can be picked up from enumerated values, meaning it could be represented by a combo box, etc. etc.
This is in no way an easy task, but it is possible. The real pain here is the metadata. If I were you, I'd code this in .Net since Reflection can be used as a metadata source (you can enumerate properties, the types, etc. just like the property grid does!).
This is in no way an easy task, but it is possible. The real pain here is the metadata. If I were you, I'd code this in .Net since Reflection can be used as a metadata source (you can enumerate properties, the types, etc. just like the property grid does!).
Thanks for your replies.
WebJose, in my window class, there is an array - private member of the window class - that will hold the list of controls to be created
However, what about
WebJose, in my window class, there is an array - private member of the window class - that will hold the list of controls to be created
However, what about
having the window procedure as a member group for my window class? Is it possible? If yes, then how?
@ahbazzi - A quick few questions!
- what versions of Windows do you need to support?
- what IDE / compiler are you using?
- are you writing directly to the WIN32 API?
Andy
- what versions of Windows do you need to support?
- what IDE / compiler are you using?
- are you writing directly to the WIN32 API?
Andy
- The version that the application must support is XP and forward
- the compiler is the c++ visual basic compiler
and regarding the WIN32 API, I'm creating my files but using API
- the compiler is the c++ visual basic compiler
and regarding the WIN32 API, I'm creating my files but using API
If you have a paid for version of Visual Studio (standard or greater) then you have MFC. This might be a better starting point if you want to use a class based approach to develop a Windows application.
There are two MFC classes that might be of interest to you; for inspiration if not use.
CFormView
CHtmlView
The latter might be of interest if you are happy with a web page style UI.
There are two MFC classes that might be of interest to you; for inspiration if not use.
CFormView
| A form view is essentially a view that contains controls. These controls are laid out based on a dialog-template resource. Use CFormView if you want forms in your application. |
CHtmlView
| The WebBrowser control is a window in which the user can browse sites on the World Wide Web, as well as folders in the local file system and on a network. |
The latter might be of interest if you are happy with a web page style UI.
Last edited on
Topic archived. No new replies allowed.