EZGUI 4.0

[Chris Boss]

 
EZGUI 4.0 has been released a few months back and it represents a new generation for EZGUI.

You can read about some of the benefits of EZGUI here http://chrisboss.hypermart.net/ubb/Forum10/HTML/000088.html

My impression of this forum is that it may be geared towards some of the more advanced PB programmers, so I will skip going through all details about how easy it is to use and the many features.

What is there for the advanced PB'er?

Let's start with controls.

Three of the more complex controls, RichEdit, Treeview and Listview are well supported with a rich command set to handle not only more common tasks (and simpler) but even the more complex tasks.
The richedit control supports moving large amounts of data (RTF or text) to/from the control (usng EM_STREAMIN and WM_STREAMOUT internally), defining text fonts, colors, paragraphs, tabs and even hyperlinks!
Also the print engine supports printing RTF text. The Listview supports not only most common tasks, but even advanced listview sorting, ownerdraw, etc. Both the Treeview and Listview can easily impliment a true drag and drop cursor for dragging items, with as little as just a few lines of code.

There are a number of custom controls that come with EZGUI, which give you a lot more choices for building a GUI, like masked edit, MCI control, Shape/Hot Spot control, Turtle Graphics control, Properties Listbox control and Files Listbox control.

Combined with its drag handle control , EZGUI's Visual Design engine gives you all you need to build your own Visual Designer front end. Not satisfied with the current visual designers for PB? Why not build your own, just the way you like it. Using EZGUI Visual Designer engine and its drag handle control you can impliment the hardest part of a designer, the drag and drop part. EZGUI's Visual Designer engine allows you to subclass any control and impliment drag and drop with it, providing the necessary drag handles.  There are also many other applications for using such an engine too, other than building a visual designer for coding. Now combine EZGUI's drag and drop engine and its property listbox control you have the basics necessary for building very advanced WYSIWYG type programs.

Lastly, EZGUI's Canvas control, plus its graphic engine (for drawing), combined with the new Sprite engine allows you to build some very complex graphics oriented programs. EZGUI's canvas control supports DIB sections and is faster than using PB's DIB SET/GET command, since you cna access the pixels directly without the need to move pixels (to a string and back again). The Canvas also supports double buffers. The sprite engine allows you to add true sprites on a Canvas, which can be moved, shown/hidden, flipped, animated (multiple frames) and even has collision detection. Sprites also support anti-aliasing and my favorite, alphablending. While it does not have all the bells and whistles of say DirectX, it is quite fast and it only depends upon the GDI. You don't have to worry about what version of DirectX is installed, what OS is installed. The Canvas control and sprites will work on Win95 to XP. If you need to support older computers, then EZGUI offers a way to do this while still offering great graphics.

EZGUI 4.0 supports it's own Thread engine (doesn't even use PB thread commands internally), which makes working with multiple threads easier than ever and safer than ever. EZGUI treats threads like events and it handles all the syncronization needed between threads. The most difficult threading to handle is when you want to communicate between threads and the primary GUI thread (which should do all the GUI stuff) without problems. EZGUI uses critical sections to syncronize all worker threads with the primary GUI thread, so you simply generate an event from any thread to the primary thread and EZGUI makes sure there are no bottlenecks.

Its not the creation of threads that the problem when using PB, but it is the syncronization to prevent problems which is often more difficult. EZGUI handles all of this under the hood.

Now this does not mean EZGUI should be used instead of all 100% API code apps. IMO, one can use both. Use EZGUI, where its advantages outweigh the desire for 100% code. And even though EZGUI is an engine, you are not limited by it. I provided a number of hooks directly into the internals of the engine, so you still have control. You don't have throw away all your API code libraries. EZGUI allows you to hook into its internal window procedure, add dialog procedures to EZGUI forms (not normally needed, but there if you need it), subclass all controls, even third party ones (if they can be created using CreateWindowEx), hook into is message loop (which includes the Modal message loop, since EZGUI uses its own internal Modal message loop for modal forms). You can even hook into the Canvas controls WM_PAINT procedure to integrate code into this process.

