Windows C++ GUI
If I wouldn't have these tangents to occupy my time my only alternative would be to do my work!
Hi Thomas,
I have bought the C++ Principles and Practice book by Stroustrup as you suggested from Amazon UK. I thought that it would be helpful to have a complete reference like the Petzold book which I found the online version of!
I have bought the C++ Principles and Practice book by Stroustrup as you suggested from Amazon UK. I thought that it would be helpful to have a complete reference like the Petzold book which I found the online version of!
Hi Freddie,
You make a very good case for suing the API and compiling it outside of Visual Studio but first things first .........
I need to get comfortable with the basics first and produce something that's half decent in about 1/10 the time I really need, if what you said previously turns out to be correct.
You make a very good case for suing the API and compiling it outside of Visual Studio but first things first .........
I need to get comfortable with the basics first and produce something that's half decent in about 1/10 the time I really need, if what you said previously turns out to be correct.
I finished with TabDemo Ian which is a Tab Control Demonstration based on your idea of a main app window with three tabs. I named the tabs in rough accordance with the information you provided me and they are Motor Controller Tab, Site Data Tab, and Project – Start Tab. On the Motor Controller Tab I added a Max Acceleration label and text box, and a Max Speed label and Combo Box. In the Max Speed Combo box I added entries for 100 Revolutions Per Minute To 1000 Revolutions Per Minute. In the other tabs I just put text indicating what they are.
Essentially, this app is a variation of another Demo App I’ve posted here and other places a lot of times showing how to build apps with multiple top level windows. In this app the twist is that the multiple windows aren’t top level windows but child windows of a Tab Control.
I guarantee this app’s code will work no matter whether it is built x86 or x64 with Microsoft’s compilers or GCC (Mingw). I’ve tested with VC15 from Visual Studio 2008 and VC19 from Visual Studio 2015. In terms of GCC I’ve tested with TDM-GCC 4.9 and TDM-GCC 4.4.1.
Changing topics slightly, one of the biggest difficulties in writing large projects is handling complexity. It is for that reason that I don’t use Petzold’s switch logic to map Windows messages to the code which handles that message. I use a for loop which iterates through an object which relates the numeric value of a message (it’s a #define) to the address of the message handling procedure/code. I have tutorial material written up about that here…
http://www.jose.it-berater.org/smfforum/index.php?topic=3391.0
The effect of this is to help modularize the code, which helps a lot with the complexity issue. On the second cut through, in an app with multiple windows, such as this one where each tab is essentially a separate window with its own registered Window Class, the code for each window can be kept in separate *.cpp and *.h files. The idea then is to use the linker hard to pull it all together into the finished binary. That’s what I’ve done here. So this project now consists of these files…
If you use an IDE to build the project such as Visual Studio or CodeBlocks you’ll need to copy the code from here with the files named as above and include them in the project. Here is a listing of just the includes and #defines from the project, as well as the build results for all the different compilation/linkages I’ve done…
The smallest build of 6,144 bytes was for x86 using my custom C Runtime Library which I coded myself named TCLib.lib. That only works for Microsoft compilers. For x64 it was 8,192 bytes. All numbers are for stand alone builds not requiring setup programs or redistributables. After that my trusty old TDM-GCC from the 10.05 Code::Blocks Release circa 2008 or so came in about 12 k – just a bit bigger than my own TCLib linked code. Reason for that is I built my lib in a somewhat similar manner to what Mingw did. After that they get pretty bloated, which is the way folks want to produce code nowadays. I guess they get paid by the byte of code generated or something.
There’s a #define Debug which if uncommented causes the app to generate a ot of log file data to show what’s going on. The #define OLD_GCC was necessary to get the code to run with my circa 2008 GCC installation, as with that InitCommonControlsEx() didn’t exist, so I had to use just InitCommomControls(). You’ll see that in the code.
There are no global variables in any of my code. I don’t believe in using them. I take a strongly object oriented view of my Windows apps, where all data which an app uses is in some way related to some specific window object. To show how I organize this note in TabDemo.h an AppData object is defined…
In the Constructor function for the main application object, which is fnWndProc_OnCreate(), I use Windows HeapAlloc() to allocate memory for one of these out of the heap, and I store a pointer to that memory within the main window’s instantiated memory using the WNDCLASS::cbWndExtra bytes. I set a few of the members there, and when the Destructor for the main window is called – fnWndProc_OnDestroy(), if #Debug is defined, those values set in the Constructor are output to the log file. This setup shows how state data can be persisted across member function calls without using global variables, or even statics, which in my mind are just cheap globals.
I’ll start posting the code. Main.cpp is larger than the 8,192 byte limit for a post here, so I’ll have to break that up into two posts....
Essentially, this app is a variation of another Demo App I’ve posted here and other places a lot of times showing how to build apps with multiple top level windows. In this app the twist is that the multiple windows aren’t top level windows but child windows of a Tab Control.
I guarantee this app’s code will work no matter whether it is built x86 or x64 with Microsoft’s compilers or GCC (Mingw). I’ve tested with VC15 from Visual Studio 2008 and VC19 from Visual Studio 2015. In terms of GCC I’ve tested with TDM-GCC 4.9 and TDM-GCC 4.4.1.
Changing topics slightly, one of the biggest difficulties in writing large projects is handling complexity. It is for that reason that I don’t use Petzold’s switch logic to map Windows messages to the code which handles that message. I use a for loop which iterates through an object which relates the numeric value of a message (it’s a #define) to the address of the message handling procedure/code. I have tutorial material written up about that here…
http://www.jose.it-berater.org/smfforum/index.php?topic=3391.0
The effect of this is to help modularize the code, which helps a lot with the complexity issue. On the second cut through, in an app with multiple windows, such as this one where each tab is essentially a separate window with its own registered Window Class, the code for each window can be kept in separate *.cpp and *.h files. The idea then is to use the linker hard to pull it all together into the finished binary. That’s what I’ve done here. So this project now consists of these files…
|
|
If you use an IDE to build the project such as Visual Studio or CodeBlocks you’ll need to copy the code from here with the files named as above and include them in the project. Here is a listing of just the includes and #defines from the project, as well as the build results for all the different compilation/linkages I’ve done…
|
|
The smallest build of 6,144 bytes was for x86 using my custom C Runtime Library which I coded myself named TCLib.lib. That only works for Microsoft compilers. For x64 it was 8,192 bytes. All numbers are for stand alone builds not requiring setup programs or redistributables. After that my trusty old TDM-GCC from the 10.05 Code::Blocks Release circa 2008 or so came in about 12 k – just a bit bigger than my own TCLib linked code. Reason for that is I built my lib in a somewhat similar manner to what Mingw did. After that they get pretty bloated, which is the way folks want to produce code nowadays. I guess they get paid by the byte of code generated or something.
There’s a #define Debug which if uncommented causes the app to generate a ot of log file data to show what’s going on. The #define OLD_GCC was necessary to get the code to run with my circa 2008 GCC installation, as with that InitCommonControlsEx() didn’t exist, so I had to use just InitCommomControls(). You’ll see that in the code.
There are no global variables in any of my code. I don’t believe in using them. I take a strongly object oriented view of my Windows apps, where all data which an app uses is in some way related to some specific window object. To show how I organize this note in TabDemo.h an AppData object is defined…
|
|
In the Constructor function for the main application object, which is fnWndProc_OnCreate(), I use Windows HeapAlloc() to allocate memory for one of these out of the heap, and I store a pointer to that memory within the main window’s instantiated memory using the WNDCLASS::cbWndExtra bytes. I set a few of the members there, and when the Destructor for the main window is called – fnWndProc_OnDestroy(), if #Debug is defined, those values set in the Constructor are output to the log file. This setup shows how state data can be persisted across member function calls without using global variables, or even statics, which in my mind are just cheap globals.
I’ll start posting the code. Main.cpp is larger than the 8,192 byte limit for a post here, so I’ll have to break that up into two posts....
Last edited on
//Main.cpp
continued Main.cpp....
|
|
continued Main.cpp....
// 2nd part Main.cpp...
|
|
TabDemo.h
// Motor.cpp
// Motor.h
|
|
// Motor.cpp
|
|
// Motor.h
|
|
Last edited on
// Project.cpp
// Project.h
// Site.cpp
// Site.h
|
|
// Project.h
|
|
// Site.cpp
|
|
// Site.h
|
|
OMG Freddie,
I am deeply indebted to you!
I am expecting delivery of my C++ book, by Stroustrup as recommended by Thomas, this evening. Armed with that, the online Petzold book and a smattering of my rusty previous API programming I should hopefully be able to find my way around and thoroughly understand what you have been so kind to provide me with.
I now plan an heavy night of programming and VS project setups!
Very many thanks once again!
Ian
I am deeply indebted to you!
I am expecting delivery of my C++ book, by Stroustrup as recommended by Thomas, this evening. Armed with that, the online Petzold book and a smattering of my rusty previous API programming I should hopefully be able to find my way around and thoroughly understand what you have been so kind to provide me with.
I now plan an heavy night of programming and VS project setups!
Very many thanks once again!
Ian
Hi Fred,
I am having a few problems getting your above code to compile and link properly in VStudio 2015.
I have tried to diagnose and fix these on my own so that I start getting used to the IDE and at the same time start to become familiar with your program which as you say is logically structured
I have sent you a personal email as I wanted to include a screen dump so that you can see how I have included all the .cpp and .h files.
I got rid of the VStudio unsafe code error messages by inserting:
#ifdef _MSC_VER
#define _CRT_SECURE_NO_WARNINGS
#endif
at the top of a couple of header files and the main.cpp
However, I am now left with an unresolved external symbol error message from the linker saying that it can't resolve the reference to
Severity Code Description Project File Line Suppression State
Error LNK2019 unresolved external symbol __imp__InitCommonControlsEx@4 referenced in function "long __stdcall fnWndProc_OnCreate(struct WndEventArgs &)" (?fnWndProc_OnCreate@@YGJAAUWndEventArgs@@@Z)
I have about run out of ideas and wonder whether you would be so kind as to give me your considered opinion.
If it would be easier to compile and link from the command line then I am happy to try that but would again need a bit of advice. That's always assuming that I can find a compiler and linker that would do the job as all that I have at present came when I installed VStudio 2015.
Hell, I'm rusty!
Ian
I am having a few problems getting your above code to compile and link properly in VStudio 2015.
I have tried to diagnose and fix these on my own so that I start getting used to the IDE and at the same time start to become familiar with your program which as you say is logically structured
I have sent you a personal email as I wanted to include a screen dump so that you can see how I have included all the .cpp and .h files.
I got rid of the VStudio unsafe code error messages by inserting:
#ifdef _MSC_VER
#define _CRT_SECURE_NO_WARNINGS
#endif
at the top of a couple of header files and the main.cpp
However, I am now left with an unresolved external symbol error message from the linker saying that it can't resolve the reference to
Severity Code Description Project File Line Suppression State
Error LNK2019 unresolved external symbol __imp__InitCommonControlsEx@4 referenced in function "long __stdcall fnWndProc_OnCreate(struct WndEventArgs &)" (?fnWndProc_OnCreate@@YGJAAUWndEventArgs@@@Z)
I have about run out of ideas and wonder whether you would be so kind as to give me your considered opinion.
If it would be easier to compile and link from the command line then I am happy to try that but would again need a bit of advice. That's always assuming that I can find a compiler and linker that would do the job as all that I have at present came when I installed VStudio 2015.
Hell, I'm rusty!
Ian
Hi Ian,
you need to add Comctl32.lib to your project. Easiest way is #pragma comment(lib, "Comctl32.lib") in main.cpp.
Might be a good idea to set up an account on DropBox if you don't have one and post the comlete project there. Loading the project into VS and hitting F5 to run is very often the asiest way to see where the problem is.
you need to add Comctl32.lib to your project. Easiest way is #pragma comment(lib, "Comctl32.lib") in main.cpp.
Might be a good idea to set up an account on DropBox if you don't have one and post the comlete project there. Loading the project into VS and hitting F5 to run is very often the asiest way to see where the problem is.
The InitCommonControlsEx() function is in one of the core Windows libraries named comctl32.lib. I didn't think it would be necessary for me to mention that when I posted the code as I assummed the Visual Studio IDE would include that library as part of the typical set of libraries to be linked against when a Win32 GUI Project is set up. I'm almost certain that used to be the case, but perhaps somewhere along the line they changed stuff. They've been known to do that. You'll note that library listed in the command line compilation strings I posted at the top of Main.cpp...
To set it up in the IDE you have to go up to the main menu to the Project Properties. That of course opens up a rather large and complicated interface component. You should be able to find a Linker Options somewhere. In there somewhere will be some kind of interface/dialog where you'll have to enter comctl32.lib into the series of libraries the build system will link against. There should be others there such as kernel32.lib, user32.lib, and maybe a few others.
At least I hope that is what the issue is Ian. Let me know how it goes. I want it to work for you.
Yes, to get rid of those warnings when building in the IDE one must add CRT_SECURE_NO_WARNINGS in a window somewhere. There's also something to the effect NONCONFORMING_SWPRINTFs or something like that. Alternately, you could set the warning level down to 1. It defaults to Max (4) I believe. Or, one could use the 'secure' string manipulation functions. Half the time when I use them they crash my apps. That's why I gave up on them.
|
|
To set it up in the IDE you have to go up to the main menu to the Project Properties. That of course opens up a rather large and complicated interface component. You should be able to find a Linker Options somewhere. In there somewhere will be some kind of interface/dialog where you'll have to enter comctl32.lib into the series of libraries the build system will link against. There should be others there such as kernel32.lib, user32.lib, and maybe a few others.
At least I hope that is what the issue is Ian. Let me know how it goes. I want it to work for you.
Yes, to get rid of those warnings when building in the IDE one must add CRT_SECURE_NO_WARNINGS in a window somewhere. There's also something to the effect NONCONFORMING_SWPRINTFs or something like that. Alternately, you could set the warning level down to 1. It defaults to Max (4) I believe. Or, one could use the 'secure' string manipulation functions. Half the time when I use them they crash my apps. That's why I gave up on them.
@freddie1,
these are default libs in VS 2015 CE:
kernel32.lib;
user32.lib;
gdi32.lib;
winspool.lib;
comdlg32.lib;
advapi32.lib;
shell32.lib;
ole32.lib;
oleaut32.lib;
uuid.lib;
odbc32.lib;
odbccp32.lib;
these are default libs in VS 2015 CE:
kernel32.lib;
user32.lib;
gdi32.lib;
winspool.lib;
comdlg32.lib;
advapi32.lib;
shell32.lib;
ole32.lib;
oleaut32.lib;
uuid.lib;
odbc32.lib;
odbccp32.lib;
Hi Fred,
I do have a DropBox Account I didn't think of uploading the entire project as I can tell that you are not impressed with VStudio!
And by the way, I was just about to post an apology for my poor choice of words, the compiler warning message said The function ****MAY**** be unsafe, not that it WAS unsafe!
The #pragma comment(lib, "Comctl32.lib") has sorted it so that I now have a Tab Demo Window with three tabbed forms titled Motor Contoller Parameters, Site Data and Project Start.
That's brilliant thanks, now I can really start delving in and adding a few bits and pieces to start fleshing it all out.
Regards
Ian
I do have a DropBox Account I didn't think of uploading the entire project as I can tell that you are not impressed with VStudio!
And by the way, I was just about to post an apology for my poor choice of words, the compiler warning message said The function ****MAY**** be unsafe, not that it WAS unsafe!
The #pragma comment(lib, "Comctl32.lib") has sorted it so that I now have a Tab Demo Window with three tabbed forms titled Motor Contoller Parameters, Site Data and Project Start.
That's brilliant thanks, now I can really start delving in and adding a few bits and pieces to start fleshing it all out.
Regards
Ian
Thanks for posting that Thomas. I see comctl32.lib isn't there, so I'm suspecting my analysis of the issue was correct, and the code should build OK once that lib is added.
In the way of background conceptual information, having unresolved externals is a common plague to programmers. There isn't any line number associated with that error as it isn't generated by the compiler, but rather by the linker. What happens is that a header file will be present where the compiler finds function declarations for various functions, and the compiler is happy with that. When the link stage comes in the linker starts looking through the various libraries for the functions that weren't defined in the *.cpp/*.obj files, because it wants to pull that executable code into the binary being created. When it has gone through all the *.obj files and *.lib files and still hasn't 'resolved' that function call, it finally emits an 'unresolved external' error.
The thing to do to avoid these is to know which libraries various functions you are using are in. You need to understand both the headers and the libraries required. Mioght sound hard but it really isn't. The comctl32.lib is a real common one. It contains all the 'Common Controls', which are things like the Tab Control, Tree View Control, Progress Bar Control, and a bunch of others. These are basically controls that are just a bit more sophisticated than the Standard Windows Controls such as labels, text boxes, and combo boxes. To find where in the documentation one is told which libraries are needed for a specific function call, look up InitCommonControlsEx() on MSDN, and near the bottom it will tell you which library the code is in.
In the way of background conceptual information, having unresolved externals is a common plague to programmers. There isn't any line number associated with that error as it isn't generated by the compiler, but rather by the linker. What happens is that a header file will be present where the compiler finds function declarations for various functions, and the compiler is happy with that. When the link stage comes in the linker starts looking through the various libraries for the functions that weren't defined in the *.cpp/*.obj files, because it wants to pull that executable code into the binary being created. When it has gone through all the *.obj files and *.lib files and still hasn't 'resolved' that function call, it finally emits an 'unresolved external' error.
The thing to do to avoid these is to know which libraries various functions you are using are in. You need to understand both the headers and the libraries required. Mioght sound hard but it really isn't. The comctl32.lib is a real common one. It contains all the 'Common Controls', which are things like the Tab Control, Tree View Control, Progress Bar Control, and a bunch of others. These are basically controls that are just a bit more sophisticated than the Standard Windows Controls such as labels, text boxes, and combo boxes. To find where in the documentation one is told which libraries are needed for a specific function call, look up InitCommonControlsEx() on MSDN, and near the bottom it will tell you which library the code is in.
C Family languages aren't usually known for making things easy. If one were building that app in PowerBASIC, which is a very high performance dialect of Basic which creates Win32 exes or dlls, including the following would be enough to use InitCommonControlsEx() ...
In that build system the location of code for linking is specified right in the function declaration.
|
|
In that build system the location of code for linking is specified right in the function declaration.
Hi Fred,
Just wanted to let you know that I have not disappeared completely but I have been working on a "rush job", nothing to do with C++ programming, so I have not had time to work on this. Spending most of this weekend on it but need to spend time with the family as well so please be patient.
The rush job is on the hardware side of this project anyway!
Regards
Ian
Just wanted to let you know that I have not disappeared completely but I have been working on a "rush job", nothing to do with C++ programming, so I have not had time to work on this. Spending most of this weekend on it but need to spend time with the family as well so please be patient.
The rush job is on the hardware side of this project anyway!
Regards
Ian