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.zipAre 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...