EZGUI is not for everyone, so is it for you ?

[Chris Boss]

In this new forum I will go into detail about EZGUI, its benefits and who will benefit the most from it.

A little history will be beneficial here.

EZGUI was originally designed for in house use. It started as a library of prewritten routines to make writing Windows applicatuons easier.

While today I am an experienced API programmer, I have never personally liked the Windows API nor found it easy to use.
Sure I can use the API, but I found there was too much house keeping to do.
Sure I can use the API, but it was geared towards C programmers rather than Powerbasic programmers.
Sure I can use the API, but there were often too many API constants to use, the terms were cryptic and too many structures and pointers were used by the calls.

Ok, thats enough about the API.

I wrote EZGUI to make my life easier and more productive when it comes to writing Windows applications.

Now ease of use does not mean lack of power.

I wanted both, ease of use and power.

Now I should point out here that my approach to programming may be different than others so it is valuable to point out my goals and perspective.

Personally I think programming has become too automated.

Ease of use does not mean there is no need to write code.

I am of the opinion that if you want to be able to develop advanced, quality applications you need to be willing to write code and lots of it.

Ease of use, IMO means, writing code which is easier to write, easier to read and maintain and which is natural (intuitive) or better put more like we think.

Now here is where the concept of power comes in with programming.

When it is advantageous there should be high level routines in a GUI library which allow you add advanced features with just a few lines of code.

One example of this, is EZGUI's drag and drop engine, which adds all sorts of drag and drop features with very little code.

Yet Power also means that the necessary low level features are there when one needs to customize something exactly to their liking.

EZGUI has many low level features which allows almost unlimited possibilities for customizing.

I have found that no two EZGUI users are alike and their needs vary drasticly.

One user wants to write code just like he did with DOS basic, meaning no Visual Designer needed. Some experienced EZGUI users never use the Visual Designer.

Others want a friendly front end (Visual Designer) so they can concentrate on coding the events, rather than the GUI.

I would venture to say that most if not all Visual Designers for Powerbasic started out as a front end for PB. Everything depends upon the designer.

EZGUI is different.

EZGUI started out as a GUI library, not a designer.

Let's take a look at this approach and see how it is different and the advantages

Note: If you want to see how EZGUI is different than the FireFly designer, read this:  http://cwsof.com/forums/index.php?topic=609.0

[Chris Boss]

Why a GUI library ?

There are a number of reasons, but reliability, stability and fast compiles are a start.

One problem with the API I found was with the need for large include files (for the API).

No two programmers could be expected to have exactly the same API include files.

Those who use the includes which come with the compiler may have differences in their files than those who regularly update them (download current ones).

Some like to "tweak" their includes and modify the declarations.

Some declarations may be missing from some includes.

Because of this a GUI engine which does not require the use of the API files would benefit users by speeding up the compile (less to compile) and less errors from includes which are in error somehow (this happens more often that you think).

EZGUI is a GUI engine which has already been compiled and so you don't need any API includes normally (unless you want to integrate some API stuff in your app).

EZGUI has been in development for many years now (its in its fourth generation) and during most of that time I haven't updated my includes by downloading new ones. I have used the same API includes for years and simply add anything that may be missing when needed. I don't want to introduce accidental erros by using new include files.

EZGUI of course has its own include files, but they are small in comparison to the API and I have complete control over them (compared to end users who may have different versions of the API includes).

Next a precompiled GUI engine is better tested than generic generated code.

All users use the same GUI engine, not uniquely different generated code by an API designer. This means that every user (and their applications end users) is testing the runtime over and over again. This means bugs are found  more quickly and the runtime is better tested for stability, IMO.

Lastly, a GUI engine (runtime) allows for better modular design.

Since most of the tasks an EZGUI application does is in the runtime, rather than in the users own code, as the application gets larger and larger, the modular design keeps the total application size smaller than if one were to code the entire application using the API.

This is similiar to Visual Basic. VB programs were larger at first because they had a 1.4 meg runtime, but as the application grew the EXE was smaller than normal and the overall size of the application balanced out so a big VB app may be smaller than its counterpart in other languages.

EZGUI was not designed for writing small utility applications that had little in the way of a GUI.

You can use my EZGUI Utility Dialog Designer, using DDT, for such apps and have no runtimes needed.

EZGUI was designed for building large, complex, professional applications which require support for many advanced GUI features.

If that is your goal, then EZGUI may be for you.

EZGUI was designed so you can build very large and complex applications, yet still be able to have then fit on a floppy disk (small overall size).

Lastly, I wanted a GUI library which was rich in features.

Since the GUI library is the core part of the product (not the designer), this feature set is extensive.

Others may provide a limited number of wrapper functions to make life easier, but there are few products for PB which have as extensive a commant set as does EZGUI.

