...One article to rule them all, One article to find them,
One article to bring them all, and in the Windows bind them
In the Land of Unicode, where the bits do fly.
(With respect to J.R.R. Tolkien)
Introduction
Long ago I had a dream: create a program which allows users fine-grained control of MIDI events easier than other editors. For me fate seemed to forever extend, but after being sidetracked by an even more interesting project (if you ever wondered about humanity’s changing conception of God three-thousand years ago, or how religion and science were intimately connected back then, check out my work – you won’t be disappointed) I was able to return to coding.
One of the twists and turns of the editor brought about a Windows wrapper, and I documented it earlier, poorly. I’m writing this to do a better job, as well as update the explanations to the newest version of the code, and make the writings into something I’m proud of, even though with .Net, WTL, and all the other options now available, demand may not be high.
My creation, named ‘DWinLib,’ incorporates several interesting features. People who are fond of mucking around with the guts of the Windows API, or just like seeing how things work, will enjoy some of the information. And if you are curious, the ‘D’ can stand for ‘David’s’, ‘Dandy,’ ‘Delightful,’ or any other wonderful ‘D’ word you want to interject. In my head it is pronounced ‘Duh Win Lib,’ in a bad Brooklyn-mobster-style stereotyped accent.
What’s In It For Me, You Ask
Many interesting items are tucked in DWinLib. Depending upon your experience, some of them will be more captivating than others.
Personally, two main reasons exist for sharing these articles. First, I believe frameworks of this nature are interesting. After all, the programming challenge kept me coding, even when the rewrite process seemed interminable. For those who share my fascination, I hope this overview is useful.
The second reason for sharing is no other Windows wrapper presentations I’m aware of explains how to wrap child controls easily, nor what is needed to incorporate callbacks for event handlers. Perhaps the knowledge will be beneficial to you.
Moving on to the tangible results, one advantage of DWinLib is resource editors aren’t required. Items derived from DwlControlWin automatically get an ID, which DWinLib processes. The only thing necessary is writing the handling code and telling the control to use it. You must still programatically lay out how things will appear, but if you don’t possess a resource editor, eliminating ID gruntwork greatly simplifies your job. (Later in my endeavors I learned about a free resource editor, enabling you to more easily create programs which don’t take advantage of WinControl processing if you want to go that way).
Another benefit of DWinLib is compiler independency. Visual Studio, DevC, Borland, and other standard C++ compilers are capable of building the code.
If you know C++ programming, a fun aspect of this library is you can easily see what is needed to wrap the Windows API. For those who are still unfamiliar with the language, you will get a better feel for C++ and Microsoft’s programming framework while working your way through the examples.
Another advantage is it is the only wrapper I know of which allows true multiple inheritance with DWinLib objects. I was told that should be bolded, so DWinLib objects can use multiple inheritance. Of course, you could not inherit from two classes with independent window procedures and have the program work correctly, as the basic premise is unsound.
In a semi-related topic, DWinLib allows creating windows on the stack rather than on the heap. A long time has transpired since I last did this, but I seem to remember doing so for a modal dialog box which died upon closing. If I have a chance I’ll create an example, and maybe other instances of applicability will come to mind.
At one time DWinLib allowed you to make flicker-free applications more easily than other frameworks. This is still true for those using the Windows classic theme. Ever since XP, a lot of window flicker when resizing cannot be eliminated because Microsoft never updated some of the common controls to stop the double painting happening on the WM_PAINT and WM_ERASEBKGND
An example of the flicker I’m discussing is visible on the scroll bar at the right of this browser window, if you are using a standard layout. Resize the window from the left edge. The scroll bar appears to jump erratically. In windows with dockers on the right, this jumping can be annoying. I haven’t been able to figure out how to overcome this behavior in Windows 7, but remember being particularly pleased when I eliminated the flicker in earlier versions of Windows because those programs ‘just felt right’ during the resize operation.
Other benefits exist to DWinLib, and we will look at many of them in these writings, but the most important one from my perspective is the framework makes Windows programming more fun.
Comparatively Framed
There are several frameworks and products which may be used to wrap Windows. Here is a summary of the ones I remember seeing, or had pointed out to me.
Windows Specific Products:
- .NET - Microsoft’s masterpiece, programs written in it are interpreted at runtime to execute. This requires .Net to be installed. As far as I know, for the greatest productivity with it you need Visual Studio, although Borland once had a programming environment oriented around it, which seems to have been inherited by Embarcadero Technologies. Mono is another option for creating and executing .Net code.
- MFC - The grandmother of all frameworks (almost). To use MFC on a real-world app requires the (discontinued?) $300 version of VS, in order to get the resource editor. If you want to statically link MFC, you will need the $800 version of VS. (I’m uncertain about these prices, because Visual Studio’s price structure changed with the 2010 edition, and the standard edition no longer seems to be offered.)
- Visual Class Library (VCL) - At one time you could get Borland’s Personal Edition for $50, but no more. The lowest entry price seems to be $199. Borland left a bad taste in my mouth once (and is the reason for the birth of DWinLib). I won’t let it happen again. (Embarcadero seems to really care about their product now, so disregard my bitchiness if that route intrigues you. C++ Builder was very fun to program in, and I’m glad it was my first C++ tool.)
Windows Specific Frameworks:
- Visual Component Framework (VCF) - Jim Crafton and his crew put a phenomenal amount of work into this. Threading libraries, graphics libraries, and a whole slew of other stuff are included. There are even hints of a Rapid Application Development framework. It is also cross-platform compatible. But I couldn’t find much of an overview on its inner workings.
- Relisoft’s Generic Windows Wrapper - One of the first places I learned about creating Windows API wrappers.
- Oluseyi Sonaiya’s Window Wrapper - Another resource.
- David Nash’s SDI Framework - Nash’s contribution to this field is impressive, since his creation now handles MDI! Also, David is a great guy, and I’m not saying that just because of my familiarity with the first name! (He helped me come to grips with the intricacies of Windows’ LRESULT data type, as well as pointing out in a big way what was needed to make DWinLib cross-compiler compatible. I.E., he is did the initial port from Borland C++ Builder to Visual Studio, for which huge thanks are given.)
- Win32 Generics wrapper - but the site doesn’t appear to show you how it is accomplished. In addition, high-level template magic is required to perform the vast majority of its tricks.
- WTL - For those who can’t get enough of templates. Its supporters sing great praises.
(I believe all of the Windows specific frameworks listed require you to assign and process control IDs yourself if you want to handle child controls. Or you will need to develop your own solution to do this in an easier manner. DWinLib does not have that requirement. I may be wrong regarding WTL.)
Cross-Platform:
- GTK - This drastically evolved since my first perusal, because I once said their example is not ‘objectified’ in the OOP meaning of the word. I can’t say that any longer.
- wxWidgets - I like this better than most, as the design appears to be a fairly clean. Unfortunately, I ran some programs based upon this long ago, and a few of the ‘controls’ did not work as I expected them to. When I contacted the author, I was told the problem was with wxWidgets which couldn’t be overcome. I do not know if those quirks have been fixed, but due to the time that has passed, I suspect they have been.)
- QT - From my reading, this is one of the cleanest alternatives, but is even worse than MFC because of the
$1,500 $3,695 price tag for a license (the last time I found one listed), unless you make your application OpenSource - OUCH!
An Overview to an End
I once tried to fit all of the information in the following articles into one document. There was too much stuff for my mind to grok, so I’m breaking everything into smaller blocks, linkification style (kinda like book chapters, or as close to them as I can get in HTML with the least amount of work). Hopefully this approach helps others comprehend everything more easily.
Let us ease into our task by setting up Visual Studio and compiling a very minimal windows wrapper. For programmers creating something extremely simple, that version may do the job, but if your program is so straightforward a pure API adaptation will almost be as easy. As you can guess by the description, the writing contains some of the steps needed for getting Visual Studio up and running, which even beginners creating non-DWinLib programs might benefit from.
As you will see upon reading, these articles were originally created for VSE 2005, which I no longer use. They have been updated to VSE 2008, with the older information left semi-intact. I don’t plan on upgrading to VS 2010 Express or 2012, as 2008 works for me, although the new C++0x/C++11 features will tempt silently, teasing my intellect to overrule my lack of time...
Once you’ve mastered a small program, the next item is the remaining things necessary for building a blank DWinLib program. The presentation would be incomplete without an overview of creating a small, but pretty useless program. Actually, it isn’t completely pointless. If you wonder how to move things around the screen with a mouse you can work out one answer by looking through the code.
Next, a discussion of DWinLib’s guts are in order. Curious to know the magic occurring when you press a button? Or maybe the mechanism which handles control ID processing behnd the scenes? Here’s the place to find out.
That covers the fundamentals of wrapping the Windows’ API, but two additional items are worth bringing up. A problem you will run into, even outside of DWinLib, is handling modal dialog boxes if you don’t have a resource editor. Without using CreateDialog, can the ‘Flashing Window’ effect be achieved when non-dialog-box areas of your program are clicked on? After some research I found the answer is ‘Yes,’ and this allows you to create dialog-like windows in the same manner as other windows inside of DWinLib.
And finally, the last thing to add is DWinLib is good for Unicode applications. To do so, set the ‘Character Set’ option to ‘Use Unicode Character Set’ in the project’s property pages in Visual Studio (or define ‘UNICODE’ and ‘_UNICODEwString’ type where you would use std::strings or std::wstrings. This typedef is in ‘DwlTypedefs.h’, and looks like the following:
#include <string>
typedef std::basic_string<TCHAR, std::char_traits<TCHAR>, std::allocator<TCHAR> > wString;
This expands to the same thing as std::string or std::wstring in VCE, depending upon what TCHAR becomes due to the definition or non-definition of UNICODE.
Other routines have been written to make dealing with ASCII and UTF16 issues easier. For examples, look at the code in the DwlAsciiAndUnicodeFileWrapper DwlFileHistory units (which automate some of the difficulties you will face with those items if you take the tasks upon yourself from scratch). Also peruse a few of the functions in DwlUtilities, which allow you to perform some numerical conversions regardless of whether your program is compiled as UNICODE or non-UNICODE. One last goody in this regard: if you have a string which you know is needed as both UTF-16 and ASCII within your code, use the DwlContainedString wrapping class, defined in DwlUtilities. As noted in the header and before the class body, there are limitations to its use, but for those who don’t have to deal with locales and foreign language characters the class may be exactly what is needed.
An additional item worth noting is the ‘PrecompiledHeaders.h’ file is designed to be the first one processed by the preprocessor. It takes care of the Windows includes for the project, as well as any other items you may desire. Once a unit of your project is stable, #include it in the ‘CompletedUnits.h’ file (which is ‘include’d by ‘PrecompiledHeaders.h’), and if you kept the precompiled headers working as in the sample programs, build times will be considerably reduced. (For another method of reducing compile times, which I have used in my own projects, check out my Two-thirds of a pimpl and a grin article. For those who don’t need full pimpls, but get tired of waiting on compiles, that pattern may ease some of your suffering.)
In addition, the last time I played with Dev-C++, true Unicode applications were impossible due to a lack of the Windows ‘c0w32w.lib’ file. All of the strings can be Unicode in a program compiled with Dev-C++, but you will not be able to link to wWinMain, which a true Unicode application calls as the entry point. (Even though VSE doesn’t seem to have a ‘c0w32w.lib’ file, the correct Unicode entry point is called.)
And with that, the end of this DWinLib overview is reached. I hope this will be of use to you in the future, and wish you the best with your endeavors, no matter what framework you choose.
The End
(PS - The MIDI editor based upon DWinLib is also completed. There are plans for many improvements, but for a first edition (even though it’s in its fourth iteration), I’m proud I succeeded in my main goals! I’m particularly pleased with the way all the data windows for each track are synchronized to each other, which I haven’t seen anywhere else.)
History
- 2/13/2013 - Began updating entire series of articles to represent DWinLib 3.01.
- 5/8/2010 - Updated core code to properly handle MDI applications, use Thread Local Storage, and several other things I’m probably forgetting. Started the process of consolidating all old articles onto ‘David O’Neil’ account.
- 4/11/2006 - Completely restructured presentation. Simplified accelerator table inclusion - it’s now always included in a project.
- 2/24/2006 - Removed dead link and added link to modal dialog creation instructions. Also updated the zip file to reflect small changes in WinButton unit.
- 2/20/2006 - Added link to a minimal window wrapper example.
- 2/19/2006 - Updated DWinLib for 64-bit compatibility. I have not tested a 64 bit build, therefore please give your feedback on any missed items if you create a 64 bit application with DWinLib.
- 1/27/2006 - No wars have yet erupted over the use of DWinLib. It is hopeful that this trend will continue.
