No announcement yet.


  • Filter
  • Time
  • Show
Clear All
new posts

  • EZGUI vs FireFLY

    Would anyone be willing to give me a quick comparison of EZGUI vs FireFLY (other than FireFLY being cheaper?)

    Last edited by Jim Dunn; 22 Sep 2008, 10:24 AM.
    "Ok, yes... I like pie... um, I meant, pi."

  • #2

    There really isn't a fare comparison to be made. They both differ greatly in what they attempt to do. I'll do my best to give you a good run down though.

    Firefly "looks and feels" more like VB. You design your interface and edit the code directly in the same application. You set whatever properties you like per control much the way PBforms or VB would do it. Firefly has a decent collection of 'wrapper' functions to assist with some of the more difficult to do tasks, but basically its a tool for those who are comfortable with Windows programming already. If/When you need to modify the source, you change it through the Firefly interface.

    EZGUI Takes a different approach in that you design your interface in one program, and then it generates the source code for you. You use whatever editor you want and build your code around the 'framework' EZGUI generated. Like PBForms, when you need to change your code, you use the designer, make your changes and then regenerate the source code. As long as you follow the rules where things go, you're code is retained within the updated code. EZGUI also uses a DLL that you ship with every application. This DLL contains the 'wrapper' (for lack of a better word) for the EZGUI commands. Unlike PB's DDT and FireFly's FF_ commands, the EZGUI commands are complete functions you use to do what is generally far more difficult to do in Windows. EZGUI is more like the traditional programming style, everything is broken down into self-contained functions and is generally easier for the person making the transition to Windows from DOS or another non-Windows platform.

    Both systems are great. The support for both is excellent, and both are actively being developed and refined. What it really comes down to is how comfortable you are with the Windows API and if you prefer to separate the code from the designer.

    I can tell you that personally, I get more done faster with EZGUI than FireFly, but then again, I never used VB and never like that style of development.

    What I would do if I were you, is download the Firefly trial, and then see if you can get the EZGUI help file (and maybe some sample source code). Its unfortunate (IMO) that Chris doesn't have a trial version, but you can probably get a good feel for how EZGUI differs by looking over the help file or seeing some sample code.

    The bottom line though is personal preference. I can guarantee you that you'll not go wrong with either product. I own both, and I use both depending on what the task at hand is.
    Software makes Hardware Happen


    • #3
      FireFly and EZGUI take different approaches to software design.

      FireFly generates 100% source code for the app and the designer generates a lot of code for you. Support code is supplied (ie. Wrappers for common tasks) in source code form as well.

      EZGUI uses a runtime (DLL) for all its support code. The Designer generates source code which only calls the runtime library, rather than the Windows API directly.

      As Joe said, FireFly is more like VB, than EZGUI.

      If you prefer 100% source code then FireFly is definitely the way to go. Also if you require ActiveX control support, FireFly would be better.

      FireFly is very impressive and continues to improve in each new version.

      EZGUI uses a totally different approach which is why I usually encourage potential customers to check out all the other Designers first (ie. download trial versions) before making the decision to buy EZGUI. EZGUI's approach may not appeal to some programmers, but for those that it does appeal to it is very productive.

      What makes EZGUI different ?

      First, EZGUI is not a set of wrappers or a support code library.

      It is a complete GUI engine.

      What does that mean ?

      It basically handles all the GUI tasks in your application including events.
      EZGUI translates common API messages (Windows true form of events) into Events which are easy to work with. When ever possible EZGUI handles as much mundane stuff as possible, so you can concentrate on what you want your application to do. EZGUI delves into areas not usually delt with by other designers. For example is has its own Graphic engine which can be used for everything from printing to the printer to customizing controls (via Ownerdraw) and even customizing the Common Dialogs (EZGUI can actually modify the look of the common dialogs, changing their buttons to 3D ownerdraw buttons and even adding secondary forms and controls to the dialogs).

      EZGUI even sports its own Sprite engine, built into the Canvas control so you can animate non-rectangular images on top of the Canvas control.

      EZGUI has its own Thread engine (for adding worker threads and syncronizing the worker threads with the main GUI thread).

      EZGUI does support third party custom controls which come in DLL form, like EGrid, SIGrid, GDImage.

      It also has a number of very high level features, not found in other tools.

      One example is the Drag Icon feature for the Listview and Treeview controls. With just a few lines of code, you can impliment draggable items for these controls with custom drag icons. This is not easy using the Windows API directly, but EZGUI makes it a breeze (simple).

      Your can download a portion of the EZGUI 4.0 Help file with all the commands in it from here:

      You read more info about EZGUI 4.0 Pro here:

      Here are some screenshots of actual applications created by EZGUI users (note: these apps all were created with EZGUI 3.0 and not 4.0. I haven't updated the page with newer 4.0 apps yet) :
      Chris Boss
      Computer Workshop
      Developer of "EZGUI"


      • #4
        That's a tough question and it has been debated in these forums many times. You will find arguments for and against both products (as well as PB's PBforms and Dominique's Phoenix Designer). Chris and myself work hard on our products and are very proud of them. You can try the FireFly 30 day trial to see if it fits your liking. You can ask questions over on my PlanetSquires forums as well. Many of your initial questions may already have been asked and answered over there.

        Also, FireFly 3 is still in development but it will expand greatly on the basic FireFly concepts that are present FireFly 2. Once you get familiar with FireFly then progressing to FireFly 3 is extremely easy.

        I wish you the best in your search for a PowerBASIC visual designer. I have never used Chris' EZGUI so I am not in a position to fairly evaluate it against FireFly, nor would I do so because such a comparison would be selfishly slanted because having used FireFly for so long, I would find other approaches not to my liking.

        Like Joe said, if you have ever used Visual Basic (say version 5 or 6), then FireFly should be very familiar and quick to get up and running. It has an integrated visual designer and code editor built in. It allows for seamless/transparent navigation between your visual GUI and the underlying code. Simply point and click to create the GUI elements and then add code in the code editor to respond to the various message handlers. Compile and run without ever having to deal with the generated code. Simple.
        Paul Squires
        FireFly Visual Designer (for PowerBASIC Windows 10+)
        Version 3 now available.


        • #5
          Originally posted by Jim Dunn View Post
          Would anyone be willing to give me a quick comparison of EZGUI vs FireFLY (other than FireFLY being cheaper?)

          Hi Jim

          An another great product for developing software is PwrDev from Edwin Knoppert. You can find it here.

          See this Post from Edwin, too.
          Last edited by Joerg Buckel; 22 Sep 2008, 02:07 PM.
          • J. Buckel
            Amicus certus in re incerta cernitur.
            Marcus Tullius Cicero


          • #6
            Joe, thanks for the info -- I downloaded FireFLY 2.91 last night; tried to compile a simple form with no controls; got TCITEM errors; even when trying to compile their samples...

            So I guess I'll try to find an eval of EZGUI...

            "Ok, yes... I like pie... um, I meant, pi."


            • #7
              Hi Chris,

              Thanks for the in-depth reply about EZGUI. I usually don't like "additional DLLs" to distribute, but my laziness says I should consider it since it sounds so powerful (and easier than coding everything by hand!!!)

              Would you ever consider putting together a "demo" video on youtube, or a demo using Captivate (or the free so we could "see it in action" ???

              Thanks again!
              "Ok, yes... I like pie... um, I meant, pi."


              • #8
                Paul, thanks for the reply -- I did try the FireFLY 2.91 last night; tried to compile a simple form with no controls; got TCITEM errors; even when trying to compile the samples projects...

                Have you resolved this TCITEM error?

                "Ok, yes... I like pie... um, I meant, pi."


                • #9
                  Thanks Joerg, I'll check it out!!!
                  "Ok, yes... I like pie... um, I meant, pi."


                  • #10

                    It may be helpful if you describe what kind of software you want to design.

                    There are a number of alternatives in the Designer area and a lot may depend upon your needs. For example which controls do you need support for ? Will you do a lot of graphics ?

                    Also what is your programming background ?

                    There is a big difference between those who come from a DOS programming background and those say from a VB background.

                    Feel free to ask any questions before purchasing ( [email protected] )
                    Chris Boss
                    Computer Workshop
                    Developer of "EZGUI"


                    • #11
                      Originally posted by Jim Dunn View Post
                      Paul, thanks for the reply -- I did try the FireFLY 2.91 last night; tried to compile a simple form with no controls; got TCITEM errors; even when trying to compile the samples projects...

                      Have you resolved this TCITEM error?

                      Hi Jim,

                      I am not sure why you would see that error. The TCITEM variable implies that a TabControl is active on your Form. You say that the same error occurs with the samples? Very strange. I could not replicate the error here and I tried mulitple different settings.

                      What compiler are you using? You're not using the PBCC compiler are you? You are compiling and running from inside the visual designer rather than using the CODEGEN_*.* files directly?

                      Do you have the compiler references in FireFly set up correctly? They should look something like the following:

                      PBWIN Compiler:

                      Include Path:


                      RC Compiler:

                      RC Include Path:

                      Send me an email at [email protected] if you would prefer to deal with this in private. Thanks!
                      Paul Squires
                      FireFly Visual Designer (for PowerBASIC Windows 10+)
                      Version 3 now available.


                      • #12

                        EZGUI and Firefly use a different style of coding. There is also PwrDev. In addition PowerBASIC Forms.

                        I've purchased all three and to date have used EZGUI and Firefly for actual projects. I have yet to use PwrDev for a in depth project.

                        All three are great products. They have differences and depending on the project I may choose a different approach.

                        EZGUI - Generates the code for forms. Use any editor to add code behind the controls. Includes a lot of controls, and extras. The downside is DLL(s) need to be included with the project. The DLLs can be bundled into a PE Exe using a tool such as Molebox or other similar tools.

                        EZGUI has the ability to run plug-ins. I haven't written one yet, but do plan to. With a plug-in, the generated code can be modified. This allows some customization.

                        FireFly - Since I have programmed in VB before moving to PB, I am more comfortable using FireFly. The style is similar to the VB editor, but it has its differences. There are things that can be done in VB that can't be done in Firefly (Also things that can be done in FireFly that can't be done in VB). Nice thing about Firefly is all the code is generated and compiled into an exe. There are no DLLs that need to be included with the project. I've used Firefly more often because I am more familiar with its style coming from a VB background.

                        I can't comment to much on PwrDev as I have yet to use it for a real project.

                        The choice really depends on the type of projects you're planning to create and maybe your background.

                        Originally posted by Jim Dunn View Post
                        Would anyone be willing to give me a quick comparison of EZGUI vs FireFLY (other than FireFLY being cheaper?)



                        • #13
                          Brian makes some good observations.

                          This is why it is important to examine your needs.

                          For some having no runtimes (DLLs) is important.

                          Having an evironment similiar to VB is important to some.

                          In these areas FireFly has the advantage.

                          While with EZGUI a runtime at times may appear to be a downside, it does have an advantage at other times.

                          The use of a runtime does have some advantages.

                          (1) The runtime is fully tested, so you don't have to worry about problems with execution of the app. It is more difficult to fully test all possible combinations of generated code. Not that 100% source can't be reliable, it can. It just that EZGUI has a good track record of reliability and this gives confidence when building applictaions.

                          (2) Modular design of a good runtime produces smaller applications at a certain point. Initially, 100% source code apps will obviously be smaller, but as the size of your application grows there will be a point where a runtime will produce the smaller application, especially when you use many of its features and the app contains many, many forms/controls.

                          (3) Some things are best done using a well designed runtime. Why ?
                          I have found that some API tasks can be quite complicated and they may rely on a number of complex APIs to work. While it could be done using 100% source code, it opens up the possiblity for more problems. A simple error in a win include file could wreak havoc to the code (and I have found a number of errors in api includes). Also it is easier to integrate code in a runtime to make the task easier to handle the task. Since the runtime is already handling a number of tasks, the new task may not require as much code to impliment.

                          I know some may take me to task on this, but I am the only third party developer using a runtime design for a Visual Designer, so I do have some experience in this area. Also I am currently developing a number of 100% source code Designers (for DDT) as well and I can see how difficult it is to impliment many of the features in EZGUI using pure source code.

                          As an example of how integration in a runtime benefits EZGUI take for example EZGUI's ownerdraw engine.

                          I am not sure if any of the other designers offer any advanced ownerdraw features, but EZGUI has an ownerdraw engine which depends upon the integration of a number of other features found in the runtime.

                          For example, ownerdraw requires graphic support. True the Windows API does have graphic commands, but when you start moving beyond simple text drawing or simple shapes, things can get a bit complex. Also the more complex your drawing code the greater possibility of resource leaks, since Windows requires you always return a DC back to its original state and a number of resources need to be deleted properly.

                          EZGUI has its own graphic engine, which has many advanced features (ie. imagelists, bitmaps, icons, gradients, polygons, polybeziers) which can be accessed via the ownerdraw engine. Also EZGUI handles all the mundance stuff and makes sure resources are handled correctly and deleted when necessary. No resource leaks here.

                          Not only does EZGUI simply working with ownerdraw and make it more reliable, but it even builds upon its own ownerdraw engine. For example it has a simplified ownerdraw command set which allows you to draw a number of items with one line of code in the ownerdraw event. Also it has builtin support for 2D and 3D colored buttons.

                          EZGUI goes even further. It impliments two of its custom controls, by superclassing an ownerdrawn listbox. The Properties Listbox and Files Listbox take advantage of the integrated ownerdraw engine.

                          The point is that EZGUI is more than just hundreds of API wrappers, but is an integrated GUI engine which has many parts taking advantage of other parts.

                          Compared to say Visual Basic, the EZGUI main runtime does much, much more in a smaller amound of space (size). The VB 5.0 runtime is 1.4 meg in size. The EZGUI 4.0 Pro runtime is only 515 KB in size and in that space it contains not only full support for the Common controls and Common dialogs (which require extra OCX's in VB), but is also has a complete graphics engine, 4 custom controls (Shape/Hot Spot, Canvas Control, Files Listbox and Properties Listbox), a Thread engine, a subclass engine, RichEdit support (requires an OCX in VB) and much, much more.

                          Compared to VB, EZGUI contains a huge number of advanced features in a much smaller size.

                          It is the runtime approach that allows EZGUI to do so many things. I could never do anything close to what EZGUI does in a 100% source code version of my Designer (also I would lose protection for a significant amount of proprietary code, like my Sprite engine).

                          If you are building large commercial applications, then EZGUI is quite efficient and a reasonably sized DLL is of little consequence. Even many professional level compilers depend upon DLL's (ie. MFC and other C runtimes).

                          Powerbasic doesn't currently support embeding external libraries into an EXE (linking external object files), so the use of a DLL is the only way to provide precompiled external libraries.

                          There is a reason for the runtime approach. In some instances a pure 100% source code may be better and desired. Yet, there are times when a runtime approach has advantages and when its does, it can make a big difference.
                          Chris Boss
                          Computer Workshop
                          Developer of "EZGUI"


                          • #14
                            Just to demonstrate how modular and efficient EZGUI 4.0 Pro is compared to Visual Basic 5.0 Pro when it comes to runtimes, let's look at the runtimes needed for a VB app.

                            To get all the controls, common controls, common dialogs and the richedit control all supported in EZGUI's main runtime (which is 515 KB in size) the following runtimes would be needed for a Vb 5.0 Pro app:

                            msvbvm50.dll - 1324 KB
                            comdlg32.ocx - 150 KB
                            comctl32.ocx - 595 KB
                            comct232.ocx - 161 KB
                            mscomct2.ocx - 633 KB
                            richtx32.ocx - 208 KB

                            Totol - 3071 KB

                            Now remember, that EZGUI provides a number of advanced features beyond these basic controls not readily found in VB. For example the Common dialogs can be customized and modified (by adding other forms and controls to them, converting buttons to 3D buttons and more). A number of controls can be customized via EZGUI's ownerdraw engine. EZGUI also provides a number of builtin custom controls not found in the main VB runtimes, like the Canvas control with its Sprite engine, the properties listbox control, etc.

                            EZGUI accomplishes all of this in about 1/5 the size of the comparable VB runtimes. Compare 515 KB to 3071 KB. Now thats efficient. (it should be noted that EZGUI was written in PB 6.1).

                            I could list a number of key features in EZGUI, not found in VB's main runtimes.
                            Chris Boss
                            Computer Workshop
                            Developer of "EZGUI"


                            • #15
                              Just to demonstrate how modular and efficient EZGUI 4.0 Pro is compared to Visual Basic 5.0 Pro
                              I must have missed the announcement that EZGUI is now a complete development environment with integrated editor, compiler, linker and stepping debugger.

                              You are comparing apples and oranges... no, it's not even that close... more like horseapples and oranges.

                              Michael Mattias
                              Tal Systems (retired)
                              Port Washington WI USA
                              [email protected]


                              • #16

                                I am comparing the use of runtimes and nothing else.

                                VB depends upon runtimes, rather than compiling 100% to pure machine language. The runtimes do most of the work and what is compiled is far less than would be the case if no runtimes were used.

                                The comparison is valid, since VB requires that many runtimes to support the same controls and common dialogs as EZGUI. What I am comparing is not the compiler (or EZGUI compared to the entire VB environment), but the use of runtimes to handle most of the GUI tasks.

                                The comparison is quite fair, since there is no other way to get support for those features in VB without the runtimes VB needs.

                                VB and EZGUI are quite similiar actually in that the EXEs are quite small compared to the non-runtime counterparts created using other means.
                                Because so much of the apps code is really simply calls to a runtime, the compiled EXE is small. This is similiar to EZGUI since its runtime does so much, that little code really needs to be compiled into the EXE.

                                For those who complain about using a runtime with Powerbasic, I don't see any difference with that and those who use Visual Basic, which also requires runtimes (like using EZGUI with PB). It is fair to compare the size of those runtimes (EZGUI and VB), since ultimately the size of the entire application is the EXE and any distributable runtimes needed (DLLs, OCXs).

                                It is actually comparing "apples to apples" IMO. The only difference is that VB is both compiler, designer and runtimes, while EZGUI is only the designer and runtimes and requires the PB compiler to be complete.

                                One of the biggest complaints I hear about EZGUI on the forums is the need for runtimes and how "bad" this is (or at least undesirable). Comparisons to VB come closest to what EZGUI really is (runtimes) and EZGUI stands quite favorably to VB (as far as runtime features). I won't say that the EZGUI designer is on par with the VB designer, but its runtime surely has many advantages to VB and is worth comparing.

                                Try to build a huge complex application with VB, using as many features as is found in EZGUI, and I doubt it will fit on a floppy disk or even a couple disks, whereas the EZGUI app likely can fit on a floppy and can simply be copied to a harddrive (no registration of components).
                                Chris Boss
                                Computer Workshop
                                Developer of "EZGUI"


                                • #17
                                  It should be noted that I paid as much for Visual Basic 5.0 Pro (about $450) as it would cost for Powerbasic and EZGUI combined. The Powerbasic and EZGUI combination is a fair comparison to the VB 5.0 Pro package. EZGUI integrates itself into PB, via its Smart Parser, so you can make the two work together seamlessly.

                                  The coding style of course is different (not OOP) and the Designer environment is different (non-VB like), but the final results are the same. A Visual Designer and Compiler combination (and runtimes) which allow you to build advanced, fast and small applications.
                                  Chris Boss
                                  Computer Workshop
                                  Developer of "EZGUI"


                                  • #18
                                    Originally posted by Chris Boss View Post
                                    EZGUI accomplishes all of this in about 1/5 the size of the comparable VB runtimes. Compare 515 KB to 3071 KB. Now thats efficient. (it should be noted that EZGUI was written in PB 6.1).

                                    I could list a number of key features in EZGUI, not found in VB's main runtimes.

                                    So, is that the last version of PB you have? How come it wasn't compiled with later versions to gain features to make it even better? Some statements are kind of confusing too...while this is the best thread I've seen about EZGUI so far and keeping to task and not bashing...the descriptions you give do seem to become book-like. Sometimes I get confused with what exactly EZGUI is. If bought does it come with everything needed but the compiler? I keep seeing posts that make it sound like PB Forms where it just designs the forms and you have to open the code in another IDE to edit/find where to edit/insert your code to make it all work. If that is the case, then Michael's comment may even apply to not only comparing to VB, but FireFly since all that is missing from it is a compiler. Often times I have just FireFly, the BIN files of PB's Compiler and the inc fileson a USB stick to compile my apps. For the price, I'd think everything should be included that is needed (Except Compiler).

                                    Also, what happened to Phoenix? It looked pretty cool and did things close to how FireFly did it, but more advanced. It was a little buggy when I originally tried it, but looked like it could be something once polished.
                                    Mobile Solutions
                                    Sys Analyst and Development


                                    • #19

                                      I have PB versions 5.0, 6.1, 8.0 and now 9.0.

                                      Technically I have two licenses for Powerbasic.

                                      Version 6.1 is for software development on EZGUI.

                                      Version 8.0/9.0 are for testing, particularly DDT code generation.

                                      Why compile EZGUI with PB 6.1 ?

                                      Each new version of Powerbasic increases the size of its runtime code (which is compiled into your app). I use PB 6.1 to keep the size of the EZGUI runtimes down as much as possible. Since I write pure SDK style code in EZGUI (calling the Windows API), I don't require DDT and I don't require any of the other improvements since PB 6.1. I would rather keep the EZGUI runtimes as small as possible.

                                      I also have to be very careful of the API includes I use. I don't want to accidently break anything with a new include file. I have used the same include files for years and I simply add missing declares and constants to it. This prevents me from accidently breaking something in EZGUI.

                                      When compiling DDT applications (using my new DDT Designers), I use the latest PB compiler and the includes that come with them.

                                      I may write some tools in PB 9.0 since it has some nice features, particularly with COM, but they won't be in the main EZGUI runtimes, but would only be added as separate DLL's.

                                      As far as your other questions:

                                      EZGUI is not like any other Visual Designer for PowerBasic.

                                      The main difference is the approach to code generation and how to impliment features.

                                      All the other Designers generate 100% source code (some may come with DLLs for custom controls, but the main apps code is pure source).

                                      EZGUI uses a runtime DLL which is required for all applications created with it.

                                      Why a runtime DLL ?

                                      I'll try to explain it so it makes sense.

                                      100% source code apps, have all the message loop, window procedure (or dialog procedure) code in your apps source code (or via a include file).

                                      EZGUI's main runtime DLL has the message loop, one universal window procedure and all support code in a DLL. In essence, the EZGUI DLL is the application core code.

                                      When an EZGUI app starts up, it calls a single function in EZGUI and EZGUI takes control of the application. It then calls a single startup routine in your apps code (EZ_Main) where you can define your first form. Once EZ_Main finishes execution, control reverts back to the EZGUI runtime. EZGUI's runtimes internal message loop is processing input and its internal universal window procedure processes all the messages.

                                      When a form is created (using the EZ_Form command), the runtime will generate a call to the application to request the creation of the controls for that form (calling EZ_DesignWindow) where you can make calls to EZGUI using the control creation commands. Once the controls have been added, then control reverts back to EZGUI.

                                      Now the only time code in your app will be executed, is when an event occurs. EZGUI has its own event engine, where it processes all the window messages for your forms (or controls if subclassed) and it will send your program an event (calling EZ_Events which parses out the event to unique routines for each control and form).

                                      When your app gets an event, you then cna use EZGUI commands in that event to do what ever you want (as well as anything else you can do with PB).

                                      Here is a flow chart of an EZGUI application, in relation to the main runtime DLL:

                                      It is important to understand that some EZGUI commands, will them selves generate events.

                                      For example, when you create a control, EZGUI generates the %EZ_Loaded event for that control and the event is sent to your apps code (first through EZ_Events, which then parses it out to the forms and controls unique event routines).

                                      EZGUI is an Event based, GUI Engine.
                                      Last edited by Chris Boss; 24 Sep 2008, 10:47 AM.
                                      Chris Boss
                                      Computer Workshop
                                      Developer of "EZGUI"


                                      • #20
                                        I have often compared EZGUI's GUI engine design as something different than just a set of API wrappers. It is not a set of wrappers (not that wrappers are bad or anything). It is an engine, since most of the time your app is executing, it may be spent in the EZGUI runtimes. Because EZGUI handles the message loop, all message processing (in its universal window procedure), your app only needs to respond to events.

                                        Now EZGUI does allow you to add "hooks" into its internal message loop or window procedure, so advanced API programmers can extended it or modify it. Most apps don't require such hooks though.

                                        In most pure source code apps, each dialog (form) has its own dialog (or window) procedure.

                                        EZGUI uses just one universal window procedure for the entire application (which is in the runtime). EZGUI forms are a unique window class, which is a superclass of the Dialog class in windows. This unique class, can act as a dialog, and also as a MDI parent or a MDI child. EZGUI knows which type of form (dialog) you want and handles default message processing based on that. EZGUI doesn't need to create a unique window class for dialogs, a unique class for MDI parents, a unique class for MDI children. It uses one class for all of them. You might call it a hybrid window class.

                                        Because EZGUI's runtime uses a universal window procedure for all forms (dialogs), this modular design decreases total application size significantly as you add more forms.

                                        The same is true for subclassing. EZGUI uses 2 unique subclassing window procedures internally. One for the drag and drop engine (for creating your own Visual Designer style app) and one for general subclassing. Again this modular design allows you to subclass hundreds of controls, all using just two internal routines. This saves on total application size.

                                        EZGUI is a reliable GUI Engine.

                                        Now another area where a runtime makes a big difference is in reliability when compiling. Since EZGUI apps don't require using the windows API includes, you don't have problems with errors in inlcude files. Since the runtime engine makes all the calls to the operating system, using the correct syntax, types, constants, etc., you never have to worry about getting an API call wrong. You don't have to worry about cryptic compiler messages for a bad API call. Some errors when calling the API, won't generate a compiler error (ie. wrong type definition or incorrect declare) which is worse, since it simply makes your app crash, without knowing why. EZGUI eliminates this, since your app only makes EZGUI calls and not the API and EZGUI comes with its own include file of EZGUI declares. Since all API calls have been precompiled (in the runtimes), you are never having to call the API directly, so it eliminates the common compiling errors when using the API includes.

                                        Another benefit of a GUI engine is parameter testing.

                                        Since most PC's are quite fast today, the extra overhead of testing parameters does't slow down an app very much. EZGUI commands in the runtime, will test many pass parameters to make sure that they are within proper limits that the windows API expects when EZGUI makes calls to the API. This makes your apps less prone to crashes, since EZGUI is testing the parameters you pass to its command set. Most, if not all pure source code generators can't afford to add parameter testing, since this would add a significant amount of extra code. Since EZGUI uses a universal GUI engine, it can do this quite effectively.

                                        EZGUI goes as far as testing the class names of controls to make sure the call is made to the correct control type. If you use a command, which was meant for say the Turtle control with a Label control, EZGUI will ignore it, since it will test the control class to see if it is the right one.

                                        EZGUI is a complete GUI engine. (see: )

                                        EZGUI now only handles all message processing (Message Loop and Window Procedure), it provides a complete command set for nearly all the controls in Windows. I don't add a new control to EZGUI, without supplying a complete command set to work with that control.

                                        EZGUI comes with a number of its own custom controls (ie. Canvas, Turtle Graphics, MCI, etc.)

                                        EZGUI has a graphic engine for drawing to controls (ownerdraw), to a DC directly, to the Canvas control and to the Printer.

                                        It handles many things not even touched upon by other Designers. Its ownerdraw engine is extensive and you can customize the look of a number of controls (and menus) in ways not easily done with other tools.
                                        Last edited by Chris Boss; 24 Sep 2008, 10:52 AM.
                                        Chris Boss
                                        Computer Workshop
                                        Developer of "EZGUI"