EZGUI – A GUI Framework! Why needed ?
Microsofts GUI Frameworks.
In trying to understand Windows programming better, I have been researching dot.net languages a bit. I have a book on Visual Basic .NET , so I decided to browse a number of topics that interested me. One of them was developing using Windows Forms. A few statements by the author in this book shed some real light on the changes over the years with Microsoft languages when it comes to user interfaces.
The author mentioned how one developed Windows applications before dot.net. He mentions three ways (using C++):
- MFC (Microsoft Foundation Classes)
- ATL
- “down and dirty Win32”
MFC and other early frameworks likely were designed because most programmers found using the Windows API directly far to complex and difficult for creating Windows applications. Now as a Windows API programmer myself I find that the Windows API at its core (window classes, window procedures, message loop) is not really that difficult to understand. The problem lay with the more complex and difficult tasks. It is relatively easy to create a Listview control for example. But to make the listview do drag and drop and to handle dragging and dropping of items is not so easy. So it was obvious that some kind of higher level framework was needed, so along came MFC. MFC had its issues, since now you had to make sure you had the proper C runtimes (MFC) and it was higher in level than the Windows API, but it was not that high level so there still was a lot to be desired.
The Windows API is “down and dirty”.
It is interesting the author of the book I read, refered to using the Windows API as getting “down and dirty”. Maybe this explains why dot.net was Microsofts next step. Programmers need a higher level framework. The question though is, does the dot.net framework and its languages (VB.NET, C#) really make programming Windows applications easier and faster ? Yes and No, in my opinion. Yes in that it is higher level, but possibly no because it introduces a layer on top of the Windows API which is foreign to it. What do I mean ? At least VB.NET too me is foreign compared to the Windows API. Sure I appreciate the need to be more high level, but going from Window classes (not the same as a C class) and messaging to objects is a big jump. I find that object coding adds too much extra code, that good old procedural style coding (which can be used with the Windows API). Even as an experienced API programmer I find myself having difficulty trying to see what is really happening in OOP WinForms code as related to the API.
Now I agree that a GUI framework can make a big difference. My own EZGUI is a GUI framework, if you will (I prefer to call it a GUI Engine). But a GUI framework, while making things easier for a programmer should parallel the Windows API, not turn it upside down like dot.net does. A GUI framework should be designed, not to totally replace the Windows API, but to work in concert with it. For example, while with EZGUI I often mention that you can write applications without using a single API call (because it is so feature rich), this does not mean I discourage using the API with EZGUI. You see, no matter how large a framework one develops, I seriously doubt it could ever cover every single feature found in the Windows API. A proper GUI framework should encourage integration of the Windows API with it, rather than discourage it.
So why a GUI framework if the Windows API is so useful and should be learned ?
The Windows API simply put is huge. No one programmer could have absolute knowledge of ever aspect of the Windows API. The real issue is how much of the Windows API is required in the average application ? I can’t give you an exact ratio, but if I were to make an educated guess I would venture to say that most Windows applications only use about 5% or less of the Windows API. So the trick is to create a GUI engine which concentrates on that 5%, rather than trying to handle all of the API. Now the problem with that 5% of the API, is that it is not a matter of just creating simpler wrappers for that 5%. Actually a set of wrappers is what I believe the approach MFC takes and that obviously didn’t solve the problem. So how does one build the proper GUI framework for Windows ? One can not forget the value of the entire Windows API (one reason managed code doesn’t work IMO) and the framework must still encourage using the Windows API. Again the key is understanding this 5% ratio.
Rather than API wrappers, view the API from the viewpoint of Tasks.
It is this very approach that I took when creating EZGUI. Using the Windows API alone doesn’t work because one can get bogged down coding and the probability of errors when using the API alone is actually quite great (aka. things like resource leaks, failed API calls from bad parameters, etc.). Making a set of wrappers like MFC doesn’t work and you can’t wrap the entire Windows API anyway. But how about a different approach ?
When I first created EZGUI 1.0 I started from a simple premise. Rather than view programming from an API point of view, why not view programming from a task point of view. This was actually easy. I simply asked myself, what tasks did I need for the majority of applications I would write ? They all need Forms, so I needed a command set to create forms. They all needed the basic controls such as the Button, Text, Label, etc. so I added commands for creating the Standard Window controls. I actually didn’t support many of the common controls in EZGUI 1.0, so I chose only those which most applications used. EZGUI 1.0 only supports the ToolBar, Tab control, ProgressBar and UpDown (spinner) control. Those four controls were the most commonly used of the Common Controls.
It comes back to the idea of, if you support that 5% which all programmers use, then you can handle probably 80% to 90% of the tasks required to build a Windows application. Amazingly, the EZGUI 1.0 runtime DLL is only 122 KB in size. Now where in the world can you find a GUI framework which is only 122 KB today ? I knew that in succeeding versions of EZGUI I could continue to add features and to support more and more, so that rather than say 80% of required tasks supported it would grow to much more.
There is one problem with this approach though. If you create a GUI framework which totally eliminates the Windows API and discourages its use (ie. managed code), the 5% of features you support will always fall short. Programmers will always be seeing the missing features and it will prevent them from accomplishing what they want. Secondly, if the GUI framework is so foreign compared to the Windows API, then when a programmer does need to go beyond the framework, the Windows API will seem so foreign to them it will be more difficult for them to grasp how to integrate the two. I believe this may be the problem for some Visual Basic programmers (versions 1.0 to 6.0). When you compare the object oriented style of the VB framework to the Window classes and messaging syntax of the API it is like night and day.
So I realized that when I created EZGUI, it should be a powerful GUI framework and make programming easier, but never forget its roots of the Windows API. There should be no “black box” design where you can’t get around the frameworks limitations, but instead it should have a more open design which allows and even encourages integration of the Windows API. The rule of thumb was, “if EZGUI can’t do it, there should be easy integration of the Windows API to add it”.
This originally took the form is things like the hook procedures in EZGUI, where you could make a hook into its own internal window procedures so you could preprocess messages either before EZGUI did (to change how it worked) or after it did (to handle things EZGUI never processed at all). EZGUI provided commands for sending messages to controls, so I did not have to support every single API message. Even from its earliest roots in version 1.0 EZGUI had a subclassing engine so you could access any controls internal messages. That is pretty low level, yet I felt it was necessary. EZGUI should never prevent you from finding a solution and API integration is vital.
Even EZGUI’s event engine, while not exactly the same as window message processing, does minic the flow of window messaging so closely that even many of my customers who came from a DOS Basic background, found it easy enough to learn but in the long run they actually developed a better understanding for the Windows API and how it works. Often there would be a one to one correlation between EZGUI events and API notification messages. The only difference was that EZGUI did a little bit of the mundane low level processing for you so you could more easily concentrate how accomplish higher leve tasks, rather than low level mundane message processing.
It actually surprised my how many EZGUI users who had no knowledge of the Windows API, eventually learned quite a bit about the Windows API. Why was this ? Because EZGUI was so easy to use it made you productive almost immediately. You could build real Windows applications in short order. But in the few rare times when EZGUI couldn’t do what you wanted, one could more leisurely take the time to learn the few small things from the Windows API needed to solve the problem. Actually I often would post answers to their problems on my forums using some API code integrated with EZGUI code and explain what I was doing. Little, by little, EZGUI users started picking up more and more API terminology.
So why not simply just use the API alone ?
We come back to that concept of , “if you can find just the 5% of the API which is used 80% or 90% of the time” and then encorporate it into an easy to use GUI framework (which makes it even easier to use for beginners) you can get programmers to be more productive quicker. Also if that 5% also is a good bit of higher level code, you provide features which are not so obvious to those trying to learn the Windows API. A good example is drawing in Windows. It is so complex, because you have to remember to select objects in and out of DC’s (device contexts) and to make sure you leave a DC the way you found it. EZGUI’s drawing commands allow you to concentrate on just drawing, while it handles all the mundane API stuff for you. Yet it still allows more experienced programmers to integrate API graphic commands into EZGUI code.
Going beyond the Basics!
Where things get interesting with EZGUI is after the first version of it, I was starting to run out of the 5% common stuff as far as tasks. Now I began to start thinking beyond the box as they say. I started to get creative. EZGUI 2.0 introduced my first graphics engine which was my Turtle Graphics scripting engine (in a control). I added some of the more complex or less used Common Controls, such as the Listview , StatusBar and Trackbar controls. I began building my own drag and drop engine for use when creating WYSIWYG style applications, like a programming language Visual Designer (Form Editor) and added my new drag handle control. I also added the Richtext control (1.0).
In version 3.0 of EZGUI things started getting even more complex and more high level. I added more Common Controls such as the Treeview, Date-Time and Animation controls. Now I was deeply involved in developing my own custom controls and the EZGUI Canvas control was introduced. It was no ordinary canvas control but supported low level DIB section so you can could access pixel data directly. I added my own MCI control and Shape/Hot Spot control.
EZGUI 4.0 saw the biggest growth of any previous version and it began to go far beyond what the average PowerBasic programmer was doing. I introduced my proprietary 2D sprite engine to the Canvas control. The drag and drop engine and the visual designer now came into its own as well. I added three more common controls, the Calendar, Rebar and Pager controls. EZGUI finally got MDI (multiple document interface). Two new custom controls were introduced, the Files Listbox and Properties Listbox control. These two controls benefit from all the work I did in EZGUI’s ownerdraw engine. Customization was the key to EZGUI and things like ownerdraw, customdraw and even subclassing all made it possible to expand the GUI framework in ways one would not even have thought about.
EZGUI also handles things like threading, critical sections, precision timing, common dialogs (even customizing them), game looping.
EZGUI 5.0 adds more powerful features !
EZGUI 5.0 pushes the boundaries of application development. Not only does it add amazing new features like its new GLCanvas control (OpenGL based) with its own 3D scripting language, but EZGUI 5.0 is the epitome of one of the key concepts I have promoted from day one. Building upon the Windows API, both in low level and high level, so a programmer can leverage the power of the Windows API. The new GLCanvas control was actually created using EZGUI’s new superclassing engine. Superclassing is a powerful API contruct, which few ever learn how to master. EZGUI has its own superclassing engine, which makes it easy to create new custom controls based on existing one, while using the Windows API to expand upon them. You have to know the Windows API to be able to use EZGUI’s superclass engine. The point is that EZGUI handles the mundane for you, so you can concentrate on what really matters. You don’t have learn everything about superclassing to do it with EZGUI. It does the hardstuff for you. If know how to process window messages you can build your own superclass control. EZGUI even handles the hard stuff for you like instance data storage.
EZGUI as a GUI framework is quite unique. It shields you enough from the Windows API so you can be productive more quickly. Yet it emulates the Windows API (ie. events) just enough so you can get a real feel for working in a Windows environment, event if you were a DOS basic programmer. It provides many ways to integrate the Windows API as you gain confidence in your understanding of the Windows API. For advanced programmers it lets you leverage the Windows API, while handling much of the mundane stuff for you so you can still be productive. Lastly it even does things for you which are not easy to do, even for an experienced API programmer.
Combined with Powerbasic it is a powerful combination.
EZGUI is only designed for use with Powerbasic, but together you have a real powerhouse (really). EZGUI was written in Powerbasic (and calls the Windows API extensively internally) so you get a “lean and mean” (small footprint and fast) GUI engine. The EZGUI runtime in version 5.0 has a huge feature set, but is less than one megabyte in size. Compared to your dot.net runtimes today or even Visual Basics runtimes, this is tiny. EZGUI does things that VB can’t and you don’t need a bunch of OCX controls just to use the common controls or dialogs. And you aren’t going to find a 2D sprite engine or a 3D scripting language in VB. Yet, EZGUI is less than 1 meg in size. That is because it leverages the power of the Windows API.
Yes, EZGUI is an amazing GUI framework. So why not check out my web site and learn more about it.