Why EZGUI ?

When I first created EZGUI the goal was simply to make writing Windows applications using PowerBasic easier. The Windows (WIN32) API was difficult enough to work with, so something easier was needed.

But as I worked on EZGUI something changed over time. It wasn’t enough to simply be able to make programming easier. I wanted to be able to do more difficult tasks, even ones which did not have a simple solution using the Windows API.

Other third party developers chose to eventually build drag and drop front ends for the compiler to make designing the GUI easier, but I chose a different route. I wanted to be able to tap into the power of Windows and even more. I wanted programmers to be able to build software that others would find difficult or even nearly impossible to build.

One of the first things I had to deal with was, how do you build a drag and drop visual designer in the first place ? If you are a powerbasic programmer, you likely have followed discussions about this on the peer to peer forums and if so, you likely realize that this is not an easy task. Few even came close to being able to accomplish this task. Only a very few were able to learn enough to be able to actually build a real visual designer. The few third party designers currently available, demonstrate how difficult this task really is. Even my own Visual Designers for EZGUI started out very rudimentary at first. It was not until the EZGUI 4.0 Professional designer that I really started to be able to produce something decent.

Now you have to appreciate something important here. I did not simply build a Visual Designer. I built a GUI framework with all the basic functionality of a Designer built in. EZGUI 4.0 (and 5.0) has its own drag and drop engine, which works using its subclass engine. You can subclass any control you can create using an EZGUI command and let the drag and drop engine take over control of it. I wrote my own drag handle control which impliments the core drag and drop functionality in it. Visual Designers (and may other apps) really benefit from a real property listbox control, so I wrote my own. In EZGUI 5.0 I significantly improved the drag and drop engine, even adding the ability to drag hundreds of controls (drag rectangles) at one time smoothly and flicker free.

The interesting thing about all of this is how such advanced functionality is built into the GUI engine. Users of EZGUI can build there own drag and drop visual designers if they like. No other visual design tool for PowerBasic lets you do this.

More than drag and drop

EZGUI though is much more than drag and drop. It is about building complex user interfaces. The drag and drop engine is just one feature. Over time my goal shifted to providing a library which provided advanced functionality which simply put, does not exist in the WIN32 API’s. There is a reason Microsoft added the dot.net runtime and other frameworks (ie. MFC, GDI Plus). Many complex tasks simply were too difficult to do using the WIN32 API or they simply did not exist (as API’s). My goal was to create new features in the EZGUI framework, which were beyond what you normally would do using the Windows API. True some of these features may exist in GDI plus, dot.net, etc., but they were not easy to do using the WIN32 API’s alone. I wanted to build features into a framework, which did not depend upon the lastest dot.net framework or the latest version of Windows. I wanted to build a GUI framework which worked on many different versions of Windows.

Customization

Rather than always concentrate on higher level features, I found it advantageous to provide access to lower level features in Windows so one could more easily customize the user interface. This is why I added an ownerdraw and customdraw engine to EZGUI. This made things like 3D colored button controls easy to do. I added the ability to more easily customize the common dialogs and some of the common controls.

In the process I began to realize that there are a lot of low level features in Windows programmers may rarely take advantage of. For example, graphics are important, but low level graphics provide more choices for customization. So I built my own Canvas control. Originally it was for a simple drawing canvas, but I then tapped into the Windows DIB (device independent bitmap) engine and added a low level engine for fast manipulation of pixels. This lead to my building my own 2D Sprite engine. The Windows 32 has no such thing as a sprite engine and most code on the web using the WIN32 for doing sprite animation falls back on a transparent BitBlt or oldfashioned XOR style bitblts. I decided to write a low level sprite engine based on DIB’s. This allowed me to write an engine which would work on even legacy versions of Windows, like Windows 95. It also allowed me to add features like anti-aliasing and alphablending and frame animation.

I began to realize that it was valuable to not only provide easier access to the features in Windows (WIN32), but to provide my own features which would not be easy for a WIN32 programmer to emulate themselves. My sprite engine is proprietary and not based on anyone elses code. I designed it from scratch.

Doing things differently

I also chose to develop features which others might not even think of or consider. For example, the majority of code I saw on the web for OpenGL examples were for a single opengl window only. So I decided to build my own OpenGL custom control. A real control, which can have multiple instances (as children like any other control) on a parent form. Why shouldn’t opengl be used in a real control, I asked myself. DirectX is basicly for a single window or full screen. Opengl was better suited for building a real control, which is why I chose Opengl. I also chose the route of building a scripting language into a control, rather than design a 3D command set. A scripting language provided an easier to way to define a 3D language. No API’s were needed. I simply added new keywords to the script language to expand it.

I also found that it was good to encourage users of my GUI engine to design user interfaces which are unique to their own needs. Rather than encourage carbon copies of each other, I wanted to provide the tools for endless ways to customize an application. So rather than build a bunch of high level custom controls which are pretty fixed in their use, I wanted to provide standard controls with an almost endless variety of ways to customize them. It is easy for example to convert a normal listbox control into one with checkboxes, using EZGUI’s simplified ownerdraw command set. Even the advanced ownerdraw engine can be used to create hundreds of uniquely different custom controls.

EZGUI’s Canvas control with sprite engine is not simply some kind of game engine. It was designed for building business oriented solutions. The Canvas control is so versatile it allows you to build all sorts of unique custom controls to solve all sorts of problems.

Power features

EZGUI also has many power features. For example I added the ability to define a form so it can generate a complex window region using a bitmap background image so you can have non-rectangular forms which looked skinned. EZGUI 5.0 has an improved version which is very fast in calculating the region, it can automatically handle drawing the background bitmap image. This window region engine was also implimented for some of the controls which are graphic in nature, such as the Canvas and Turtle graphic controls.

When I added a drag engine for the Listview and Treeview controls (drag items within the control or to other windows), one fetaure which was necessary but the WIN32 API does not provide is autoscrolling of the control. Without autoscrolling, drag and drop is useless for these controls and the feature did not exists in Windows, so I built my own engine to do it.

EZGUI has its own Thread engine for worker (non-GUI) threads and it was designed so worker threads can communicate with the primary GUI thread. EZGUI while providing thread support, was designed to prevent abuse of threads. A certain threading model is used which from my research is best suited to building applications which support threads.

EZGUI has its own unique Layer engine, which is used when implimenting tab controls. It also has uses beyond tab controls, since it is not tied to the tab control. Much like graphic editors can put objects on different layers and show and hide them based on their layer, EZGUI provides a layer engine for controls.

There are many more features than I can discuss here, but the GUI engine has many unique engines designed to push the power of Windows development.