EZGUI and the language of simplicity !
Computer programming is never easy. There are many challenges we face as programmers in trying to develop software quickly and efficiently. So why is EZGUI professional (current version is 5.0) so different than other methods of coding applications ?
EZGUI was designed with the idea of the “language of simplicity” .
What does that mean ? While I strongly believe in the value of a RAD environment, when it really comes down to it, building quality software depends upon coding. No RAD environment can replace good old code. Code is the glue the holds are application together. Why ?
Programmers can easily get into a mindset of viewing software from a technical point of view. Is the RAD environment they use easy to use ? How can I write as little code as possible ? But no matter what we as programmers have in mind as far as making life easier for ourselves, software is a tool used by our end users. It is designed to do tasks. Our end users think in terms of tasks, not in terms of technology. Does the software do the tasks the end user requires ?
I wrote custom software for local businesses for a number of years and one thing I learned was that I needed to think like my customers, rather than a programmer. One way I did this was by being task oriented. I viewed a software project simply as a set of tasks my customer needed to handle. This effected how I wrote code, because I had to break down the end users higher level tasks into smaller user interface tasks so I could build them exactly what they wanted. The ability to build quality reusable libraries which were task oriented, helped me write software faster and better because I could more easily customize it to exactly the way the wanted it.
The EZGUI runtime engine was designed based on this concept of being “task oriented” and “customization oriented”. When I used Visual Basic, I loved how easy it was to design an application. The RAD environment of Visual Basic was hard to beat. Where I had problems was when something I wanted to do was slightly out of the ordinary and it went beyond the VB “blackbox” of objects. Other VB programmers must have felt a similiar feeling since it was not uncommon to see VB’ers add Windows API code to their applications so they could go beyond the VB “blackbox”.
When developing EZGUI, I didn’t simply just start creating wrappers for the Windows API nor did I concentrate on the Visual Designer thinking the RAD environment would solve all the problems. I concentrated on tasks. Yes, I viewed EZGUI as a “task library”. It didn’t matter if a task was easy to impliment or hard to impliment. I simply asked myself, what if a programmer wanted to do “this or that” and I then proceeded to build a solution which allowed customization if possible, but was easy to use. This is why EZGUI became more than just a library. It became an engine, a GUI engine.
You see, some tasks may be simple enough so that you can write a simple function which does the task and is then finished. But the more I worked on EZGUI, the more I found that some tasks required a running engine which continued to work even after the initial request for the task. Let’s look at one example which well demonstrates this.
One day I was thinking about how does one build applications which are not rectangular windows, but are odded shaped. The first step was to find a way to make a window non-rectangular. This required a complex window region, but how do you generate that region ? Well, the shape of the window would be based on the background image, so it made sense to write a routine which could convert a Bitmap image into a complex window region and then to be able to pass that region to a window (form). But more is required here. Once you have your window region, you need to be able to draw the bitmap you used as the background, which means you have to be able to process a dialogs WM_PAINT routine. Now you needed an engine to handle that or you would have to code two different tasks, one to create the window region and the other to paint the form background. But this is one task, I decided, not two.
So how does EZGUI handle this ? Let’s look at some code:
PN$=EZ_LoadPicture("mediabg.bmp") EZ_ShapeFormToPicture PN$, -1 EZ_Form "MPLAY", FParent$, "EZGUI Media Player", 0, 0, 67.875, 20.9375, "C"
In the code above, I load a Bitmap and then with one command EZ_ShapeFormToPicture I tell EZGUI to store a bitmap for the next form created, convert it into a window region and when the form is created set the window region and then process the forms WM_PAINT routine and draw that bitmap to the forms background. Yes, two tasks became one.
It was this concept of “tasks” which molds how EZGUI was designed. This is where EZGUI has the advantage. It was designed to solve problems, to handle tasks and to allow customization of many of those tasks. This is why I has to be a GUI engine rather than simply a set of API wrappers. Some tasks are very complex and let’s look at one. If you create applications with a listview or treeview control, one of the more common tasks you may have to deal with is how to add the ability to drag and drop items. At first glance, you may browse the API docs looking for a single window message or function that does this, but there is none. There are a number of API’s which need to be called and you have to subclass the controls to process the mouse movement. Actually it is quite complex. EZGUI provides a number of commands to support its drag and drop engine for the listview and treeview controls and it is about 600 lines of code. But this is not something which you can just one or two API’s and then it is all done. It is very complex and requires an internal engine to track the drag icon and to do internal message processing. Now where things get complex is if you need to customize the drag and drop. The listview and treeview are two different controls, so how do you build an engine which treats them as equals (one task, but for two different control types). Also what is you want to drag and itme, not within the control to another control or even to another top level window ? Now what happens if you want to customize the drag icon ? Now what happens if the drag icon goes to a position where you need to change how the icon looks (ie. outside of the control) ? What happens if you want to custom draw the icon dynamically ?
Now to make things even more complex, I quickly realized that any drag and drop code for these controls is useless if you don’t impliment an autoscrolling engine. If the dragged item reaches the top or bottom of the control, then you need to automatically make the control scroll to bring more items into view. Can you see how by viewing this as a task, it can get very complex quickly. In this case I had to impliment something which is very complex and hard to do and it required any engine to do this. So how hard is it to code a drag and drop icon in EZGUI ? Check this out for a treeview control:
SELECT CASE CMsg& CASE %EZ_DragItem hTree1&=CVal& hParent1&=EZ_GetTVParent("DDROP", MyID&, hTree1&) IF hParent1&<>0 THEN EZ_StartDrag -1,-1,8,8, "+++AH" END IF CASE %EZ_DragItemDrop hTree2&=CVal& ' Handle to item it was dropped on, so do something
This impliments the complete drag and drop icon task. Now in the %EZ_DragItemDrop event you decied what to do once you know where the item was dropped and add the code for that. But this code impliments the actual drag icon, mouse tracking, icon drawing and autoscrolling. A complex task made easy. EZGUI even generates Events for you so you know what to start a drag operation and when it is finished.
Another way EZGUI makes coding easier is the way it handles parameters for many commands. EZGUI has autoscaling built in since it uses its own coordinate system. Forms and controls use character coordinates (floating point so accurate down to the pixel) which it can scale. This means all the coordinates of your forms and controls are scalable. Another way EZGUI simplifies things is to avoid the use of API handles as much as possible. It does use API handles for treeview items and menus, but many other UI elements do not use handles at all. For example forms are given names and there is no need to store a forms handle. This makes coding a lot easier. Common resources like colors (brush) and fonts also don’t require a handle. EZGUI builds internal tables and uses indexes for colors and fonts. This allows you to easily reference a color or font without having to use a global variable with a handle in it. EZGUI allows you to free a color or font, but if you don’t it cleans up when your app terminates.
EZGUI also uses simple, easy to remember, property strings rather than API constants (where you OR bits) in many commands. It makes coding easier. For example, the EZ_DefFont command can create a font and does not need any complex bit flags or API constant. For example consider these examples:
EZ_DefFont 9, "Arial", 12, "BVUIQ"
This defines font #9 (an index) to Arial with a size of 12 points and which is Bold (B), Variable Width (V), Underlined (U), Italics (I) and Letter Quality (Q). EZGUI uses this simple single character type of property strings as much as possible. Also by each property character usually being the first letter of the propety name (ie. B for Bold) it makes it easy to remember, so you don’t have to read the help file as often to remember properties.
You see, while you may be able to quickly lay out a user interface in a visual designer, what really matters is making that UI do something useful. This is where EZGUI’s runtime engine makes the difference, both with its internal engines and its easy to use command set. This is the “language of simplicity” ! I find it interesting when I see Powerbasic programmers struggling to accomplish some task (on the PB forums) and then see EZGUI users say something like “that would be so simple with EZGUI !”.
EZGUI is a GUI engine, not a visual designer, but guess what ? It comes with its own visual designer, so you get a RAD tool also. You get the best of both worlds. And even if the EZGUI designer is a little different than what you are used to and maybe you miss your old Visual Basic environment, it’s when you start coding that you realize the power of the tool you have. Unlike Visual Basic where customization was difficult, EZGUI provides so many high level and low level tools for customization that you won’t really miss that old RAD tool of yours. The power of EZGUI is the GUI engine !
EZGUI is the only GUI engine or GUI framework for use with PowerBasic.