EZGUI even impliments MDI using the same internal engine! You even have access to the MDIClient control so you can paint its background.

For the more advanced programmers among you, some info:

EZGUI impliments its window engine using a custom Dialog class. It doesn't use the windows dialog class. Actually this one window class, impliments both Dialogs and MDI Frames/Children amaziingly. It even allows you to define true dialog procedures (through its hooks) for the MDI forms as well, just like dialogs.

A while I am sure many of you can easily write apps using the API alone, when you are in a hurry, EZGUI allows you to build complex apps quickly. Build your own personal tools using EZGUI.

I would estimate that most of my customers are only using about 5% or less of the features in EZGUI, on average. There are so many advanced features, that an experienced API programmer can do amazing things with EZGUI.

Now as far as the main runtime (a few of the controls are external DLLs), it is only 515 KB in size. Now if you prefer, you can compress it with a tool like UPX and it compresses down to a tiny 157 KB! Now for all it provides that is really small.

[Theo Gottwald]

I have tested EZGUI 4.0 for a while now and want to say an independent opinion.

I know that the typical user of this forum doesn't like AddOns or wrappers that do SDK-stuff "under the hood".
The reason is, that this may hold people away from learning "real windows programming".

After testing it, I see anyway two good reasons for using EZGUI for projects where it fits.

Reason Number 1: EZGUI is more near to SDK then the PB DDT commands.
You learn the EZGUI Commands and mostly the API commands doing (samehow) the same have the same name.
For example: EZ_Settimer and Settimer (API).
When I saw the EZGUI Help first my impression was "he just took the API and made an EZ_ infront of anything".
Its not like this, but as said EZGUI does mix with SDK without problems and its command set names are not far from the SDK commands.
Therefore my reason number 1 where i can recommend it, is for beginners who do not want to go the hard way from the first day.

Reason Number 2:EZGUI helps to come from A to B faster
You have a programming project, which just needs to get done as soon as possible. Using EZGUI you get it done in less time.
While EZGUI has also a learning curve (and there are hooks and corners in there), after some weeks you do get things done faster.
I do not talk at first from the Visual designer here, in fact the EZGUI Visual Designer is in terms of intuitive usage behind competitors.
And it will need time to find out how it works. The time saver is the EZGUI API-Library.

Other things good to know:
I must say that the support for EZGUI from Chris is very good. I had some questions, mailed him and got an answer.
There are some obstacles in EZGUI you can not easy get around without help, because the system is built up and improved and not all switches are where you would expect them.
The original help file is - i must say "nearly complete", most often the "See also" fields are missing - while needed for beginners.
I had less problems, cause I know the API-commands I would normally use and then I just put an EZ_ infront of it and most often i get what I need :-).
Anyway there is an alternative help-file from Frank Kelly, if you use EZGUI, get this one, ask Chris for the link.
One of the things, why EZGUI is a time-saver, is the fact that you find the right commands and parameters to do something much more easy.

Using SDK you have often to figure out "is it a BSTR or NUL-terminated", what sort of Pointer do I need here?
Where can I get an working example?
EZGZUI most often takes away these sort of problems. You just use normal PB Strings and LONGS. I found these two things, to save me a lot of time.
-> Quickly find the right command for GUI Tasks
-> Easy parameters

Now a word to multithreading.
Multithreading is easy with Powerbasic. Reading something from "simplified multithreading commands in ezgui" i wondered how it should be made more simple.
Then I checked some checkmarks n the form property and just wrote the name of my multithread-sub at the place where its expected.
Its really easy. And its safe - because EZGUI will close the Thread automatically when the form is beeing closed.
If you forget to end a thread in a normal PB Program, you may end up with a Error-Message. And that is my final comment to EZGUI.

Its stable and it frees used resources even if you would forget
While those commands sound exactly like API commands with an EZ_ infront of their name, I believe that Chris has done a lot under the hood, to release uneeded resources.
You want someone to run after you and close all those handles and resources you have used?  Let Chris do it.
The resulting programms are stable as PB programms are.
One reason I most often avoid components from other people is, that I am not shure on the stability of the result. In case of EZGUI the result is stable and for PB users this is most important.