No announcement yet.

EZGUI 4.0 - Unique Features

  • Filter
  • Time
  • Show
Clear All
new posts

  • EZGUI 4.0 - Unique Features

    I have discussed a number of EZGUI's features in this forum before.

    Here I would like to mention a few of the overlooked features which
    make EZGUI quite unique.

    (1) Drag and Drop Visual Engine.

    When building the EZGUI runtime engine, in each new version I
    added features to it that I needed for building (or improving)
    the Visual Designer. EZGUI's Visual Designer is itself a 100%
    EZGUI application. Not a single API call is made directly by the
    Designer. Only EZGUI calls are made.

    What does this mean for you ?

    Have you ever wanted to build a Visual Designer like application ?

    Maybe you would like to build your own Visual Designer/Code generator
    instead of using others Designer.

    Maybe you would like to build a WYSIWYG type app such as a report
    generator, a paint program or some other drag and drop style app.

    EZGUI has all the features in it to build such applications.
    It can easily do the so called "rubberbanding" when sizing an
    object. It can drag amd drop controls. It has its own Drag Handle
    control which makes adding drag handles to objects very easy.

    I don't believe there are any other tools available for PB which
    offer this feature.

    (2) Ownerdraw Engine

    Because EZGUI combines a number of different engines into one
    product, it can offer features which are not so easily available
    in other products. EZGUI has a graphic engine (for use with its
    Canvas control). By combining this with an OwnerDraw engine
    (EZGUI does all the hard stuff for you), it allows you to
    customize the look and feel of many different controls (like the
    Button, label, ComboBox, ListBox, Listview and menus). EZGUI even
    goes further in that version 4.0 has a new Simplified OwnerDraw
    command set
    . This allows you to customize a variety of controls
    with just a few lines of code. The simplified command set makes it
    so easy, you can add some advanced stuff to your GUI's easily.

    One of the simplist things to do with ownerdraw are the 2D and 3D
    colored buttons. It takes only a couple lines of code to have
    2D or 3D colored buttons. The designer allows you to define them
    visually as well. Also the designer supports ownerdraw button plugins
    so you can use your own customized 2D and 3D buttons in the designer.
    2 plugins are already provided (generates 100% EZGUI source code, so
    no extra DLL's).

    (3) DIB Engine

    DIB's (device independent bitmaps) offer some exciting possibilities
    for software development. EZGUI's DIB engine works alone (create
    a picture/bitmap but a DIB, not DDB) or in the Canvas control.
    The Canvas control supports DIBs as well for its buffers (even
    double buffers).

    The nice thing about EZGUI's DIB engine is that you don't have to
    move pixel data to access it. You don't do a GET action to
    get the DIB pixels, modify it and then SET them back. EZGUI gives you
    direct access to the DIBs (even in the Canvas control) via pointers.

    You can write apps that modify the DIB buffers which are much faster
    because you don't move pixel data around.

    What can you do with the DIBs ?

    A good example is a photo editing program.

    Here is a complete example of a simple photo editing program
    written using EZGUI. It can convert bitmap images from 32 bit
    color to:

    blue only -
    red only -
    green only -
    blue tint -
    green tint -
    red tint -
    gray scale -

    Original Image -

    Now here is the source code for the entire app:

    ' *************************************************************************************
    '                    Portions: Copyright Christoper R. Boss, 2003 to 2006
    '                                    All Rights Reserved !
    ' *************************************************************************************
    #DIM ALL
    ' --------------------
    #INCLUDE "..\includes\"
    ' --------------------
    DECLARE SUB Form1_Display(BYVAL Parent$)
    DECLARE SUB Form1_Design()
    DECLARE SUB Form1_Events(CID&, CMsg&, CVal&, Cancel&)
    DECLARE SUB UseFilterOnBitmap(BYVAL Mode&)
    GLOBAL FORM1_hMenu0&
    GLOBAL FORM1_hMenu1&
    ' --------------------
    #INCLUDE "..\includes\"
    ' --------------------
    SUB EZ_Main(VerNum&)
        Form1_Display ""
    SUB EZ_DesignWindow(FormName$)
        SELECT CASE FormName$
            CASE "FORM1"
            CASE ELSE
        END SELECT
    SUB EZ_Events(FormName$, CID&, CMsg&, CVal&, Cancel&)
        SELECT CASE FormName$
            CASE "FORM1"
                Form1_Events CID&, CMsg&, CVal&, Cancel&
            CASE ELSE
        END SELECT
    SUB Form1_Display(BYVAL Parent$)
        FORM1_hMenu0&=EZ_DefMainMenu( 500, "&File", "")
        EZ_Color -1, -1
        EZ_Form "FORM1", Parent$, "Compress Bitmaps", 0, 0, 80, 28, "C_"
    SUB Form1_Design()
        FORM1_hMenu1&=EZ_DefSubMenu( 505, "&Select Bitmap File", "")
        EZ_SetSubMenu FORM1_hMenu0& , 500, FORM1_hMenu1&
        EZ_AddMenuItem FORM1_hMenu1&, 510, 0, "-", ""
        EZ_AddMenuItem FORM1_hMenu1&, 511, 0, "Show Red Only", ""
        EZ_AddMenuItem FORM1_hMenu1&, 512, 0, "Show Blue Only", ""
        EZ_AddMenuItem FORM1_hMenu1&, 513, 0, "Show Green Only", ""
        EZ_AddMenuItem FORM1_hMenu1&, 514, 0, "Limit Color Planes to High 4 Bits", ""
        EZ_AddMenuItem FORM1_hMenu1&, 515, 0, "Limit Color Planes to Low 4 bits", ""
        EZ_AddMenuItem FORM1_hMenu1&, 516, 0, "Show Blue Only 14 Bit", ""
        EZ_AddMenuItem FORM1_hMenu1&, 517, 0, "Show Green Only 14 Bit", ""
        EZ_AddMenuItem FORM1_hMenu1&, 518, 0, "Show Gray Scale 7 Bit", ""
        EZ_AddMenuItem FORM1_hMenu1&, 519, 0, "Show Red Tinted", ""
        EZ_AddMenuItem FORM1_hMenu1&, 520, 0, "Show Green Tinted", ""
        EZ_AddMenuItem FORM1_hMenu1&, 521, 0, "Show Blue Tinted", ""
        EZ_AddMenuItem FORM1_hMenu1&, 528, 0, "Display Original", ""
        EZ_AddMenuItem FORM1_hMenu1&, 530, 0, "E&xit", ""
        EZ_Color 0, 15
        EZ_UseFont -1
        EZ_UseFont -1
        EZ_Canvas 100, 0, 0, 80, 28, "+{DIB}{DBUF}"
    SUB Form1_Events(CID&, CMsg&, CVal&, Cancel&)
            CASE %EZ_Window
            CASE 500     ' &File
                IF CMsg&=%EZ_Click THEN FORM1_FILE_Select
            CASE 505     ' &Select Bitmap File
                IF CMsg&=%EZ_Click THEN FORM1_OPENBITMAP_Select
            CASE 510     ' -
            CASE 530     ' E&xit
                IF CMsg&=%EZ_Click THEN FORM1_EXIT_Select
            CASE  100
            CASE 511 TO 528
                IF CMsg&=%EZ_CLick THEN
                    UseFilterOnBitmap CID&-510
                END IF
            CASE ELSE
        END SELECT
    SUB FORM1_FILE_Select()
        LOCAL F$, P$, CW&, CH&, W&, H&, AW!, AH!
        EZ_Color -1,-1
        F$=EZ_OpenFile("Form1","Select Bitmap :", "", "Bitmaps (*.bmp))|*.bmp|", "S")
        IF F$<>"" THEN
            EZ_GetPictureSize P$,  W&,   H&
            ' convert to character units and resize canvas control
            AW!=EZ_ScaleToCharSize(W&, "PX")
            AH!=EZ_ScaleToCharSize(H&, "PY")
            EZ_ResizeC "Form1", 100, (80-AW!),0, AW!, AH!
            EZ_GetCanvasSize "Form1", 100, CW&, CH&
            ' draw picture on canvas
            EZ_StartDraw "Form1", 100, CW&, CH&, ""
                EZ_CDrawPicture  0,0,  W&, H&, P$, ""
                EZ_CCopyBuffer 1,2,0
            EZ_FreeImage P$
        END IF
    SUB FORM1_EXIT_Select()
        EZ_UnloadForm "Form1"
    ' this is the format for 32 bit RGB pixels
        B   AS BYTE
        G   AS BYTE
        R   AS BYTE
        Reserved AS BYTE
                                    ' Best      Good        Low     Poor
    %GreenShift       =   4&        ' 4         8           8       16
    %RedShift       =     16&        ' 4         8           16      16
    %BlueShift       =    16&        ' 4         8           16      32
    SUB UseFilterOnBitmap(BYVAL Mode&)
        LOCAL CW&, CH&, FirstPixel&, YB&, X&,Y&,PY&, V&, VT&
        LOCAL P AS EZ_RGB32 PTR, BitMask?, BitMul?
        EZ_GetCanvasSize "Form1", 100, CW&, CH&
        EZ_StartDraw "Form1", 100, CW&, CH&, ""
        ' copt buffer 2 to buffer 1 to get original to work with
        EZ_CCopyBuffer 2,1,0
        FirstPixel& = EZ_StartDrawByPtr("Form1", 100, 0)
        IF FirstPixel&<>0 THEN
            FOR Y&=0 TO (CH&-1)
                FOR X&=0 TO (CW&-1)
                    SELECT CASE Mode&
                        CASE 1
                            @P.R=(@P.R AND BitMask?)*BitMul?
                        CASE 2
                            @P.B=(@P.B AND BitMask?)*BitMul?
                        CASE 3
                            @P.G=(@P.G AND BitMask?)*BitMul?
                        CASE 4
                            ' high 4 bits
                            @[email protected] AND 240
                            @[email protected] AND 240
                            @[email protected] AND 240
                        CASE 5
                            ' low 4 bits
                            @P.R=((@P.R AND 15)*16)
                            @P.G=((@P.G AND 15)*16)
                            @P.B=((@P.B AND 15)*16)
                        CASE 6
                            ' 18 bit color shows little or no loss
                        CASE 7
                            ' 18 bit color shows little or no loss
                        CASE 8
                            ' GrayScale
                            V&=(@[email protected][email protected][email protected][email protected][email protected])\6
                            ' V&=(V&\2)*2
                        CASE 9
                            ' Red Tinted
                            V&=(@[email protected][email protected])\3
                            V&=V&+164:IF V&>255 THEN V&=255
                        CASE 11
                            ' Blue Tinted
                            V&=(@[email protected][email protected])\3
                            V&=V&+128:IF V&>255 THEN V&=255
                        CASE 10
                            ' Green Tinted
                            V&=(@[email protected][email protected])\3
                            V&=V&+80:IF V&>255 THEN V&=255
                        CASE ELSE
                    END SELECT
                NEXT X&
            NEXT Y&
        END IF
    The app uses a Canvas control with 24 bit DIB buffers. It uses
    double buffers, one to store the original image and the other
    to store the modified one.

    Combine EZGUI's graphic engine, Canvas control and its DIB engine
    then you can do all sorts of advanced graphics, not easily done with
    other tools.

    Chris Boss
    Computer Workshop
    Developer of "EZGUI"
    Chris Boss
    Computer Workshop
    Developer of "EZGUI"

  • #2
    (4) Threads

    Now this may seem simple at first, since PB has some
    thread commands, but EZGUI goes far beyond this.

    First all of EZGUI's thread commands call the API directly.
    They don't use any of the PB thread command internally.
    This is because I need to go beyond some of the basics
    of threads.

    First of all, one expert on threads, suggests that all GUI
    code be in the main thread and only non-GUI code be in
    worker threads. I fully agree with this and EZGUI follows this
    principle. The problem is how do you communicate properly
    between the worker threads and the main thread, so you can
    use the main thread to modify your GUI, while using your
    worker threads to do calculations ?

    EZGUI has a thread engine which handles all of this for you.
    It uses critical sections internally at the right time to
    control communication between threads and the main thread.

    EZGUI has an extensive command set for working with threads,
    even at a low level.

    EZGUI 4.0 though goes a step further!

    The new simplified thread command set was added to EZGUI 4.0.
    This command set makes working with threads even easier that ever.
    EZGUI even tracks your threads and shuts them down for you when your
    app terminates, even if you forget to do it. The Threads generate events
    for you so all you have to do is write code in the events.

    (5)Subclassing Engine

    While subclassing is not too awful hard to do once you learn it,
    it is easy to make errors in subclass code which can cause havoc
    for a program.

    EZGUI offers a subclass engine which makes subclassing a
    "no brainer" as they say. Just add:

    EZ_SubClass 2

    just before the control is created and thats it.

    EZGUI will now generate many new events for the control for you,
    based on the subclass engine. There is even an %EZ_SubClass event,
    where you can process the controls window procedure messages directly,
    if EZGUI does not generate the events you need.

    EZGUI uses the subclassing engine for two purposes.

    First, it uses it for simple subclassing of controls to get
    access to their internal events (messages). It also uses it
    for implimenting the Visual Design drag and drop engine.
    This allows EZGUI to impliment drag and drop for any control
    , even many third party external custom controls. EZGUI can subclas
    the controls and add drag and drop features.

    (6)Event Engine

    When working with the common controls, you have to process the
    WM_NOTIFY message and then parse out notification messages. This
    often requires a good bit of API code, including using structures
    for each event and then returning the correct return values back.

    EZGUI makes handling many of the common notification events for
    the common controls simple. It preprocesses the most common ones,
    gets any necessary info you may need and knows what values to
    return back.

    This makes working with the common controls very simple, since
    all you have to do is respond to a simple event, like %EZ_Selected,
    %EZ_UnSelected, %EZ_DragItem.

    Most EZGUI users do not have to write any WM_NOTIFY code when
    working with the common controls.

    EZGUI also uses universal event constants, rather than unique
    constants for each different control type. This makes coding
    much easier. Why use a different event constant, say for a
    click event, for each different control, when you can use just
    one (%EZ_Click) for all the controls.

    EZGUI's event engine is what makes it unique. The event engine is
    so extensive now in version 4.0, that there aren't many events missing
    for most users. I have often discussed the meaning of EZGUI being
    a GUI engine and this is far more valuable than one may think.

    Some times I mention the large command set in EZGUI. The command set
    is only part of EZGUI. A large portion of its internal code is
    dedicated to its event engine. EZGUI does so much for you behind
    the scenes it is more than you would imagine.

    Chris Boss
    Computer Workshop
    Developer of "EZGUI"
    Chris Boss
    Computer Workshop
    Developer of "EZGUI"


    • #3
      (7) Common Dialog customization

      EZGUI 4.0 goes far beyond just making it easy to display the
      common dialogs. It actually let's you customize them and even
      allows you to process events for some of the controls on the

      EZGUI automatically creates a dialog hook internally to the
      common dialog. It then treats the dialog as if it were an EZGUI
      form, giving names to each dialog. This makes it easy to process
      events for the dialogs controls.

      Here is an example of some EZGUI code which customizes the open file

      To display the dialog:

         EZ_Color 0, -3
         EZ_ChangeDlgButtons -2
         F$=EZ_OpenFile("Main","Select Bitmap:", "", "Bitmaps (*.bmp))|*.bmp|", "PRZ")
      To process events for the dialog and to center it on its parent

      (this code is within the EZ_Events routine)

          CASE "{OPENDLGX}", "{OPENDLG}"
              SELECT CASE CID&
                  CASE %EZ_Window
                        IF CMsg&=%EZ_Loaded THEN
                           DIM CW!, CH!
                           EZ_GetSize FormName$, CW!, CH!,0
                           EZ_ExpandForm FormName$, 30,0
                           EZ_HideC FormName$, -1,-1  ' hide corner scrollbar
                           EZ_Color 0,15
                           ' add a child form with a Canvas on the dialog here
                           EZ_Form "DLGCHILD", FormName$, "", CW!+1, .5, 26, 13,"P"
                           EZ_CenterForm "Main", FormName$,1
                       END IF
                   CASE 1152, 1148  ' textbox on standard dialog or combobox on explorer dialog
                       IF CMsg&=%EZ_Change THEN
                          UpdateCanvas EZ_GetText(FormName$,CID&)
                       END IF
                  CASE ELSE
                       IF CMsg&=%EZ_OwnerDraw THEN
                          DS_Draw3DButton FormName$, CID&, CVal&
                       END IF
              END SELECT
      The code above adds a child form to the common dialog which has
      a Canvas control for display a bitmaps. The common dialog is
      resized to make room for the child form. The ownerdraw events
      for the common dialogs buttons are handled and the textbox which
      has the current filename has its %EZ_Change event processed so
      the filename can be read and then retrieve the filename so it
      can be passed to a subroutine which loads the bitmap and draws it
      on the Canvas control.

      The point is how easy it is to integrate new code and features
      into a common dialog. Because EZGUI handles the internal hook for
      you and treats the dialog like a normal EZGUI form, you can do
      all sorts of things with the common dialogs.

      Here what this common dialog looks like:

      Chris Boss
      Computer Workshop
      Developer of "EZGUI"

      [This message has been edited by Chris Boss (edited July 25, 2007).]
      Chris Boss
      Computer Workshop
      Developer of "EZGUI"


      • #4
        (8) External IDE support

        One of the discussions that came up during development of EZGUI 4.0
        , with Beta testers, was whether the Visual Designer should have
        its own code editor (and be completely integrated) or whether it
        should use an external code editor, so the user could use their
        favorite code editor instead.

        I initially was planning on a builtin editor, but my beta testers
        talked me out of it. They didn't want to lose the use of their
        favorite code editor (many used JellyFish).

        It is more difficult to integrate a Visual Designer with an
        external code editor which the user chooses, than to simply use
        a builtin one. I had to find a solution.

        The result, is the new "Smart Parser".

        The Designer generates code, creates a source file and autoloads
        your favorite code editor (the editor requirement is that it
        support passing a filename as a startup parameter). Where things
        get tricky is when you return to the Designer and edit the forms
        and then regenerate the code. Now the parser has to merge the
        previous code with the changes made by the designer, which is no
        easy task. It also has to remove code for controls that have been
        deleted from a form.

        The EZGUI 4.0 Pro designer does a great job in handling this!

        You can actually move smoothly between the designer and your
        favorite code editor and the smart parser will make all the
        necessary modifications to your source code. It even backs up the
        previous source code, just in case something goes wrong up to three

        The Designer works at a project level. You can move quickly from
        Form to Form. When you want to work on adding code, you simply
        click a toolbar button and the designer quickly regenerates
        your code and displays your favorite code editor with the source
        file loaded.

        The Designer works well with both the PB IDE and JellyFish and
        should work with any code editor that works similiar to these.

        One other feature of the Designer which is very useful is the
        full screen mode. You can actually change the designer so it
        goes into full screen mode, where the client area (of the MDI
        client where the form is displayed in the designer) to full screen.
        The main menu and toolbar disappears, so all you see is your form
        and the project palette window (which can also be folded up so only
        a caption bar shows).

        - Visual Designer in normal mode:
        - Visual Designer in fullscreen mode:

        Chris Boss
        Computer Workshop
        Developer of "EZGUI"
        Chris Boss
        Computer Workshop
        Developer of "EZGUI"


        • #5
          For more info about EZGUI 4.0 Pro:

          Chris Boss
          Computer Workshop
          Developer of "EZGUI"

          [This message has been edited by Chris Boss (edited July 25, 2007).]
          Chris Boss
          Computer Workshop
          Developer of "EZGUI"


          • #6
            (9) Resource Tracking and Cleanup

            One of the nice things about EZGUI is that you don't have to worry
            about cleaning up resources (or DC's). When GDI objects are loaded/created
            (ie. Bitmaps, Fonts, Brushes) EZGUI tracks them. Even menu handles
            (ie. popup menus) are tracked.

            While EZGUI offers commands to delete (or free) such objects if
            you want to, you need not worry about cleaning up when your app
            terminates. EZGUI tracks all such resources and deletes them when
            the app terminates (while Windows may do some cleanup of a process
            when it terminates, it is best to actually explicitly delete such
            objects before the app terminates).

            Also, EZGUI references some GDI objects differently than usual.
            For example, colors (and associated brushes), fonts, cursors,
            and imagelists are referenced by an number (not a handle). This means
            that when they are loaded you don't have to store their handle to
            use later with drawing code. If you do need their handle (for an
            API call) there are functions which return the actual handle by
            referencing their number (as a parameter).

            This makes it easier to code, since you don't have to track
            GDI handles.

            EZGUI also takes care of DC cleanup in its graphic commands.
            It selects GDI objects into the DC, draws and then restores the
            DC back. You never have to worry about selecting objects into
            (and out of) DC's.

            The syntax for selecting colors or fonts is very easy.


            EZ_Color 0, 15 ' black foreground on white background
            EZ_UseFont 3
            ' draw something

            EZ_Color works the same as the DOS Basic color command and
            EZGUI even predefines the 16 default DOS colors.

            With EZGUI you can concentrate on doing things, rather than
            cleaning up afterwards.

            In essence, if EZGUI can cleanup resources for you, it does it.

            Chris Boss
            Computer Workshop
            Developer of "EZGUI"
            Chris Boss
            Computer Workshop
            Developer of "EZGUI"


            • #7
              (10) Canvas control

              While it is true there are some Graphics Tools available for
              use with PB, EZGUI's Graphic control is unique in a number
              of ways.

              (1) It is part of a complete GUI engine and Visual Designer.
              EZGUI is most often compared to other Visual Designer (or front
              ends for PB). In this catagory (rather than just graphic tools)
              it stands alone, since it has its own graphic control and graphic
              engine. This means when you purchase a Visual Designer/GUI engine
              you get graphics along with it, rather than have to buy a separate
              graphic tool. (of course this does not mean that you can't use
              a tool like GDImage if it offers some features you need, since
              EZGUI will support such tools). But if money is tight and you
              have to keep costs down, EZGUI gives you a GUI engine, a Visual
              Designer and Graphics engine.

              (2) The Canvas control is a real windows control. This means you
              can use as many as you like in an app and treat it just like any
              other control. It can be subclassed if need be. But what makes it
              interesting is some of its advanced features, which still will run
              even on Windows 95, such as:

              - draw Polygons and Polybeziers using relative coordinates (no arrays needed)
              - draw gradients, including 3d gradients
              - access EZGUI Turtle graphic engine for a vector based drawing engine
              - draw RTF text retrieved from a RichEdit control
              - work with double buffers (draw on either and copy from one to the other)
              - choice of DBB's (device dependent) or DIB's (device independent in 16,24 or 32 bit) for buffers
              - sprite engine which supports frame animation, anti-aliasing, alphablending
              - sprites are drawable objects themselves (draw on them directly)
              - scrollable buffers

              What Visual Design front end has such powerful graphic capabilities ?

              (11) Layers

              As far as I know, no other Design environment offers Layers.
              When developing EZGUI I needed a way to support Tab controls, so
              I had a choice. Either embed forms (dialogs) on each Tab or use
              the layer technique. I chose layers because they offer advantages
              beyond embeded forms.

              Layers can be used for anything, not just tab controls. Each control
              is assigned a layer and EZGUI tracks them. There is a command to
              display Layers (or multiple layers), so EZGUI can display what ever
              layer you need. This allows you to do all sorts of tricks, far beyond
              just using them with tab controls. You can create those wizard style
              dialogs using this technique (and no child forms needed).

              It also has one great benefit in that you can visually design
              your forms and see actually how they will look, since the designer
              supports layers too. Since the designer supports layers, you can
              build all sorts of complex dialogs (and tabs) and see exactly how
              they will look.

              This also decreases the number of forms your application requires.

              Layers are an extremely useful tool and a favorite among EZGUI users.

              Now if you really prefer embeded child forms (They are
              embeded on other forms), EZGUI provides a mechanism called
              Page Forms. EZGUI can also show a page form and hide all the others
              via a single command. So you have the best of both worlds. Use
              layers when they are better and use page forms when they are better.

              Chris Boss
              Computer Workshop
              Developer of "EZGUI"
              Chris Boss
              Computer Workshop
              Developer of "EZGUI"


              • #8
                (12) Code Readability / Maintainability / Reliability

                The EZGUI concept was designed with a simple precept:


                At first glance, one may wonder why doesn't EZGUI follow more
                the syntax of API coding ?

                Simply put, I don't like it!

                I am not a novice to API programming, since I have to be an advanced
                API programmer just to write EZGUI. Yet, it is my opinion as an
                experienced programmer that API coding is far more complex than
                it needs to be. There are hundreds, if not thousands, of structures
                and constants to be used. It is very easy to be overwhelmed with
                it all and even I find that whenever I have to write some API
                code, I have to go back a reread the API docs quite carefully first,
                not just simply as a quick reminder, but because I just can't remember
                all the complexities of an API call.

                BASIC has always been a language known for its ease of use and
                simplicity. Windows on the other hand is overly complex.

                One of the advantages of EZGUI is that the code (both that generated
                by the designer and even what you may write yourself) is much easier
                to read and understand (once you understand the basics of the EZGUI
                command set), than some other coding styles (ie. SDK).

                When writing very large applications code can run into the many thousands
                of lines. Once applications get very large, code readability is
                critical to code maintainability. All software will likely have
                bugs in it, but the easier it is to read ones code and examine it,
                the quicker one can find those bugs and make the software reliable.

                Often I see such things as speed, size of app., feature set, etc.
                touted about different software. How often though do you see
                people touting how reliable their software is, how stable, how dependable ?

                Software reliability is far more critical than anything else.

                Code readability contributes to software reliability!

                As I built the EZGUI command set (the engine), I often asked myself,
                what is the bare minimum that a programmer will want to configure
                with a given task ? If much of the task could be automated or at
                least simplified, I did it. Where common sense dictated that the
                programmer likely would want to have some control of how a task
                is handled, I tried to find the easiest way possible for the user
                to define the task, without making it needlessly complex.

                To make coding easier, I used simple property strings, rather than
                ORing constants together.

                Here is an example:

                To display the Font common dialog, the code would look like this:

                OK& = EZ_ChooseFont ( FormName$, MyColor&,  DProp$ )
                ' to retrieve the actual font
                ' use:
                ' EZ_GetSFont TFace$, PSize&, FProp$
                The last parameter DProp$ can use any of the following characters
                to define properties of the dialog via a simple string:

                C - Define Font Color also
                F - Fixed Pitch Fonts only
                S - Standard Size Fonts only (8 to 14 point)
                (otherwise point sizes can be 1 to 127)
                T - TrueType fonts only
                P - Fonts must be usable on a printer

                Parameters which use a simple property string, use single characters
                for each property and the character will be something easy to
                remember, such as the <U>first letter of a word</U>.

                Compare a simple property string like:




                EZGUI also automates a lot of things for you, like with the
                Font dialog it remembers the last font selected and initializes
                the dialog to that font the next time you display it.

                True, I personally had to make choices about what was important
                to allow the user to define and what to automate, but Beta testing
                often gave users a chance to offer feedback on things that needed
                more options, so the final outcome is a command set which offers
                a lot of user choices, with the minimal amount of coding possible.

                EZGUI allows faster coding (since it often requires less code to
                accomplish many things.

                For example here a Toolbar is defined using just one line of code:

                EZ_Toolbar %Form1_Toolbar1, "#LargeSTD",  "BBBB BBB|1785094{New|Open|Save|Close|Cut|Copy|Paste|}", "FORT24X24"
                The Designer makes it easy to generate this code, but still only
                one line of code is needed for the complete definition of a toolbar
                with 7 buttons (and text).

                It is this <U>compactness</U> in coding which makes EZGUI code
                much easier to read (and write).

                Once EZGUI users get use to the common syntax of EZGUI commands,
                they will find they can write code much faster, since they have
                write less code and it has a much simpler syntax than many API calls.

                Chris Boss
                Computer Workshop
                Developer of "EZGUI"

                [This message has been edited by Chris Boss (edited July 30, 2007).]
                Chris Boss
                Computer Workshop
                Developer of "EZGUI"


                • #9
                  (13) Engine Hooks

                  One question some have is:

                  What if I need to change how EZGUI handles specific events ?

                  I tried to add as many hooks into the core engine as possible,
                  to allow advanced API programmers to access some of the internal
                  engines in EZGUI.

                  The following commands are available:

                  EZ_HookMsgLoopProc - Create a Hook into internal Message Loop
                  EZ_HookDialogProc - Create a Hook into internal Window procedure (for all forms) to custom dialog procedure
                  EZ_HookDialogProcEx - "similiar to EZ_HookDialogProc"
                  EZ_HookComDialogProc - Create a Hook into Common Dialogs
                  EZ_HookCanvasPaint - Create a Hook into Canvas controls WM_PAINT routine
                  EZ_UseDialogProc - Create a unique Dialog Procedure Hook for one Form

                  I recognized that advanced programmers would like to be able to
                  modify how EZGUI works, so I added as many hooks into its internal
                  engine as is possible.

                  Chris Boss
                  Computer Workshop
                  Developer of "EZGUI"
                  Chris Boss
                  Computer Workshop
                  Developer of "EZGUI"


                  • #10
                    (14) High Level Functionality (less coding)

                    I have commented about the extensive command set in EZGUI before,
                    but one thing easily overlooked is the built in functionality
                    which often handles lots of small details for you so you can
                    concentrate on coding the important stuff.

                    One example is the Listbox control.

                    EZGUI's listbox control allows you to set a simple property (a
                    single property character - ^) to convert the listbox to a drag listbox.

                    To code this via the API requires more than simply sending a message
                    or setting a style.

                    It requires a number of steps:

                    (1) convert listbox to a drag listbox
                    (2) register a custom window message
                    (3) process the events for this custom window message
                    (4) during events call API's to display the drag icon

                    This is a bit oversimplified, but to accomplished this takes quite
                    a lot of lines of code (at least a 100 lines or more) and you have
                    to know all the API calls needed to accomplish it.

                    With EZGUI you simply select the drag property when creating the
                    control and EZGUI handles all of it for you. EZGUI even generates
                    its own %EZ_DragItem event for the control so you can control
                    which items can be dragged.

                    Another example is the Listview and Treeview controls.

                    EZGUI provides a command to allow you to generate a true drag icon
                    for an item. Items can be dragged within the control or even to other

                    The code for this is quite complex and I won't even waste time
                    trying to explain how this is done, but suffice it to say that
                    it is quite complex and requires a good knowledge of a number
                    of API calls.

                    The point is, that with just a few lines of code, EZGUI apps can
                    generate drag icons for these controls.

                    There are dozens of such built in high level features in EZGUI,
                    which would require some complex API code (and a lot of it) otherwise.

                    It is this high level functionality which makes EZGUI quite

                    This is one of the reasons why I chose a runtime (DLL) approach,
                    rather than generate 100% code. It allowed me to concentrate on
                    a number of high level features which would have been hard to do
                    otherwise. Also the EZGUI user can concentrate on tasks, rather
                    than lots of code.

                    I would venture to say, IMO, than no other coding method for PB
                    requires as little code as does EZGUI apps for many complex tasks.

                    When developing EZGUI I often asked myself the questions:

                    (1) What tasks would most programmers want to accomplish ?
                    (2) How much control would they want over that task ?
                    (3) How automated would they want the task to be ?

                    If a task would more likely be something a programmer would want
                    complete control over at every point, then I would write the
                    command set as low level.

                    If a task would more likely be something better suited to automation,
                    and little low level control was needed, then I would write the
                    command set as high level.

                    Always I tried to create a command set that would require as little
                    coding as possible.

                    Another aspect of the EZGUI command set was that the commands added
                    were not just a matter of finding as many API messages I
                    could wrap for a control. Many control messages are quite simple
                    and they could easily be wrapped with little effort.

                    I added commands based on need, not ease of coding the wrapper or
                    simply to bloat the command set.

                    The goal was to keep the runtimes as small as possible, so if I
                    added new commands simply to bloat the command set, the DLLs would
                    be huge.

                    I seriously considered, "what would most programmers need" when it
                    comes to features.

                    More often that one would think, the truly necessary features
                    often required a more high level approach. At times this meant
                    the feature required a combination of commands with associated

                    To be more simple, this means that to accomplish a task, required
                    calling some API's to start the task (or prepare a control for a task),
                    and then process a number of window messages (either to a controls
                    parent form or via subclassing the control) to handle the task in
                    motion (so to speak). This requires a more high level approach since
                    you have multiple things to do to fully accomplish a given task.

                    This is the reason that EZGUI is a GUI Engine. You can't just
                    encapsulate a number of API calls. There has to be a supporting engine
                    which handles the task in motion (ie. a drag icon).

                    EZGUI is task orientated in design.

                    This means for the programmer, you can concentrate on getting the
                    job done quickly, without having to concentrate on a lot of code.

                    The less code needed (by you the programmer) to accomplish a task
                    means savings in time and better code readability.

                    This is the hidden value in EZGUI.

                    Don't just look at price.

                    If using the API a given programming task would take a few hours
                    to write and EZGUI allows you to do it in minutes, what is that worth
                    to you ?

                    True, EZGUI has its own learning curve at first, but once one gets
                    up to speed with it, users often are amazed at what it can do and
                    how quickly.

                    Chris Boss
                    Computer Workshop
                    Developer of "EZGUI"

                    [This message has been edited by Chris Boss (edited August 10, 2007).]
                    Chris Boss
                    Computer Workshop
                    Developer of "EZGUI"


                    • #11
                      (15) Simpler syntax means less coding

                      The EZGUI command set decreases coding time by using a syntax
                      which is simpler and shorter. Also the simpler syntax
                      makes memorizing commands much easier.

                      While it is not possible to totally eliminate the use of constants
                      , EZGUI keeps the use of constants down to a absolute minimum.

                      One of the things I dislike about the Windows API is the dependency
                      upon so many constants. To make things worse, the constants often
                      have long names.


                      Compare this:

                      to this:

                      Note: EZGUI uses simple property strings for many commands and
                      the letters are usually the first letter of the property name.
                      In this case, E = Edit, M = MultiLine, S = Sunken Edge, T = Tabstop, V = Vertical Scrollbar

                      EZGUI only uses constants where absolutely necessary (for speed and
                      ease of understanding, like event constants or some drawing commands).

                      EZGUI also nearly eliminates the use of structures (TYPEs) for
                      command parameters (there are only a couple types even defined
                      in the include files).

                      Passing structure pointers via control messages is basically
                      eliminated, since all EZGUI control commands use simple
                      parameters, rather than pass structures.

                      The design of EZGUI commands was based on the simple premise of
                      "keep it simple". The simpler the command syntax, the easier it
                      is to code.

                      A couple examples are:

                      A new command to simplify defining popup menus allows you to define
                      the entire menu with one line of code.


                      EZ_DoPopupMenu "Form1", CVal&, 9000, "Item 1|Item 2|?,O|Item 4|Item 5|","C"
                      Generates this popup menu:

                      Item 1           (ID 9000)
                      Item 2           (ID 9001)
                      Ownerdraw item   (ID 9002)
                      Item 4           (ID 9003)
                      Item 5           (ID 9004)
                      Keyboard accelerators can easily be defined like this.


                      EZ_DefAccel "Form1","^F1,100|^F2,101|%F1,200|%F2,201|$PGUP,300|"
                      This defines keyboard accelerators for "Form1" which are:

                      CONTROL-F1   (ID 100)
                      CONTROL-F2   (ID 101)
                      ALT-F1       (ID 200)
                      ALT-F2       (ID 201)
                      SHIFT-PAGEUP (ID 300)
                      This is just a few examples, but is demonstrates how the entire
                      command set was designed. Commands need to be readable and short.

                      This speeds up your coding significantly.

                      One of the reasons I named the product EZGUI (EZ short for Easy)
                      is not because it was a beginners tool, but because it makes
                      coding much easier, while still being a professional (high end) tool.

                      If commands are easier to remember (less time wasted reading API docs
                      for reference), shorter in length (quicker to type) and simpler in
                      syntax (less extra code to write, like using structures) then one
                      should be able to write much more working code in much less time.

                      If one can write a section of code in a few minutes, instead of an
                      hour, isn't this worth something to the programmer ?

                      Add to this an extensive and easy to navigate Help file (HTML Help)
                      coding just gets easier than ever.

                      Chris Boss
                      Computer Workshop
                      Developer of "EZGUI"
                      Chris Boss
                      Computer Workshop
                      Developer of "EZGUI"


                      • #12
                        (16) Controls, Controls, Controls (plus lots of custom controls)

                        EZGUI 4.0 Pro has a unique set of custom controls that come with it.

                        The goal of the custom controls is to give you as much variety as
                        possible, so you can build complex GUI's. I added the custom controls
                        to solve problems (or to fill a need). They are more than simply eye
                        candy. They serve very important needs.

                        Let's take a quick look at the custom controls included:

                        (1) Canvas control

                        I have already mentioned a lot about this control. Mainly the purpose
                        is to give you an advanced Canvas to draw on. There isn't much that
                        can't be done with the Canvas control. What Visual Design tools
                        provide such an advanced drawing tool as does EZGUI ? The sprite engine
                        alone is an amazing tool.

                        (2) Turtle Graphic control

                        Why Turtle Graphics ?

                        It is a vector based graphic engine. Vector images have advantages
                        in that they can be scaled and the image itself takes little disk
                        space. The Turtle control can even be used to draw on other controls
                        , such as the Canvas. EZGUI gives you access to its drawing engine
                        outside of the control itself.

                        (3) 3D/2D color Buttons

                        EZGUI uses the ownerdraw feature of the button control and combines it
                        with its graphic engine (simplified ownerdraw command set) to give
                        you real 3D/2D colored buttons. Colored buttons are very useful
                        for GUI's that need a way to distinquish between buttons in a
                        very visible way (aka. color). While not a true window class of its own,
                        you do get a new control type without a lot of effort.

                        (4) Drag Handle control.

                        As discussed above, when implimenting a WYSIWYG style application,
                        one of the hardest things to do is add drag handles to controls.
                        EZGUI makes it amazingly simple and even has a drag and drop engine
                        to support the control.

                        (5) Files Listbox control.

                        The control is quite simple in nature, but offers you the ability
                        to display lists of files/folders/drives with icons (even the system
                        icons). It is a very useful control to have.

                        (6) MCI control.

                        How often have you wanted to add multimedia to your application ?
                        Nothing fancy, but you just wanted to add audio, CD audio, video
                        or MIDI. The MCI control not only gives you easy access to the
                        MCI engine in Windows, but it provides its own simplified command
                        set to make working with multimedia even easier. You might say,
                        it is multimedia the easy way. The control also provides the necessary
                        window for displaying video. It couldn't be easier.

                        (7) custom MDI Client class.

                        EZGUI provides its own MDI client control. It is actually a superclass
                        of the MDI client control in Windows. By superclassing the control,
                        it allows EZGUI to do things beyond the normal MDI client control.
                        One example is customizing the background of the control. EZGUI provides
                        easy access to the controls background paint routine and even provides
                        easy to use drawing commands, so you can customize the look of
                        the MDI client control.

                        (8) Properties Listbox control.

                        A properties listbox control is a complex and very advanced control.
                        How often did you wish you could add a properties listbox to your
                        applications ?

                        (9) Masked Edit control.

                        A masked edit control is an often desired control to have. It
                        gives you more control over editing text. It even has a calculator
                        mode, when a text field is totally numeric. The text is input
                        similiar to how it appears in a calculator (from right to left and shifted).

                        (10) Shape Hot Spot control.

                        This may seem like a very simple control, but it far more useful
                        than may think. Not only can the control display a true shape
                        (ellipse, rectangle, rounded rectangle (filled or hollow) and line),
                        but it can also act as a hot spot control. This means that it is
                        totally invisible and allows other controls to show through it,
                        but it responds to mouse clicks. You can put a number of hot
                        spot controls over key locations of a picture (bitmap) control,
                        and they can respond to mouse clicks.

                        Notice the variety of controls!

                        EZGUI gives you something for most situations.

                        Add to this, EZGUI's ability to customize other controls via ownerdraw
                        and custom draw, you have many, many options available for
                        developing any kind of GUI you can imagine.

                        It well supports each control it has. Controls like the
                        animation control, datetime, calendar, listview, treeview,
                        trackbar, statusbar, updown, toolbar, progressbar, tab control,
                        drag listbox, pager, rebar, tooltip and richedit control have a
                        good command set for each which allows you to access the most
                        commonly used (and needed) features.

                        How many Design tools make working with the pager or rebar control
                        easy ?

                        How about working with the RichEdit control ?
                        EZGUI provides an extensive command set for working with this
                        control and you can even do hyperlinking with it. EZGUI can load large
                        RTF files into the richedit control.

                        How about implimenting drag and drop icons in the listview or treeview
                        control ? EZGUI makes is amazingly easy.

                        Chris Boss
                        Computer Workshop
                        Developer of "EZGUI"

                        [This message has been edited by Chris Boss (edited August 17, 2007).]
                        Chris Boss
                        Computer Workshop
                        Developer of "EZGUI"


                        • #13
                          (17) Variety of features in Command set

                          In building applications programmers often need a variety of
                          features in the command set. A tool may offer good support in
                          one area, but be lax (or totally missing) in another.

                          While it is not possible to build a tool that has everything,
                          the goal with EZGUI is to fill the most common needs of
                          programmers in a large variety of areas.

                          Let's look at three aspects of EZGUI and its variety.

                          (1) Variety of Forms/Controls and good support for each.

                          EZGUI supports every control it has with a good command set to
                          allow the user to work with the control to get the most out of it.

                          EZGUI supports all of the following forms/controls:

                          - MDI Child forms
                          - MDI parent form
                          - page forms (embeded forms)
                          - owned forms (a form of embeded forms with caption bars)
                          - shaped forms (non-rectangular using regions based on a bitmap image)
                          - standard forms (aka. dialogs)
                          - modal forms (with access to modal message loop)
                          - Rebar Forms (form embeded in Rebar control)
                          - Pager Forms (form embeded in pager control)

                          - Animation control
                          - Button control (also 3D/2D colored buttons and ownerdraw)
                          - Calendar control
                          - Canvas control (custom)
                          - CheckBox control
                          - ComboBox control (also ownerdraw)
                          - DateTime control
                          - Drag Handle control (custom)
                          - Files Listbox control (custom)
                          - Frame control
                          - Icon control
                          - Icon Button control
                          - Label control (also ownerdraw)
                          - Listbox control (also ownerdraw and drag listbox)
                          - Listview control
                          - MCI control (custom)
                          - MDI Client control
                          - Pager control
                          - Picture control
                          - Picture Button control
                          - Progressbar control
                          - Properties Listbox control (custom)
                          - Radio control (also known as option button)
                          - Rebar control
                          - RichEdit control (1.0 and 2.0)
                          - ScrollBar control
                          - Shape/Hot Spot control (custom)
                          - StatusBar control
                          - Tab control (also ownerdraw)
                          - Text control (also Masked Edit custom control)
                          - ToolBar control
                          - ToolTip control
                          - TrackBar control
                          - Treeview control
                          - Turtle Graphic control (custom)
                          - UpDown control

                          Each control above is well supported by a full command set so you
                          can do the most common tasks with them.

                          (2) Extensive and varied command set.

                          Notice the variety of areas the command set handles:

                          - Clipboard
                          - Colors
                          - Common Dialogs (open/save, colors, fonts,print, page setup, find/replace)
                          - Control Search Functions
                          - Debug
                          - Enumeration of controls on forms
                          - Event options
                          - Files and Paths
                          - Focus and ZOrder
                          - Fonts
                          - Game Loops
                          - Graphics (icons, bitmaps, imagelists, DIB's)
                          - Help files (hlp and html)
                          - Keyboard
                          - Layers
                          - Menus
                          - Message Boxes
                          - Operating System Info
                          - Printing
                          - Redraw controls/forms
                          - Regions
                          - Registry
                          - Resources
                          - Size and Position of Forms/Controls
                          - Sound (system beep)
                          - Sprites
                          - Time and Timers
                          - Threads Simplified commands
                          - Tray Icons

                          Advanced command set (also for integrating API code too):

                          - Control Messages
                          - Custom Draw
                          - Drag and Drop
                          - DC Drawing
                          - Drawing control background
                          - External Libraries
                          - Hook Procedures
                          - Notification Events
                          - Ownerdraw Advanced command set
                          - subclassing controls
                          - Threads (advanced)
                          - Visual Designer Engine

                          (3) Extensive Event set.

                          EZGUI doesn't simply pass through common event messages (ie. WM_COMMAND,
                          WM_NOTIFY) to your application. It actually preprocesses most events and
                          converts them into a simpler EZGUI event syntax. It does a great
                          deal of background event handling for you, so you need only do as
                          little processing of the event as is possible. A simple example, is
                          EZGUI will pass values for the event, such as when a user clicks
                          a listview or listbox item, the index of the item is also passed in
                          the event.

                          Here is the complete list of EZGUI events currently supported:
                          (to save space I have removed the EZ_ prefix to all of the event names)

                          More often used events:

                          - Click
                          - Change
                          - DClick
                          - Loaded
                          - Loading
                          - Started
                          - Focus
                          - NoFocus
                          - Selected
                          - UnSelected
                          - ToolTip
                          - Close
                          - Ownerdraw
                          - OwnerSize
                          - LVClickInfo
                          - LVDClickInfo
                          - InitPropDlg
                          - SelectCursor
                          - Timer
                          - Maximize
                          - Restore
                          - Post
                          - Notify
                          - Freenow

                          Less often used events:

                          - AllowEdit
                          - CaptureOfff
                          - ChangePos
                          - ChangeSize
                          - ChangeZOrder
                          - Collapse
                          - Command
                          - Compare
                          - ConvBtnPos
                          - CtrlError
                          - CustomDraw
                          - DClickCap
                          - Disable
                          - DoMDIMsg
                          - Drag
                          - DragForm
                          - DragItem
                          - DragItemDraw
                          - DragItemDrop
                          - Drop
                          - DropFiles
                          - Dropping
                          - EditSetSel
                          - EraseBG
                          - Expand
                          - FindDlgFindNext
                          - FindDlgReplace
                          - FindDlgReplaceAll
                          - FindDlgTerminate
                          - FinishMCI
                          - FlagMCI
                          - GameLoop
                          - KeyDown
                          - KeyPress
                          - KeyUp
                          - LButtonDC
                          - LButtonDown
                          - LButtonUp
                          - MButtonUp
                          - MenuClose
                          - MenuShow
                          - MinMax
                          - Minimize
                          - MouseEnter
                          - MouseLeave
                          - MouseMove
                          - Move
                          - NextCtrl
                          - NoBottomSize
                          - NoCustomDraw
                          - NoDClick
                          - NoDrag
                          - NoLeftSize
                          - NoRightSize
                          - NoTopSize
                          - PollCtrl
                          - PrintError
                          - RButtonUp
                          - Redraw
                          - RTFLink
                          - SaveSetSel
                          - ScrollBG
                          - ScrollBGKey
                          - SetODChildID
                          - ShowCommonDlg
                          - Size
                          - Sizing
                          - SMSelected
                          - SubClass
                          - SysKeyDown
                          - SysKeyPress
                          - SysKeyUp
                          - Sysmenu
                          - Terminate
                          - Thread
                          - ThreadCode
                          - ThreadP
                          - TrayDClick
                          - TrayLButtonDown
                          - TrayLButtonUp
                          - TrayRButtonDown
                          - TrayRButtonUp
                          - Updated

                          As you can see, the Event list is very extensive and I doubt any
                          other RAD environment provides such an extensive event engine.

                          Remember that events are not just simply passing through API messages.
                          They have been preprocessed by EZGUI, so you don't have to do
                          much to process them. EZGUI does all the hard stuff for you.
                          You simply get meaningful events so you can add your own code
                          to these events so it executes at the right time.

                          Chris Boss
                          Computer Workshop
                          Developer of "EZGUI"
                          Chris Boss
                          Computer Workshop
                          Developer of "EZGUI"


                          • #14
                            (18) Price!

                            OK, at first glance this does not sound like a benefit.

                            It definitely is a difference between EZGUI and other products,
                            since EZGUI is probably one of the higher priced addons for PB.

                            Let's discuss why.

                            The obvious answer is that for an addon developer to stay in
                            business for the long run, they have to charge a price that
                            accurately reflects the time and effort that goes into the

                            The real question for customers though is, is the product
                            worth the price to you. Do you get real value for what you pay ?

                            The two aspects I will discuss here as far as value are,
                            (1) product features and their value and (2) Tech support and its value.

                            Let's start with Tech Support.

                            Yes, I provide an online forum for tech support, but so do a
                            a lot of others. What makes EZGUI tech support different ?

                            Simply put, it is the amount of time and effort that I personally
                            plan on providing my customers. Why do I say plan ?

                            You see, time costs money, as they say and I decided awhile back
                            that I didn't want my customers to feel short-changed because I
                            didn't spend enough time and effort in answering their questions.
                            By adding a sufficient amount to the initial price of the product,
                            I could guarantee that I could spend plenty of time with customers
                            to help them solve problems and yet not be hurting the bottom line
                            necessary to stay in business.

                            So how far does the tech support go ? What are you getting for
                            your money ?

                            Not only do I visit my forums multiple times a day, so the time
                            difference between when you ask a question and when I post an
                            answer is short, but the amount of time I spend in finding the
                            answers to questions is also quite extensive. While some questions
                            are simply about how to use the product and they are easy to
                            answer, many questions are beyond the basic use of the product.
                            Often questions are about finding solutions to specific tasks.
                            It isn't a matter of pointing the user to a simple command or
                            API. Often it is a matter of going beyond the basics to find
                            a way to impliment some specific task with the tools available.

                            With a lot of tech support, if the answer is not obviously apparent
                            (to the tech support person) and if it is beyond the scope of the
                            basic documentation, tech support may simply tell you that you
                            are "on your own" on this one.

                            No so with EZGUI!

                            Ask my customers about the support that I offer.

                            I have planned to spend a significant amount of time in
                            doing tech support for customers, which means that I will at times
                            spend even a few hours researching the answers to a question.
                            Not only are a number of my posts on my forum quite long and
                            detailed, but I have been known to spend hours writing test code
                            to find a workable solution to a problem or task and I have spent
                            a good amount of time researching the API docs on MSDN (the latest)
                            to find the whys and wherefores of how to make Windows do certain

                            One customer literally sent me 70 or more emails with questions
                            and I answered them all.

                            I have encouraged customers to telephone me (they pay for the call
                            of course) if they need more personal help. At times you just need
                            a real person to talk to. If I spend and hour or two on the phone
                            with a customer, that if fine with me. Even potential customers
                            should feel free to telephone me to ask questions, before they
                            spend their hard earned money on the software.

                            The point is, tech support is very personal and very extensive.
                            If you purchase EZGUI you will not be left to yourself without
                            help. I planned it that way!

                            Next, lets discuss features and their value.

                            EZGUI is more than just a Visual Designer.

                            It is a complete product.

                            I will be the first to say, that other PB addon vendors offer
                            very high quality products, even with features that I wish I
                            had in mine. I won't knock them.

                            No one single product can have everything, which is why the feature
                            set of each product is quite different and the end user must
                            determine which one fills their needs.

                            Yet, when it comes to EZGUI, one goal I had in development,
                            was to offer the user as complete a product as I possible could.

                            Aside from the PB compiler, the goal was to give the user everything
                            they needed in EZGUI so that they wouldn't have to seek other tools
                            to fill in voids.

                            Sure, one could buy multiple products, each one for a specific task,
                            but imagine getting a product that had nearly everything you would
                            need to build your Windows applications.

                            So, what does EZGUI have ?

                            - Visual Designer and Code Generator (using smart parser technology)
                            - basic GUI engine (forms and controls)

                            but is has so much more ...

                            I added custom controls to fill in voids in what Windows offers.

                            Rather than add a lot of custom controls to simply emulate
                            Microsoft apps, I chose to add controls which were very
                            task specific.

                            Customers would need some basic multimedia features -
                            So I added the MCI control.

                            Customers would need graphic features -
                            So I added the Canvas control and Turtle Graphics control.

                            Customers would want to do basic animation (moving graphics) -
                            So I added the Sprite engine to the Canvas control.

                            Customers would want more user input features in their GUIs -
                            So I added the masked edit control, files listbox control and
                            property listbox control.

                            Customers would want to build their own controls or customize -
                            So I added ownerdraw and customdraw support and a subclassing engine.

                            Customers would want to build WYSIWYG style apps (drag and drop) -
                            So I added a drag and drop (visual design) engine including a drag handle control.

                            Customers would want to add a little "eye candy" to their apps to make them different -
                            So I added easy to use 2D/3D colored button controls and Form regions
                            (non-rectangular forms based on Bitmap background).

                            Beyond the GUI itself, users would need tools to do complex tasks.

                            Customers would want to print things -
                            So I added a complete print engine.

                            Customers would want to build multi-threaded apps -
                            So I added a Thread Engine.

                            Customers would want to build games -
                            So I added a Game Loop engine and advanced Timing.

                            Customers would want to build Tray Icon apps -
                            So I added easy to use Tray Icon support.

                            The list of features are too extensive to do it justice here,
                            but the point is that I have attempted to make EZGUI as complete
                            as possible. I tried to analyze the most common needs programmers
                            would have for building Windows applications and then to put the
                            necessary tools into EZGUI.

                            Remember, that EZGUI is in its fourth generation now. I have had
                            plenty of time to find all the areas which were missing. While
                            in EZGUI 1.0 and 2.0 customers still had extensive wish lists,
                            with EZGUI 4.0 the wish lists are disappearing. The command set
                            is becoming so extensive, there is more often than not, an EZGUI
                            solution to most any given task.

                            When you purchase EZGUI, you are getting more than just a simple
                            tool. You are getting a complete solution. Sure, EZGUI can't do
                            everything imaginable (nothing can), but it can do far more than
                            most people realize. Currently I would estimate that most users
                            don't use more than 5% of the EZGUI feature set. The thing is, that
                            they don't all use the same 5% of features. It is the completeness
                            of the feature set which allows so many varied users to be able
                            to get what they need from it.

                            To appreciate the true value of the product, don't just consider it
                            a Visual Designer. Consider how much you would pay for many of
                            the indivisual components separately. Then the value becomes

                            EZGUI is a Bundle !

                            It is many tools bundled together.

                            Chris Boss
                            Computer Workshop
                            Developer of "EZGUI"
                            Chris Boss
                            Computer Workshop
                            Developer of "EZGUI"


                            • #15
                              To make things a little easier for those researching EZGUI
                              here are some quick links:

                              Details about EZGUI :

                              Some Designer Screenshots:

                              Screenshots of some apps built using EZGUI:

                              Walk-Throughs of using Designer:

                              Using Designer:
                              ToolBar example:
                              MDI example:
                              Non-Rect. Forms:
                              Tab Control:
                              Rebar example:
                              EGrid example:

                              Chris Boss
                              Computer Workshop
                              Developer of "EZGUI"
                              Chris Boss
                              Computer Workshop
                              Developer of "EZGUI"


                              • #16
                                (19) Legacy Operating System support

                                Some may scoff at this, but for others it is critical.

                                A lot of software today is designed for the bleeding edge technology and the latest operating system.

                                Personally, I feel it is important that developers be able to design software that will run well on even legacy hardware. Companies often spend a lot of money on computer hardware and it is a waste of valuable resources to simply keep throwing away older hardware, simply because newly purchased software won't run on it. Now of course some software, I can see the need for the latest and fastest hardware (games, graphics, etc.), but often common business oriented software doesn't really benefit all that much from leading edge hardware (and OS). To have users be forced to upgrade (or buy a new PC), simply because ones development tools need bigger and better PC,s is a waste.

                                EZGUI was designed so it will run well on even legacy systems. It has a few features that require later OS like XP,2000, but most features will run even on a Windows 95/98 PC (with IE 5.0). EZGUI dynamically loads the features requiring XP, so the runtimes are not dependent upon XP.

                                This means you can safely develop apps for legacy and new OS.

                                This can be very useful for developers who write inhouse software which needs to be used on legacy systems. Companies can save thousands of dollars by using existing legacy systems with software developed using EZGUI.

                                What is really amazing is that the majority of EZGUI's command set works even with legacy OS's. Even its graphic engine and sprite engine work with Windows 95/98, including Alphablending.

                                If you are looking for a way of developing powerful Windows applications, that will even run on legacy systems, consider EZGUI 4.0 Pro.

                                Build applications that look like they were designed for XP/2000, but can run on 95/98.
                                Chris Boss
                                Computer Workshop
                                Developer of "EZGUI"


                                • #17
                                  (20) Control support - Listview

                                  EZGUI has complete support for the Listview control.

                                  The command set available for use with the listview control is:

                                  EZ_Listview (create control)
                                  EZ_DrawListview (simplified ownerdraw)

                                  EZ_SetAttr (sets an attribute)
                                  EZ_GetAttr (gets an attribute)
                                  attributes available are:
                                  - BColor (background color)
                                  - TColor (text color)
                                  - ToolTip (tooltip handle)
                                  - Edit (edit handle)
                                  - TBColor (text back color)
                                  - PCount (page count)
                                  - Header (header handle)
                                  - ICount (item count)
                                  - SCount (selected count)
                                  - SMark (selection mark)
                                  - TIndex (Top Index)

                                  Search functions:


                                  Commands which work with multiple control types, as well as lisview:


                                  Universal commands:


                                  Listview Events:


                                  There are other commands that can be used with the listview control (such as sizing the control, etc.), but this should suffice.

                                  The Listview has a lot of high level support in EZGUI.

                                  EZGUI can not only sort the control (by column), but can also search and sort the control by combining multiple columns.

                                  EZGUI has its own drag and drop engine which makes it is easy to impliment draggable items in a listview. Items can be dragged within the listview, dragged to other controls or can be dragged to other forms.

                                  The drag/drop engine also impliment autoscrolling when dragging.

                                  EZGUI supports both custom draw (change fonts or colors) and ownerdraw with the listview. EZGUI has a high level and low level graphics engine for drawing during ownerdraw. You can even ownerdraw the listview controls header control.

                                  EZGUI has a complete imagelist engine which makes it easy to use imagelists.

                                  EZGUI's subclassing engine makes it simpler to impliment other unique features.

                                  EZGUI's support for controls, such as the listview is not just a set of API wrappers, but there are many high level features.

                                  The code alone in EZGUI which impliments drag and drop items (in listview and treeview) is very complex. It even allows you to customdraw the drag item cursor as item moves.

                                  Very few tools give you so much control over the listview control!
                                  Last edited by Chris Boss; 19 Oct 2007, 05:19 PM.
                                  Chris Boss
                                  Computer Workshop
                                  Developer of "EZGUI"


                                  • #18
                                    (21) Modular Design produces smaller apps

                                    If you have been following the discussion in the PB cafe forum about the Asus eee PC, you may find this very interesting.


                                    EZGUI has an advantage, when it comes to building very large applications.

                                    Of course any app built using PowerBasic will be small, but when you start building very large applications with hundreds of forms with lots of complexity, the size of an application can still grow quicker than you may think.

                                    To keep apps smaller, modular design is very important.

                                    To appreciate this, look at Visual Basic apps. Once the runtime is installed, the EXE's for apps were often quite small, since most of the apps code was executed in the runtimes and not the exes.

                                    EZGUI apps are similiar.

                                    Once the main runtime is installed (about 515 KB in size), the actual EXEs for apps are very small.

                                    Why ?

                                    Because of modular design!

                                    Because so much of the code in EZGUI is reusable, your apps need to do very little, so the resulting EXE's are quite small.

                                    Also remember that EZGUI's runtime contains some very high level and advanced code in it. It can dynamically generate regions for a Bitmap for non-rectangular forms, it has a sprite engine which can do alphablending, has a complete graphics engine, an ownerdraw graphics engine, a drag and drop engine (build your own visual designer), high level support for common controls and rich edit control and much more.

                                    Modular design benefits small application design in the long run and EZGUI being a true GUI engine is as modular as it gets. I tried to keep redundancy down to a minimum in EZGUI.

                                    This modularity won't be appreciated in smaller applications, but if you want to create the next "Office" software or any other very large application, then EZGUI's modularity will really make a difference.

                                    You will also find it interesting that the ezgui runtime DLL compresses well (if that is what you want to do). UPX compresses the main runtime DLL down to just 158 KB (EZGUI runtimes do not come compressed).
                                    Chris Boss
                                    Computer Workshop
                                    Developer of "EZGUI"


                                    • #19
                                      (22) Reliability !

                                      No software is perfect and preventing bugs is a challenge.

                                      Take time to browse the EZGUI forums to see the questions posted by users. One thing you will notice is that rarely are bugs discussed.
                                      Also rarely are users experiencing GPF's or crashes of their apps.

                                      Why ?

                                      It isn't enough to simply know how to call specific API's.

                                      One must understand how Windows does things (when and how).
                                      Windows itself even has its own share of bugs.

                                      This is one reason I prefer the runtime engine over 100% source code.
                                      Not that pure source code can not be reliable, but an engine often handles much more than pure source code library code does and it can take into consideration all sorts of problems that may arise better than pure source code libraries. This observation is not a comparison between EZGUI and other Designers! It is an observation made from my own experience in working on my own 100% source code Designer, compared to EZGUI's runtime code.

                                      When writing source code libraries there is a tendency to try to keep routines short and not overly complex, so they tend to be more low level.
                                      Generated code is even more difficult, since some code may be generated multiple times in an application (ie. WM_NOTIFY code), so if it is too complex, it will bloat an app and be hard for the user to edit.

                                      In working on my latest 100% source designer, I keep coming across this problem, where I have to weigh the value of generating code on the fly for stuff or add more library code (so generated code is smaller).

                                      With a runtime library, things are more consolidated, more organized.
                                      I find that I reuse a lot of code (modularity), so I can save a lot in internal routines. Also I am not concerned about readability of runtime code. It is more important that it works well, not whether it can be read, since users never read runtime code. They only need generated code to be readable, not runtime code.

                                      I have found that in a runtime engine I can take into consideration a lot of small things, easily overlooked, that will make an application more stable, more reliable.

                                      One example is, error checking code.

                                      I really could make the EZGUI runtime even smaller if I wanted to, but it has quite a lot of error checking code.

                                      Why ?

                                      Because Windows is not so fond of errors when passing parameters to its APIs. It doesn't take too much to bring Windows to "its knees", by handling an API function incorrectly.

                                      EZGUI actually shields the programmer from the worse of such problems. True, you can still have bugs in your apps code, but EZGUI makes it easier to find such bugs and it prevents a lot of them from crashing Windows. EZGUI compensates by preventing a lot of errors (even if you pass bad parameters).

                                      One user, who was an experienced API programer himself, actually tested EZGUI out to see how stable it was and how it handled errors. He purposely passed bad parameters to a number of EZGUI commands to test to see how they handled them. He told me he couldn't crash EZGUI (at least with what he tested anyway). EZGUI simply did the right thing, by ignoring bad parameters or compensating somehow.

                                      With EZGUI it is easier, IMO, to find the causes of problems in code, since it is easier to track problems down. EZGUI even has its own debug window designed to help finding hard to track problems related to Events.

                                      Windows is a very complex environment and to build applications that are very stable and reliable is a challenge. While no development tool is perfect (not even EZGUI), EZGUI is an extremely reliable development tool that allows one to build quality applications quickly and easily.

                                      The use of a runtime engine is one of the reasons it is so reliable!
                                      Last edited by Chris Boss; 20 Nov 2007, 11:22 AM.
                                      Chris Boss
                                      Computer Workshop
                                      Developer of "EZGUI"


                                      • #20
                                        Hi Chris,

                                        It seems anytime I visit the 3rd Party section on this forum, you have a features and benefits thread going. All the other GUI designer vendors respect that this IS the PowerBASIC forum and just post 'press releases'. Couldn't you have made one post of this and pointed to your own forum which I'm sure you have this posted already? I'm not trying to be 'sour grapes' here but months and months of the same EZGUI threads pushing your product is a bit much.

                                        Bob was nice enough to create a section on HIS forum for the PowerBASIC 3rd party people to make announcements. Don't you think your taking advantage of that good will?