Let me start with why I designed EZGUI the way I did. No matter what anyone says, writing Windows applications is not easy. For those who are engulfed in writing software using mainstream development tools (aka. Visual Studio) everything revolves around the development environment. From intellisense to drag and drop design, the idea appears to be “make things easier for the programmer”. I agree with the sentiment, but disagree with the method.
For programmers like myself who are engulfed into the world of the WIN32 API’s, programming can be just as complex. The Windows API is by no means simple. I recently downloaded two of the better Visual Designers (demos) created by the PowerBasic community and I have seriously considered how they differ from the approach I have taken with EZGUI. One designer attempts to emulate classic Visual Basic in many ways, while the other appears to be taking some cues from Visual Studio, with a design environment similar to Microsofts Blend designer. I was impressed with the designer which emulates Blend, but at times I found it bit overwhelming, which is the same experience I have felt using Blend with XAML. I have a good bit of experience with graphic designers for 2D and 3D drawing and for me, I just don’t view visual design of a graphic user interface to be the same thing and I prefer the more old fashioned classic Visual Basic style of laying out of forms. So in this case something more akin to Visual Basic is likely more user friendly.
Now as far as working with code, the two worlds I have to compare are the WIN32 world of PowerBasic developers and the Object Oriented World of Visual Studio. I don’t think WIN32 is easy, but compared to all the OOP stuff in Visual Basic (dot.net) and the huge dot.net framework, even the complex WIN32 is easier in my opinion. If you want some of my feelings about OOP read some of my other blog posts ( ie. http://cwsof.com/blog/?p=612 )
So back to PowerBasic and the WIN32
The Visual Designers for PowerBasic which have been developed, do a great job of building a powerful front end. One weakness, in my opinion, though is their dependency upon the Windows API and WIN32 coding. As applications get larger and larger with more complex user interfaces, I find that the WIN32 API’s are like a dangerous iceburg just waiting underneath the water ready to sink the ship. When working with the Windows API, I don’t want any surprises. This means that I personally am more inclined to want to build reusable library code and use it, rather than keep writing (or generating) more WIN32 API code. EZGUI was not originally designed to be a commercial product. It was designed as an inhouse library so I could keep myself as far away from the Windows API as possible. To me this was a more reliable method of coding.
If there is one thing I put far above “ease of use” in my software, it is reliability. I like to use the term “solid as a rock” when I describe my goals for EZGUI. No matter how fancy the user interface or the tools we use to build them, software has to be reliable. This is one of the reasons I don’t like the WIN32 API’s because of the huge set of include (header) files required. One slight change in a new version of the headers and you can break a lot of code. This is why when I created EZGUI using PowerBasic, when I got started using PowerBasic 6.0 I determined to keep the original header files (includes) from that compiler as my core headers. Then as I needed anything which may be missing, I modified my own include files, rather than use the new versions provided with the compiler. I didn’t want any surprises. Also I also determines to write all my own code for the library. No copying others code (even open source or freeware) to save time either. I had to fully understand all the stuff I was doing with the Windows API, before I added new code to EZGUI’s runtime. The library had to be rock solid, “no surprises”.
The Windows API is also not intuitive, in my opinion. Tasks which should have been easy, often are complex or tedious. Why couldn’t the API’s be simpler and easier to use ?
To be honest, I find it confusing that most of the third party developers of Visual Designers for PowerBasic, have preferred to generate SDK (pure WIN32 code, much like old fashioned C) style code, rather than to take advantage of the GUI command set built into the compiler (called DDT or Dynamic Dialog Tools) which does a decent job of simplifying the Windows API and it produces more reliable code in my opinion (it may be simple, but it just works). There needs to be a balance between access to the power of the Windows API and ease of use and reliability. DDT does some nice tricks to make coding easier to read and reliable.
I have considered building a full Visual Designer for use with DDT, but I really don’t want to compete directly with the PowerBasic PB Forms designer. I have a utility designer I sell for generating DDT code, but that is as far as I currently plan to go with DDT. DDT does its job well and PB Forms supports a good portion of the PowerBasic users. For me, I chose a totally different route.
A GUI Framework
I don’t find working with the Windows API, directly, reliable, so building a Visual Designer which concentrates more on the drag and drop experience which generates pure WIN32 code is out of the question. PowerBasics DDT GUI command set is quite usable for many smaller to medium sized applications which have a minimal user interface, so there is little reason for me try to out do PowerBasics own PB Forms designer for those users.
My own needs and goals are far more extensive than that. I wanted to be able to build as large an application as I wanted, with as complex a user interface as possible. One goal was that I didn’t want to be dependent upon a bunch of third party custom controls (like classic Visual Basic programmers). I wanted everything to be possible with just one system. It had to be easy to use, powerful, extensible, reliable and have as small a footprint as possible. While a drag and drop design environment was vital, the designer experience would not be the key to the product. The real power would be in the GUI engine or framework. The framework would be so easy to work with that one could even write applications without the benefit of a Visual Designer if need be (and a number of my customers actually prefer to write apps that way). How many programmers today can write a complex Windows application using just a simple code editor, a single source code file for most of the source code and be able to design the user interface only with code ?
With this idea, EZGUI was born. The Visual Studio world has its framework, dot.net, so why shouldn’t the PowerBasic community have its own GUI framework ? Well, it does and it is called EZGUI (for Easy GUI). But there is one problem ! The Windows API is a complex and large set of API’s. How can you keep a GUI framework small and tight, while tapping into as many features as possible ? I decided on the old 80/20 rule (or close to that ratio). The principle goes like this. That 80 percent of users only use about 20 percent of the features available. I found this true with using the Windows API. So in my mind, the goal was to try to tap into that smaller 20 percent of the Windows API, so it would provide mostly what is needed for 80 percent or more of what a developer needs, to be able to build a complex user interface.
There was a key though which was important. What if a developer needed something not found in that 20 percent ? This is why making the GUI framework extensible was vital. I designed it so it was easy to integrate pure WIN32 code when it was necessary to solve a problem. This is exactly what my customers have done. I encourage them to use only the framework if possible, but in the few instances where something they needed was missing, I explain to them how to extend the GUI framework using the WIN32 API. I even show them how to avoid having to use any of the WIN32 header (include) files when they do this. EZGUI has its own header file which basically has the entire command set declared in it. Most applications can be written without the need for a single Windows API header file. This was by design. EZGUI applications compile very fast because they are not dependent upon a huge number of API headers. The primary EZGUI header file is only 92 KB in size. That is tiny compared to the typical WIN32 application requirements. Previous versions of PowerBasic put the majority of API include (header) code in a single file about 1 megabyte in size. The current version (10.0) uses multiple header files more similarly layed out like Microsofts C headers and it amounts to more than 1 megabyte in size and spans multiple files. EZGUI has its entire command set declares in just three include files which total about 97 Kilobytes in size (primary one is 92 KB and the other two are very small). That is one tenth the size of the include files needed using any other methods of coding using PowerBasic. Compile time is significantly faster and less prone to error.
Compile times for EZGUI applications are very fast, because there is minimal code to compile. Another factor contributes to faster compile times. That is the unique GUI command set in EZGUI. Unlike the WIN32 API’s many tasks only require a single line of code and the syntax of most EZGUI commands have been designed for minimal characters to be typed into the code editor. For example, the code necessary to create a Toolbar control, with all the buttons defined using one of the built in system Bitmaps would look like this:
EZ_Toolbar 50, “#LargeSTD”, “BBBBBBBBB|{New File |Open|Save|Close|Cut|Copy|Paste|Print|Redo}”, “ALONF24X24{1}VT”
By defining certain aspects of the toolbar using simple macro property strings, the amount of code is minimal. The GUI engine handles interpreting the property strings into meaningful API calls internally. The above code defines a toolbar using the large standard bitmap system images, with nine buttons, each with a text string in them and defaults to using the images (indexes) in sequential order for the image icons. This command can even define image indexes which are not sequential, using a single character per button. The images are 24 x 24 pixels and the last string parameter defines all the properties of this control.
Better than XAML, the GUI command set allows you to manually define a user interface but using a syntax which requires minimal code, but is still dynamic since these are actual sub/function calls into the GUI framework. The parameters could be passed variables instead.
Now new EZGUI users actually find there is a difficult learning curve at first. Not because EZGUI was not designed to be easy to use, but because it is so different than what they may have been used to. Once they understand the common syntax of the command set and how things work, often the learning cycle speeds up significantly.
The secret to a GUI framework
One of the secrets to the EZGUI framework is something so simple and obvious, programmers often fail to appreciate its importance. As programmers we get so used to “plug and play” we may find ourselves not wanting to write much code. It is so much easier to just pop in that third party custom control (typically OCX with Visual Studio) rather than create something ourselves. Maybe we want the Visual Designer to do all the work and simply add a little code here and there in some event routines. But you may say, “I don’t have time to write a custom control from scratch” and I would agree with you. But there are problems in being too dependent upon a number of third party controls. Every new third part component added to a project, adds the possibility of some incompatibility between components. Second, most component models today are based on COM (ie. OCX) so the components may need to be registered with the operating system, which prevents apps from being truly portable. The size of the applications also tends to increase significantly. So what I decided for EZGUI was this. First if a third party custom control must be used, I would encourage users to opt for those in DLL form which don’t need any special kind of system registration. This would make them portable, so you can just copy and run. EZGUI’s own framework is built of just DLL’s and they are all portable. Just copy them into the same folder as the application and they will work.
Second, why not design the GUI framework itself to have an extensive set of customization features built in, so you could simply create new controls by using existing ones and simply use some sort of customization feature. Actually, this was a perfect thing to impliment, since the WIN32 API’s already had this built in (albeit not that easy to do), so I could tap into these features in the Windows API, make them easier to use so developers would have almost limitless choices for customization. I chose to impliment both OwnerDraw and CustomDraw for controls which supported them. I provided the mechanisms to use these methods of customization, such as a graphic drawing engine.
The key to EZGUI’s nearly limitless potential is customization. Add to this, access to many low level features in Windows, but made easier, such as subclassing, superclassing, using worker threads and syncronization (critical sections). There are three different Graphic engines, one for the Canvas control, one for the printer and the other for low level drawning into any Windows DC (this is used for ownerdraw).
Filling in the gaps
The interesting thing about the Windows API is that while there is a great deal of power in it, often it is either not easy to accomplish certain tasks or there is no medium or high level ways to accomplish some tasks, which really should have been in the operating system from the beginning.
With EZGUI, I chose to fill in some of those gaps. First, tasks which were a bit difficult using the Windows API’s, I found ways to simplify them or even automate them. For example, there are two sets of ownerdraw commands in EZGUI. Once is more low level, but still much easier than using the Windows API alone. There is also a “simplified” version of the ownerdraw command set, which with just one line of code allows you to draw using a variety of ownerdraw features. For example, I impliment a simplified ownerdraw command set for 2D and 3D colored button controls. Customization need not always be overly complicated.
But the customization features alone were not enough. There were many things missing in the Windows API or at least no medium or high level ways to accomplish some tasks. These I had to build myself. I took on this challenge in a variety of ways. First, I created new controls which simply didn’t exist in Windows. True some of these may exist in the dot.net world, but that is because they are using a large GUI framework, instead of the Windows (WIN32) API. Somebody had to create these new controls, because they didn’t exist before.
I started with easier control concepts, but progressively added more and more to handle a variety of common tasks. Again the the 80/20 rule applied. I wanted new controls which were more generic in their use, but would cover a larger variety of common tasks. I created an MCI control, because multimedia is important. I created my own Canvas control because it was the most useful graphic oriented control to create. I wrote my own Files Listbox and Property Listbox controls.
More was needed though
The downside to the 80/20 rule is that programmers could easily get into a rut using only the more popular and simpler controls. There was a need to actually break the 80/20 rule and find ways to encourage programmers to push the envelope when it comes to user interfaces. One of the downsides of the new Metro interface in Windows 8 is that it tends to encourage conformity, when at times there is a need for something new and fresh which better handles the task. It is not a matter of simply breaking the rules just for the sake of breaking the rules. At times something better may really be needed. To illustrate, most birds fly since that is the norm for birds, but penguins don’t. Why not ? Because they serve a different purpose. They are birds, but they swim in the water like other birds fly in the air. They are a beautiful bird in their own right, but they are different and in their case different works, because they have a different purpose. So too with designing user interfaces. Doing something different just because it is different does not make sense. But what happens when there is a better design, by doing it differently ? Maybe the different task or purpose requires something different, something better.
While in versions 1.0 to 3.0 of EZGUI, I concentrated on the 80/20 rule, with EZGUI versions 4.0 and 5.0 it was time to break the mold. It was time to provide the tools so developers could push the envelope a bit. At a time when the devices we run Windows on are changing more and more, there is a need for more choices in software, not less.
While previous versions of EZGUI contained a built in drag and drop command set, it was time to push it beyond the basics. I needed the drag and drop for building my visual designer, but my customers also benefit from using it too to build WYSIWYG style applications. I improved the drag engine so it could drag multiple objects (controls) at one time, with speed and minimal flicker. Try selecting a couple hundred controls in your favorite designer and drag them all around together and see how difficult a task that is. This is a very useful feature for building enterprise and commercial applications which need the ability to do real drag and drop.
More and more PC users are using multiple monitor setups, so it was important to add that functionality. Because of the different device sizes which applications may have to run on, I added a new AutoSize engine for automatically resizing controls when a Form changes size. This autosize engine is very sophisticated, even with some unique customization features to handle many of those situations where a simple rules based system won’t handle it. I added a number of features to improve the graphics engine. Starting with EZGUI 4.0 I added a 2D sprite engine. Sprites have been around since the days of the Commodore 64 and Atari home computers, so why didn’t Windows have them ? I built my own sprite engine and embeded it into my Canvas control. Sprites can do more than just games, but have many business applications as well. EZGUI does this also without the need for DirectX too.
In EZGUI 5.0 I added a new superclassing engine, which I used to build the latest new control which is the glCanvas control, a hybrid control based on my Canvas control but which adds a 3D scripting language on top to display OpenGL based 3D objects. Now 3D is easier than ever. No need to learn the OpenGL API, the control handles it all via its extensive 3D scripting language.
The point is that, a GUI framework like EZGUI pushes the limit of software development, but it has one more significant benefit.
Windows 8, the desktop and tablets
With Windows 8, all the emphasis is on the Metro (or Windows Store) side of Windows. But the desktop is not only still alive, it can be more powerful than ever. The challenge of building Windows 8 desktop applications, which are not only fast and fluid, but are also emersive and exciting is being able to break out of the mold and being able to design something totally different and something dynamic as well. EZGUI was designed for this challenge (and more will be added in a future version). First, the entire EZGUI framework is only about 1 megabyte in size. The core runtime engine DLL is only 700 KB. Because EZGUI uses only DLL’s in its framework it is portable and you can create applications where you simply copy and run. Because the size of framework is so small and the executables which use the framework are significantly smaller too, you can build applications with an amazingly small footprint. This makes a difference when drive space may be a premium on a tablet. Applications can even be run using SkyDrive. Just copy and run, no installation needed. How about installing them on a jump drive and run anywhere ?
One problem many face is how do you support older legacy computers, while still support Windows 8 ? Applications built using EZGUI will also run on a variety of versions of Windows. Because the GUI framework was designed to be as universal as possible, it will run on Windows XP to Windows 8, dynamically changing itself when possible for the latest versions of Windows. Actually EZGUI applications can run even on Windows 95/98/ME and 2000 also (some features only available on 98 or later and some only on XP and later). System requirements for applications are minimal, so you can write software which will run on more Windows devices, even with as little memory as 256 megabytes or less. How many XP computers are still being used, even in the Enterprise, which only have 256 meg ram ? EZGUI applications can handle it.
At a time when software needs to be more dynamic and be able to run on a greater variety of devices (x86 only though), EZGUI 5.0 provides an amazingly large feature set but with a minimal footprint. All of this is only possible with a GUI framework. This is why I chose to build a framework, rather than simply a Visual Designer front end. But don’t worry. EZGUI comes with its own drag and drop Visual Designer, designed specifically for this unique framework. So whether you are designing for Windows XP, Vista, Windows 7 or Windows 8, EZGUI provides a framework up to the task. EZGUI keeps the desktop alive in Windows 8 and makes writing small footprint applications for tablets much easier.