Download a HTML help file which has the command set documentation in it to appreciate this point:

http://cwsof.com/ez4cmds.zip

Are you really serious when you say EZGUI has one of the most extensive command sets compared to other GUI tools for PB, you may ask ?

Absolutely yes !!!


Let's discuss this in my next post...

[Chris Boss]

Remember how I said EZGUI started out.

It was my own personal GUI library.

I simply asked myself the question, "what are the most common tasks required for writing a Windows application ?".

Those common tasks became the core of the EZGUI runtime library.

In each new generation of EZGUI I had to go further and ask "what common, yet difficult, tasks would most Windows programmers require".

I had to go beyond the basics.

One of the problems I saw in many Windows programming environments, was the tendency to depend upon adding components (OCX's) to add new features, rather than adding the features themselves or by simply adding the necessary building blocks so you can build it yourself.

For example, in Visual basic notice the common controls are not directly supported by the code runtime. You had to add a bunch of OCX's to add support for controls which often were standard to many Windows applications.

To make things worse, if say the standard (and common) controls lacked a feature you needed, it was not easy to expand them.

VB'ers especially became dependant upon purchasing one third party custom control after another.

With EZGUI I took a different approach.

First, if a control was supports in the Windows API (ie. standard controls and the common controls) I added them to the core GUI engine.
Second, I went through the API docs to find all the features these controls supported and asked the simple question:

"which of these features would most Windows programmers want in their applications?"

I didn't just go through the list of messages a control supported and just start writing wrappers for the ones easiest to impliment.

Of course some features were easy to impliment.

But a number of features were a bit more complex and require some complex API code. If I felt that feature was a necessary feature for the average programmer, then I added it even if it was difficult to write.

This is where a number of EZGUI's high level features came from.

For example, when I added RichEdit support the most common task one would require was to be able to print RTF text. This is not simpole a thing to do using the API, but I added this feature to EZGUI because it was a necessary feature IMO.

EZGUI 4.0 Pro has a drag and drop engine (drag icons for dragging items) for the Listview and Treeview controls. Not only that, but the drag engine can do auto scrolling when you drag and item to the top or bottom of the control. This is a common feature on quality Windows applications that use these controls, yet the code to accomplish is very complex, quite large in size and possibly out of the realm of many PB programmers to write themselves. Yet, I added this feature because common sense said, many programmers need this ability.

EZGUI users would not have to depend upon a bunch of third party controls (OCX's) or complex API code just to impliment what I considered standard Windows features.

Now this is where it gets interesting. If EZGUI provides so many high level features, is there any low level functionality ?
Also what if EZGUI doesn't provide what I require ?

I'll consider that in the next post ....

[Chris Boss]

Because of the modular design of EZGUI (a GUI engine as a runtime) I wrote the internal engine with a lot of modular design which can be exposed.

For example, rather than have just one print engine to a printer and wrote the print engine as a generic print or graphic engine which can print to any DC (device context).

I then created the Printer print engine on top of that.
I then created the Canvas control print/graphic engine on top of that.

Lastly, I exposed the low level print/graphic engine so you can use it to print to any DC you like. The ownerdraw engine is build upon that.

So this gives me three print/graphic engine:
- printer
- canvas control
- any DC

The concept behind the GUI engine is to create many low level functions (commands) which are then used to build higher level functions which then may be used to build even higher level functions.

Now add to this the ability to "hook" into many of the high level functions to modify their functionality, this gives the programmer almost unlimited options to customize many features.

For example,

EZGUI can display the common dialogs (ie. Open file, Color, fonts, etc).

Ok, this is no big deal one may say.

EZGUI goes further though.

EZGUI created hooks into these dialogs so it can trap events occuring with those dialogs, just like a normal EZGUI form.
Not done yet.

EZGUI provides the ability to modify the common dialogs (add child forms with controls), even converting the button controls to ownerdraw.

Since EZGUI has many low level features like ownerdraw, DC graphics, etc. which can be integrated into higher level functions like the common dialogs and it provides the necessary "hooks" (or events) to accomplish this, you now can customize your applications in all sorts of way you never imagined before.

Yet, EZGUI still goes further!

At some point is was necessary to expand the features of existing controls. Visual basic users would simply purchase a third party custom control to give this functionality.

With EZGUI, I tapped into the "customization" engines already built into Windows, which are not used as often by PB programmers as they could be.

Tow mechanisms were used.

(1) Custom Draw

EZGUI uses thie engine to allow customizing of the fonts and colors of some controls per each item (ie. Listview, Treeview). If all you need is to customize colors and fonts per item, this is relatively easy with EZGUI (only certain controls support this).

(2) OwnerDraw

Ownerdraw allows you to actually draw a control (or menus) exactly the way you want. For example, rather than purchase a third party control which displays a combobox with either different fonts or colors in each item (for a drop down font or color selection list), EZGUI makes it easy through ownerdraw.

Now what is really exciting about this is that two levels of this feature are provided.

- Low level ownerdraw where you draw things exactly the way you want
- high level "Simplified Ownerdraw Command set" which has a set of high level commands that allow you to customize many controls with just a few lines of code.

Such features allow you to "build" custom GUI's using just one runtime engine and without the need to resort to a number of third party OCX's.
Why use someone elses custom control, when you can build it yourself exactly the way you like.

It doesn't end here.

EZGUI also provides a subclassing engine where you can tap into a controls window procedure and modify its features. This is very advanced, but it offers nearly unlimited customizations. You can integrate API code here if you like, but EZGUI also provides a number of built in, easy to use ways to use the subclass engine.

For example, EZGUI already has a graphic engine which can draw into an DC. The subclass engine can tap into the background drawing routines if a control and then generate an event (%EZ_EraseBG) where you can draw the background yourself using any EZGUI drawing command (for DC's).

The subclassing engine has a number of high level features built in, for example you make the sides of a control draggable and EZGUI does the hard stuff for you.

The key here is giving you as many ways as possible to customize your GUI.

There is another feature of EZGUI for customizing which goes much further ....

[Chris Boss]

Another mechanism for customizing EZGUI provides is its own custom controls.

I took a different approach in choose the type of custom controls to add to EZGUI.

Rather than provide a number of very high level custom controls which only a few may use, I choose to provide custom controls which are what I wopuld call "Building Blocks" for bigger and better things.

For example the most powerful custom control is the Canvas control.

This control allows you to create all sorts of unique controls far beyond the average third party control.

The biggest feature added in EZGUI 4.0 Pro's Canvas control is the new Sprite Engine.

Sprites are movable, non-retangular objects (images) which can be moved, hidden/shown, animated (multi-framed) and even anti-aliased.
My favorite feature of the sprites is their ability to be Alphablended into the background and each other.

With this control, the graphic engine and the sprite engine you can create alll sorts of animated, graphicly oriented controls of your choosing.

EZGUI gives you the building blocks to build a variety of powerful and unique applications.

But in all of this there is one catch !

Whats that ? ....

[Chris Boss]

EZGUI is not for everyone !

Isn't EZGUI the best thing since apple pie ?

No, not in the wrong hands it isn't.

EZGUI is a powerful tool in the right hands.

Well, who is that you may ask ?

Its hard to pinpoint exactly who gets the most out of EZGUI and who doesn't, but from my experience with a variety of customers I'll venture an educated guess of who I think gets the most out of EZGUI and who won't.

If you are long time VB'er (thats VB as in Visual Basic) , but you hate writing code and demand the latest and best Visual tools to you can drag and drop your creations into life.
If you depend upon black box third party controls (aka OCX's) to give your applications that special look.

You may not be happy with EZGUI.

If you have immersed yourself into the Windows API and think in terms of dialog procedures, window procedures, classes, notification events.

You may not be happy with EZGUI, because it may appear to foreign for your tastes.

Then who will like EZGUI ?
Who will benefit from EZGUI ?

My first gut response is:

You must be someone who loves to write code. If you are too drag and drop dependent, then look elsewhere.
Real coders, tend to love EZGUI since they have all the tools, high level and low level to create unlimited GUI's.

You must be disatisified with what you can currently accomplish with your current programming tools.
If you are happying using your current tools and can accomplish all you want with them, then why are you looking elsewhere ?

You must be desirous of being willing to learn a new programming style and technique (still using basic of course, plus EZGUI) if it can produce the final results you are looking for, which would be an advanced GUI with features others only dream of adding to their software.

You must be a coder first, then willing to use a totally different Visual Design tool than you may currently be used to.
The designer may not be exactly what you are use to, but as long as it accomplishes the job, it is the GUI command set that interest you, the ability to do things you never though you could do before.

If you want that "graphic edge" to your software, to go beyond the average software. If you are willing to be more concentrated on the possible final results, rather than the idiosyncronises of how you get there (meaning "not the way I am use to doing it, but it works and the results are what I seek"), they you may be one who likes EZGUI.

Lastly, if you are not committed to your investment in EZGUI, then you may be better off forgetting it.

EZGUI users often find that it is different that what they were use to in the past and that initially the learning curve requires some effort.
A common experience is what I call the "light comes on and I see" moment. New users may struggle at first, make a few mistakes, be confused at first, but if they persist and are committed to learning the product (and I offer a lot of help here, so you are not alone) they may finally reach a point where they will say "it all is coming together now" , "it makes sense now", "I get it" and they experience that "aha" moment where things fall into place and they understant things.

From that point on it is often smooth sailing and such customers become very productive with EZGUI. They start building software they used to only dream of.