Coding versus Drag and Drop !

When discussing the benefits of EZGUI 5.0 Professional with potential customers, one thing is often overlooked by them. This is the difference between coding and drag and drop development.

Software development today has become a matter of using advanced visual design environments where the programmer spends more time selecting items, from intellisense drop down lists or property boxes, than actually writing code. At least that is my impression of it anyway. While I appreciate the value of a visual design environment for laying out forms with controls (the user interface) I do feel that coding is still very important. Programmers should not expect their development environment to so all the work and this is the concept behind EZGUI.

Yes, EZGUI has a visual designer/code generator, but the real power is in the GUI engine, not the designer. This is why some new customers may end up being disappointed with EZGUI, while others are just plain excited when they start using it. The first thing new users will notice is the visual design environment is not like other visual design tools. It looks different and works differently. There is no built in code editor, but it depends upon working with an external code editor (via its Smart Parser technology which literally rewrites the code for you each time you change user interface elements). Some new users just can’t beyond the Visual Design environment and I believe there is a good reason for this. For many today, writing software is no longer a matter of coding. It is a matter of software development being more “application” building rather than coding.  We as programmers can find ourselves expecting our tools to do all the work, rather than us being in control and writing code.

One example of this “application” building mindset is the idea of reusable components. There is nothing wrong with reusing code or even higher level components. The real problem though is that if one depends too much on components, they may find themselves becoming “application” builders rather than programmers. Because most components are fixed in their feature, it is easy for developers to complain and offer all sorts of suggestions of how the component should really work (even if only a minority would ever want the features desired). Such developers are really not programming anymore, but they are simply dragging and dropping their applications and expecting the tool creators to do all the work. I find it very disappointing when a customer suggests a new feature, which currently could be coded with just a couple lines of code.  Two or three lines of code is not very much, but to expect the tools creator to add a new feature which encapsulates those few lines into a new command for the library is just wrong. I would rather spend my time on building much more complex routines than that.

The same goes for the visual design environment. Visual Designers are only tools to speed up the layout of an application, particularly the user interface (forms and controls). Designing forms visually makes a lot of sense. But often developers want more. They want so many high level components that writing software becomes simply a matter of dragging and dropping with little code writing. Even non-programmers could do that ! The problem with over dependence upon components is that often some customization is usually required to get the exact results desired. You just can’t write software properly just using only high level components.

EZGUI is different and for good reason. The GUI engine (library in the form of DLLs) is the core of the tool, not the designer. The majority of my time was spend on building the GUI engine. But even with the GUI engine, it was important to recognize the value of low level, medium level and then high level features. Initially most of the work was on low level features. A GUI engine really needs to be as much low level as it is high level. What many not realize is that EZGUI’s low level design is why it can pack so many features into such a small set of runtime files. The reason is that by starting out low level, even I could build upon that as I add higher level features. For example, EZGUI 5.0 has two special custom controls (higher level), the Files Listbox and Properties Listbox controls. What few may realize is that rather than write those two reusable controls from scratch, I took advantage of EZGUI’s low level ownerdraw engine and simply created two new controls using superclassing (listbox is the base window class) and uses the ownerdraw abilities of the base class to build two new high level controls. Simply put, I used the low features of the GUI engine to build its higher level features.  EZGUI reuses as much code as possible within itseld.

Another example if the new glCanvas control which supports OpenGL 3D. This control is a hybrid control based on my normal Canvas control. Again I used EZGUI’s own Canvas control as the basis of this new control using the new superclassing engine I added to EZGUI 5.0 and then I added OpenGL 3D on top.

The idea behind EZGUI is to blend the low level, medium level and high level together into one engine. If you don’t like some high level control, then EZGUI provides ways to customize it, whether it be through subclassing, superclassing or hook features provided in the command set. EZGUI was not designed for those who simply want to live within a visual design environment all the time. It was designed for coders. Those who are willing to learn how to tap into the power of the GUI engine.

Do you realize that some of the more experienced EZGUI users, skip its Visual Designer completely ? Yes, they prefer to hand code the entire application. This gives a programmer even more control, because you are not subjected to a lot of the forced code of the visual designer, which it may generate for the benefit of modular design which works well with the Smart Parser. Hand coded apps are usually smaller in size and have a lot less code.  The real power of EZGUI is in the GUI engine, rather than in its visual designer.

To make sure my customers are happy with the product, when I discuss EZGUI in marketing material (ie. on the PowerBasic Third Party forums) I have lately actually been trying to discourage some from purchasing EZGUI. I have found the need to highlight this difference between coding and drag and drop, so only the right people end up purchasing EZGUI. For those who simply must live in their favorite visual design environment, I have pointed out that their may be better options for them via some of the other tools available for use with PowerBasic. To me, one happy customer is better than a hundred disappointed customers. Those who are the happiest with EZGUI are those who appreciate its appeal to coders, rather than those who live for drag and drop.