EZGUI – why ?

Note:  My EZGUI software is not the EZGUI for use with Unity! My EZGUI has been around a lot longer and is for developing Windows applications.

Ok, I am biased !

I am the developer of EZGUI (for use with PowerBasic), so of course I am biased toward it.

So the question, why use EZGUI ?

I originally wrote EZGUI as an inhouse library so I didn’t have to mess with the Windows API all the time. It was written for me. No matter what anyone says, it takes a long time to learn the Windows API to the point where one is proficient with it. It really isn’t that complex once you get used to it, but the documentation is terrible and you really need to read a good book written by an expert if you want to make sense of the API. The other thing I don’t like about the Windows API is that it is very easy to make errors when coding which will literally crash your application (aka. GPF). Actually there are lot of easy errors one can make with the API, which can cause serious problems for your application and make it unstable.

Just think for a moment about all the great software out there written by the “big” software companies, which at times will crash or GPF in certain situations. If the big guys have trouble writing software which is crash proof, what about the small independent programmers like myself. So why did I start writing a library ? One, to make things easier to do. Second, the library code would be tested to the point where bugs would be much less common. You see, I like to write code which is not only bug free, but also which takes the initiative to prevent me from making more errors.

You see, the EZGUI 5.0 main runtime DLL is about 700 KB in size, which is quite small for what it contains, but did you realize that it would even be much, much smaller if I took out all the parameter checking code in it ? Most EZGUI routines test the parameters you pass to make sure that you are doing what you are suppose to. For example, with the API you can send a message to the wrong control class and it doesn’t know the difference. You are simply sending wrong values to Windows and what it does with it, you don’t want to know. With EZGUI, it actually tests the control to see what class it is, before acting upon it, so you don’t attempt to do something with the wrong control type.

EZGUI also test the values of the parameters to see whether they are within the range allowed. While a library like EZGUI can’t prevent all possible errors, it does decrease them significantly. If a parameter is bad, EZGUI may simply use the default values and in the worse case scenario, EZGUI will simply do nothing at all (ignore your command call), which at least doesn’t try to make Windows do something bad.

Another problem with the Windows API, I don’t like is how it handles memory and resources. Windows often requires you to create something (ie. a font) and then make sure you later delete or free it. EZGUI doesn’t need to do this. It tracks all such resources it uses and it will free them when your application terminates, if you forget to do it. EZGUI also is very efficient in how it uses resources and shares them as much as possible.

The other thing about Windows is that some tasks are just simply too complex for the average programmer to figure out and you have to write lots of code to accomplish the task. One good example is autoscrolling, when dragging items in a Listview or treeview control. Its hard enough to figure out how to impliment drag and drop in these controls, but the operating system has no built in autoscrolling for these controls. EZGUI, though provides such a feature, which can be implimented with just a couple lines of code. There are hundreds of lines of API code in the routines that do this in EZGUI. It requires a number of tricks, such as subclassing the control on the fly, handling drawing drag icons and sending messages back to the control itself when the cursor is in the position to require autoscrolling. It is very complex code to say the least.

By building an advanced library of routines, I can write Windows applications in half the time (or less) than it would take otherwise.

The other thing about EZGUI is that it is now in its fifth generate (version 5.0). In version 1.0 I spent most of the time learning the basics of the Windows API, so I could write a core engine. But in each new version, I was able to start digging into more and more complex stuff.  While EZGUI 1.0 had a few advanced features, like my Layer engine, later versions really pushed the limits of Windows application design.

In EZGUI 2.0 I ported over my Turtle Graphics engine into a custom control. I started digging into some of the common controls like the Listview and trackbars. I added richedit 1.0 support. I added some new drag and drop features, such my drag handle control and improved the subclassing engine. You see, the Visual Designers that come with each version of EZGUI are themselves EZGUI applications. Any hard to write features they require, were added to the EZGUI runtime engine, so no API calls have to be made by the designers.

Now with EZGUI 3.0 I added the Treeview, datetime and animation controls, plus a number of my own custom controls such as the Canvas, Shape/Hotspot and MCI control. The Canvas control is where I started to dig deeper into the GDI and graphics. I also started digging deeper into DIB sections, which are very powerful. I also added ownerdraw support and 3D colored buttons. EZGUI 3.0 is where Graphics started to become a big deal in the runtime engine.

EZGUI 4.0 though is where things really started to take shape. The Canvas control has the Sprite engine added to it. The sprite engine is a proprietary 2D animation engine, which is very fast, powerful and works on Windows 95 to Windows 7. The drag and drop engine had many new changes and the visual designer for the first time, really came into its own. The Smart Parser really made a big difference in the designer. I continued to add more graphic features and more ownerdraw features. I added a thread engine, critical sections and improved subclassing. I added new custom controls such as the Files Listbox and Properties Listbox controls. I added a game loop engine and high precision timers. The command grew significantly in this version.

By version 4.0, EZGUI was pushing the limits of Windows application design, so I wondered if I would be able to come up with anything new in the next version. I was no longer doing the simple stuff anymore. EZGUI 4.0 has features in it, which you will not find in any other visual design tool for use with PowerBasic. EZGUI’s graphic engine was always steps ahead of the PowerBasic DDT Graphic command set. I was even dabbling with stuff you only see in advanced graphic engine tools. EZGUI’s sprite engine is amazingly fast and without any hardware support. I did a benchmark of GDImage with 500 animated sprites and EZGUI 4.0’s sprite engine (which is also in my EZSprite product) and EZGUI’s sprite engine was significantly faster running 500 sprites. Only when GDImage resorted to hadrware support, did it run faster.

Now it is important to note, that one rule I have is “avoid the bleeding edge” when it comes to hardware, as much as possible. The reason is that I want my tools to be able to be used to create software which will run even on legacy PC’s. This saves money for my customers, since they don’t need the latest hardware. They can keep old legacy computers in use far longer than most others can.

Now when I started working on EZGUI 5.0, the question was “what’s left to do ?”

I was already pushing the limits for Windows application design, while still providing legacy PC support. EZGUI 5.0 brought big changes to my software. The Designer was significantly improved. The runtime now supported themes, multi-monitors, 3D OpenGL based animation, more advanced Graphics commands (like alphablending, image rotation, etc.) with even 22 built in image filters. I added new features to allow component design and custom control design. A new superclass engine was added. The list goes on !

The point is, that by the fifth generation of EZGUI, I am pushing the bounds of software development when using Powerbasic and most who browse this web site can’t even fully comprehend the power which is in EZGUI 5.0. The knowledge and experience about the Windows API that has gone into EZGUI 5.0 is far more than most realize. Now of course EZGUI has a real learning curve now, since it is a huge command set of its own, but the benefits are worth it.