The EZGUI paradox !
“EZGUI is easy to use”
“EZGUI is a RAD tool”
Yet, some new users initially find EZGUI, especially its visual designer, very confusing.
Paradox ?
Let me explain. I have been trying to fully grasp this paradox with my software and here are some observations of mine which may be helpful. Now remember that not all customers are the same so there is no way one can easily sum up all new users with one model, but I have seen a trend or pattern over the years with my customers and my conclusions are based on this.
Chris Boss doesn’t think like most programmers !
If you have ever even thought this for one moment, don’t feel bad. I won’t be insulted. I have to admit, this is most likely true. The more you use my software the more one will likely appreciate why I say this. Most people when they use my visual designer, their gut reaction is, “this is so different than what I am used to”. That is true. I did not design my visual designer to be like any one elses tool. I did not copy Visual Basic. I did not copy PB Forms. I did not copy FireFly. So what gives, you may ask ?
Even my GUI engine and its concepts, some find a little confusing at first. Why does EZGUI do so many things so differently than what you may be used to ?
Consider the background and history of EZGUI.
There is a good reason my visual designer is not like others, especially designers for use with PowerBasic. When I first started programming in PowerBasic (I was using PB 5.0) there was no DDT. There was no PBForms. There was no FireFly. There was no PwrDev. Actually there was no visual design tools for use with PowerBasic at all. You see, Powerbasic was not viewed as development tool for full blown Windows apps at the time, even by Powerbasic. Thats why the product was called PB DLL (or a DLL compiler). Even Powerbasics advertising touted it as an addon tool for use with Visual Basic, for those who wanted to write fast DLL’s for VB. Now I face a critical problem back then.
I wanted to write full blown Windows applications (which PB DLL could do), but one had to understand the Windows API to do so. There was no DDT back then, only pure SDK style coding. So I began an inhouse project to make writing apps easier. I had to find a way to be able to build an application quickly and easily. I was (and still am) a firm believer in building reusable libraries and so it began. My GUI library came to life. To make a long story short, it was not called EZGUI intially, but once I decided to make it a commercial product , EZGUI was born.
As I started building my GUI library, I quickly noticed that without some kind of visual drag and drop designer, building a user interface was slow going. Nobody that I can remember back then even knew how to build a drag and drop designer. There was no code on the PB forums to teach one how to do this. For me, it was a matter of a lot of research and trial and error. EZGUI was the first commercial product to attempt visual design for PowerBasic.
It wasn’t all about the designer.
What many have not realized over the years, is that EZGUI was (and is) not all about the Visual Designer. I did not design EZGUI to be a visual designer. The product was (and is) a GUI engine , a GUI library. Visual drag and drop, was simply a necessity for building apps faster and generating UI code. This is why the early generations of EZGUI’s designer were quite limited. They did the job, but that is all. It was all about the GUI engine though. That was the primary concern. The power of the product is the GUI engine.
The quicker new users realized this about EZGUI, that the power is in the GUI engine, the quicker they became productive with it. Each new version of EZGUI, the designer improved, but the GUI engine is where it was all about.
I see you are a coder !
Over time my customers most likely would begin to realize something about me. “Chris Boss, you are a coder aren’t you !”. Yes, that is a very correct description of my mindset. You see, I date back to writing DOS applications, before Windows became popular. I have a lot of experience in writing custom software for local businesses, most in the DOS days. From this past experience there are certain qualities that I have developed, when it comes to programming. First, I am a coder. I personally feel programmers need to code more and depend less upon visual designers. Many programming tools today are more App builders, than they are programming tools. This was the big problem with Visual Basic. Too many VB’ers could quickly lay out a user interface (which was easy), but when it came done to the coding part, that is where some fell short. You see, in the wrong hands, Visual Basic is just an app builder. If you can draw it, you can build it. That may be fine for the user interface part, but once you get past that, one must still know how to code. Thats where things can go wrong very quickly. Coding is an art, a skill. Even in the world of todays programming languages, especially dot.net stuff, I feel that programmers want the tools to do all the work. Maybe this is why dot.net programmers can’t give up managed programming languages. They do so many fancy things quickly, so a programmer can get a false sense of security. “See what I can do with dot.net” one may think, but how much of it have you really coded though ?
Myself though, I am a coder. I do believe in library code, both high level and low level, but the power comes from coding, really ! EZGUI’s runtime engine was designed for coders and the more quickly one appreciates this, the faster they will learn how to use it. Ask any long time EZGUI user and likely they will agree, that the “power is in the GUI engine” (the runtime). Now this may not sound very promising for many drag and drop developers today, but what I can tell you is this, once you see the power of the GUI engine and start tapping into it, you will find that you can do so much more than you imagined possible. I really believe this.
The Designer is only a high level tool for the GUI engine.
EZGUI’s Visual Designer is the first thing many new users see and the experience is not always the best for some. Why ? If you come to the designer from the aspect of your current programming experience, whether it be Visual Basic, PB Forms, etc., likely you may be disappointed at first. It does everything differently that your current tools. Nothing seems familiar. And likely you are right. Instead of just starting right in and trying to build an application, you really need to slow down and take the time to read as much of the help file as possible. You need to start learning about the GUI engine first. Actually you may be better off starting with the code samples in the codeclips folder. You see, the codeclips are not designer generated apps. They are hand coded. Hand coded you say ? Yes and there is something important here.
Hand coding, teaches more about EZGUI than anything else.
Unlike other programming tools, EZGUI as the unique ability to be used purely as a hand coding tool. I actually have some customers, who write commercial quality software using EZGUI, who hand code everything. They don’t use the designer. Not only is it possible, but some hand coders can produce apps faster and better than those who use the visual designer. These programmers are the ones who can honestly attest to the fact that the “power is in the GUI engine” and that being a coder is where you truly see that power. Now this does not mean I don’t want you to use the Visual Designer. I actually do. But you have to experience EZGUI using hand coding to understand the mindset behind the product.
The GUI engine was designed for fast hand coding.
Everything about the GUI engine, speaks ease of use when hand coding. For example, many DDT and API programmers wonder what happened to all the API constants they are familiar with. They are gone. EZGUI commands were purposely designed for minimal character typing. This is why is often uses property strings for commands, where a single character represents a property. If possible the command names are kept as short as possible. Constants are few in EZGUI, mostly used to define events and little more. EZGUI was designed for coders and they are the ones who quikcly grasp what it is all about. Even EZGUI’s use of character coordinates, rather than dialog units or pixels, speakes ease of coding. Actually EZGUI’s character units are superior to dialog units and easier to visualize in the mind (which coders require). They are scalable, but while dialog units often do not translate perfectly to pixels (because dialog units can’t handle fractions of a unit well at times), EZGUI uses floating point numbers for character units, so they can always translate perfectly to pixels, while still being scalable. EZGUI even provides functions for converting between pixels and character units, so you can work with both.
EZGUI is both high level and low level. It is high level when it really can make a difference, but it is also very low level so you always have the power to do almost anything.
The power is in the engine.
The average EZGUI user only uses a small portion of the EZGUI command set and they are always learning new ways to tap into parts of the command set they haven’t used yet. The ley to EZGUI is to always opt for an EZGUI command rather than resort to the Windows API. API programmers are more likely to start integrating API code too quickly into their apps. You see, EZGUI was designed so that in most cases one should never have to use a single API call at all. That is the mindset one shoudl develop. Always try to do it all without the API. You will find that your apps compile faster (no API includes required) and that your code is more readable and easier to maintain. The GUI engine is so powerful it can do a lot for you that you don’t realize. Actually the runtime has a number of built in engines which are doing a lot of the work for you. This is why you don’t need any dialog procedures or window procedures. This is why you don’t use window messages. EZGUI is event based and it generates nearlly all the events one may usually require.
This does not mean that you can not add API code to EZGUI apps. EZGUI was designed so one can easilt integrate API code with it, when EZGUI can’t handle some task. But if you don’t learn how to do as much as possible using the EZGUI command set, you won’t appreciate when it is the proper time to integrate API code. EZGUI provides advanced features such as hook procedures and functions to return API handles, so you can integrate API code when necessary. But you have to do it the EZGUI way. You need to learn EZGUIs own command set first, before trying to integrate API code in your apps. So new users, no matter how experienced with the Windows API, should try to stick to EZGUI commands only.
The Designer was built upon the GUI engine.
The more you understand how EZGUI apps are written and the EZGUI command set and mindset, then the more you will appreciate its Visual Designer. The designer was designed to optimize the EZGUI command set. The code it generates is easy to read, but only for those who grasp how an EZGUI app works and the command set. Learn that first. This is why you don’t see familiar things such as window styles for controls. Simply put, you don’t need them or use them. The more you understand about how EZGUI impliments certain events such as low level mouse button events such as %EZ_LBUTTONDOWN, the more you will understand working with events in the designer. EZGUI uses subclassing to access such low level events, but subclassing is only to be used when you require a low level feature. Normally EZGUI generates the most common events (ie. %EZ_Click) without the need for subclassing. The designer knows what events require subclassing and what do not. So to get certain events, when you select them in the designer, it will generate the necessary code to impliment subclassing of the control (EZ_Subclass command). By just using one event which impliments subclassing, this makes multiple events now available. For example just by selecting the %EZ_FreeNow event in the designer (which requires subclassing), you will get access to many other events as well. So to appreciate the designer, you really need to understand the GUI engine.
The Smart Parser, a curse and a blessing.
When I first designed the Smart Parser, we were having debates in the beta forum (prerelease) about the best way to handle integrating visual design and coding. Many users wanted more control of how they edit code, so they did not want a built in code editor. They wanted to be able to use the PB IDE, Jellyfish or any other favorite code editor. This meant the designer had to support many different external code editors. There needed to be a way to allow the designer to control the UI creation code, while allowing the user to edit the rest of the code. The solution was the Smart Parser. Now while initially many find it confusing, it actually does make sense and it does work very well. One critical aspect here is the speed of code generation. You see, my own impression of many who use DDT and PB Forms (and powerbasic in general) is that they write apps with only a few dialogs/forms. EZGUI on the other hand was designed so one can build very large applications, possible with dozens if not hundreds of different forms. This required I design a parser which could handle the UI changes, but with minimal effort in reading (parsing) the source code. The smart parser does an excellent job of this, but with one restriction. It considers certain blocks of code as “protected”, meaning “don’t touch it”, since the Designer will always regenerate that code block. The routines which add the controls to a form are a perfect example.
Programmers using other tools like to add code before and after the control creation commands. EZGUI’s designer does not allow this. Now of course if you hand code you can do anything you want, but when using the Designer it imposes restrictions. If a routine is protected, simple put you can not edit any code in it. The designer must protect and control all code in those routines.
This technique produces clean code for all the UI creation and it makes sure you code always works as intended by what you designed in the designer. It allows for very fast code generation, event for very large projects with many, many forms.
The work around !
Some programmers get very confused by the limitations of the Smart Parser, but there is a work around and that is the GUI engine. You see, I recognized the problem with not being able to edit the UI code and rather than slow down the parser, I chose a different routine. I added features to the GUI engine which give you features not found in the API normally. For example EZGUI has a number of unique events designed to allow better control of the order code is executed. It has the %EZ_Loading event which occurs from within any control (or form) creation command, so that before EZGUI attempts to create the control/form you requested, it will generate an event (%EZ_Loading) and in that event you can actually modify the parameters of the controls creation command and change them dynamically. Also if you want to manually subclass a control you can call EZ_SubClass in the %EZ_Loading event and it will be just as if you had hand coded EZ_SubClass before the control creation command. There is also an %EZ_Loaded event which occurs right after the control is created so you can have code executed right after the control creation command is called. Forms also have the %EZ_Started event, after the form becomes visible the first time.
EZGUI’s event engine solves a number of problems for both hand coders and those who use the Visual Designer. This means that the protected code generated by the designer does not really limit you. You can add code in the events of the control and it will act just as if it was written before or after the control creation command. I know this is different for many, but not only does it work, but it works very well and is actually better in some ways.
In the Designer, you can tell it to generate the %EZ_Loading event for a control (%EZ_Loaded always occurs).
The smart parser actually is a good balance between control and speed. The designer needs to control some of the code, while you benefit from the faster speed of the parser. If you build very large projects you will appreciate this.
The light goes off eventually, so be patient.
Have you ever seen in cartoons when a character finally gets a great idea or something finally makes sense, they draw a lightbulb turning on next to their head. Actually this well illustrates how learning to use EZGUI occurs. Initially many are confused, because EZGUI is so different, especially the designer. The key is to ask lots of questions. If you give up in learning EZGUI without asking me (via email or the forums) any questions, then the result will be your of your own doing. You see, I not only expect new users to ask lots of questions, but I want them to. I know EZGUI is different and that written documentation just never does it justice. You need to ask those questions and lots of them if necessary. I had one new user who literally emailed me nearly 70 times before the light turned on so to speak. The point is that the light will eventually turn on for you too. This is the “tipping point” for most EZGUI users. For some it takes a few days. Others may take a few weeks, but it does usually happen. But guess what happens when the light turns on in the mind ? Everything starts making sense all of sudden. The reason is that there is a mindset behind EZGUI. There are good reasons it does things the way it does. The nice thing though is that this mindset is quite consistant in EZGUI. Once you get one thing all sorts of others things start making more sense. And this is where the fun begins.
The fun begins !
When things start making sense fo new EZGUI users, something amazing happens. They in short order go from confused to “wow, I can do this and that” ! They get excited. The start becoming productive. From here it only gets better, because once you see the power of the GUI engine, many realize that they can do so much more than they could before. Even those who those think they really know the Windows API quite well, may find that EZGUI does so much more than they imagined. I have said this before and I will say it again. Do not under estimate the power of EZGUI. You have no idea how much research into the Windows API I have done to build this engine. EZGUI 5.0 , the latest version, is so advanced that I doubt many Powerbasic programmers using the Windows API alone could do even half the things it can do. While DDT programmers are using the simple drawing command set of DDT, EZGUI users are doing 2D and 3D animation, low level high speed graphics and more.
Commercial quality apps !
I did not design EZGUI to be a tool for novices (aka. the EZ in EZGUI). Yes, I designed the command set to be as easy to use as possible. But EZGUI was designed for professional programmers who need to be able to build quality commercial applications. The stability of the GUI engine is one example of why commercial programmers love using EZGUI. The power of the GUI engine allows them to build applications that even their C++ peers would find hard to do, and especially with the amazingly small footprint of EZGUI. Like any tool designed for professionals, there is a learning curve. This means to get the most out it, requires a certain degree of commitment. Unless you reach that point where the light in the mind turns on and you get it, EZGUI will be a disappointment to you. It was meant for those who were committed to learning the EZGUI way of doing things. The nice thing though is that once you start getting productive with it, things start moving very quickly. Some customers are writing dozens and dozens of commercial applications with EZGUI at a fast pace. It provides an advantage for their businesses. Fast, quality applications which can do amazing things, with an amazingly small footprint. Yes, the power is in the GUI engine and once you realize that, some exciting things can happen. And I am here with you along the way to help you get the most out of it.