posted 12-01-2006 12:44 AM         

Part 1:

The decision to purchase a tool like EZGUI requires some real thought into the benefits it offers. The price ($249) may turn some off at first, but as many of my customers have told me, it is worth it.

EZGUI is not for everyone and there are of course different programming styles. Some prefer 100% source code. Other prefer to stay close to the Windows API. But for some, EZGUI offers many benefits worth considering and I would like to discuss them here.

If you are perfectly satisfied with the methods you currently use in developing Windows applications using the PB compiler, don't read on. But if you are looking for a better development environment, more features , better quality and faster development speed, then please seriously examine the following:

(1) Reliability

One of the key goals in the development of EZGUI has been the need for reliability. Especially if you are developing commercial applications, you can't afford to have your software suffer because of poor code.

This is one of the reasons, I chose to use a runtime (DLL), instead of generating 100% code. I didn't want anything to break, when programmers used EZGUI. They would depend upon it and could ill afford to have their applications break, because something was wrong with EZGUI or code generation.

EZGUI is now in its 4th generation and the core runtime routines are tried and true. My customers depend upon them. Now of course no one can say their software is 100% bug free. I would never say that. But I feel (and I think my customers would agree) that EZGUI 4.0 is as good as it gets as far as reliability.

Why ?

There are a number of reasons, but I will mention a few here.

First, is my view of debugging software. Debugging is an art form, IMO. It is easy to lack patience when debugging software and to not put enough time into it. If you ask my customers (when bugs have been reported), I at times may spend days trying to figure out what is wrong and to find a solution. No matter how long it takes, I try to do it, so I can make sure my customers have confidence in EZGUI.

Another aspect of debugging something as complex as EZGUI is the need to research the Windows API thoroughly. I have found it critical, that I fully understand the proper way to use the API. Again this takes time and patience. I never use an API call, unless I fully understand how it works first. I never just copy others code from what is available on the Internet. I want to understand how it works and why. I want to understand the underlying API's involved.

There have been times, my customers have requested a feature and I simply reply that I can't add it yet, since I do not fully understand or grasp the concepts or API's involved enough to add it. Nothing goes into EZGUI, before I grasp the concept and methods involved to a reasonable degree.

I don't expect potential customers to take my word for it. I prefer to let my customers speak. If you have any interest in EZGUI feel free to post your questions on this forum and let my customers give you honest feedback.

Another aspect of reliability, has to do with the problems associated with multiplatform development. EZGUI was designed for developing applications that will run on OS's from Win95 to XP. One of the problems with some development tools today (and this includes many non-PB programming languages/tools) is that they are written for the "bleeding edge" of operating systems. Just take a look at software tools you purchase (or even end user software) at the "requirements" needed to run the software. Not only do you often see only later OS's being supported, but at times you will see references to "service pack versions". This dependence upon only the latest OS or service pack, makes it very uncertain whether you can develop applications for a variety of platforms.

EZGUI was designed so it can run on as old a platform as possible and yet still take advantage of later OS features.

For example, EZGUI's graphic engine, including the new Sprite engine, should work even on Windows 95 without any special OS runtimes, like DirectX or GDI+. EZGUI actually pushes the limits of features in Windows that have been around since Windows 95, but are not often used. One example is OwnerDraw. You can customize the look and feel of controls far beyond the basics supported by the OS. EZGUI 4.0 comes with full support, even in its Designer for 3D colored buttons in 4 different styles (using the new plugins feature). EZGUI 4.0 supports things like non-rectangular Forms using bitmap images and regions. There are many advanced features, which still only requires a minimum of Windows 95.

Now for those features which do require later versions of Windows, EZGUI takes a safe route. Instead of making the runtimes dependent upon later OS API's, EZGUI instead will poll the OS to see if the features are available and then will dynamically load any needed API calls. What this means is that your applications won't be limited to later versions of Windows. You can still run them on earliers versions, but a few features simply may not be available (the few features in this catagory often are more eye candy than anything else and may not be critical to the apps functionality).

The point is that EZGUI goes to great lengths to give you as advanced features as possible, while still only requiring as minimal as possible the requirements of the OS.

A good example is EZGUI's sprite engine. Just imagine being able to have sprites which can be alphablended and anti-aliased on as old an OS as Win95. Now of course the speed of a CPU may limit how much can be done when working with heavy graphics.

One may ask, why support older OS's ?

While it is true that many people have either Windows 2000 or XP, there are also many computers still used today that run older OS's. In business these older computers are often relegated to lesser tasks, but they many times are still used. Imagine the potential for your software if it can run a even older computers, while still offering advanced features and a small footprint.

Even if you aren't concerned about older OS's, you still may be concerned about all the changes between service packs on current OS's and whether it will break your software. Since EZGUI attempts to use only API's which have changed little from Windows 95 to XP, it is less likely to be effected by service pack changes.

The goal as been, "aim for as a consistant as possible reliability on as many Windows platforms as is possible" (32 bit). There aren't many programming tools today that aim for that. I recently downloaded a free express version of a MS product, only to find that it would not run on my PC, since it was only service pack 1 (XP Home). Another well known compiler maker, also had free versions of some of its compilers and they to would not run on my system. I have a 2.5 ghz PC, 256 meg ram, 128 meg video card, with XP Home and yet I can't run a variety of programming software. While not the bleeding edge, it surely is not old or obsolete.

EZGUI offers developers the ability to build powerful, feature rich software, which will run on as many systems as possible.

To be continued ...

[This message has been edited by Chris Boss (edited 12-01-2006).]

posted 12-01-2006 02:41 PM         

EZGUI was designed to make programming complex Windows applications as easy as is possible. This does not mean that it lacks power and is only for beginners.

Everyone is familiar with the old saying "why reinvent the wheel".

You might say that EZGUI is similiar. EZGUI provides a rich command set (over 600 commands/functions in runtime) which allows you to concentrate on the task at hand, rather than wasting time on the complexities of the Windows API.

For example, the command:

EZ_Clear

clears the data or items from the Listbox , ComboBox , Listview , Treeview, Tab control , Turtle Graphic control and the Canvas control.

One command which handles a common yet simple task, clears the data from the control. Yet each control type has its own unique way of doing this via the API. EZGUI goes farther, by giving you one command for all of the above controls. The command tests the control to see what type (class) it is and then uses the appropriate API to clear the control of its data or image.

This one command is like 7 commands in one!
Yet the purpose for it is simple and its implimentation is also simple.

This demonstrates the basic concept of the EZGUI engine. Why bog the programmer down with all the dirty details, when he simply wants to do a given task ?

This means the EZGUI command set is not only simple to use, but at times it actually handles multiple control types per each command, so the command set is actually larger than you would think. It would probably take a similiar tools library of wrapper functions a 1000 or more functions to do what EZGUI does.

For example, EZGUI 4.0 introduces two new commands, EZ_SetAttr and EZ_GetAttr (which sets/gets attributes of controls) which alone encapsulates over 150 API messages and handles many different controls.

The command set alone gives programmers the necessary tools to build very complex applications in as short of time possible.

EZGUI is also very high level, when it needs to be. At first glance one may have the impression that EZGUI's runtime is simply a large number of simple wrappers over relatively simple API calls. This is not the case. There is a significant number of very high level commands or engines in EZGUI.

For example, the EZ_ToolBar command which creates and populates a complete toolbar control (defines bitmap, buttons, properties for buttons, etc.) uses nearly 400 lines of code in it. Yet this one high level command only requires one line of code in your applications. Imagine if your application has dozens of toolbars in it, the savings in coding.

EZGUI also contains a number of very high level engines. The Visual Designer Drag and Drop engine alone contains many hundreds of lines of code. This engine impliments drag and drop features which would be very difficult to do using the API directly. EZGUI has a number of engines built in, such as a subclass engine (makes subclassing easy and safe), drag/drop designer engine, event engine (ie. EZGUI's WM_NOTIFY processing code is over 600 lines of code and handles the most common WM_NOTIFY notification messages and converts them to easy to handle events, including customdraw).

EZGUI 4.0 has a ownerdraw engine which makes customizing controls very easy to do. This makes it easy for EZGUI to impliment 2D and 3D colored button controls, fancy ownerdraw menus, listboxes or comboboxes and even to customize the listview control.

EZGUI 4.0 has a new Thread engine which not only makes writing thread code much easier, but also much saver. EZGUI handles all the difficult stuff like syncronization using critical sections. It makes it easy to pass events between worker threads and the main (primary) GUI thread.

Basically, EZGUI offers so many high level features, you would be hard pressed to find another tool that handles so many different tasks.

EZGUI was developed with the idea of tasks and not API's. I didn't just pick API calls and say, let's make a wrapper for this. I asked the question "what tasks would a programmer need to do" and then I wrote high level commands to do the task. Some tasks took only a few lines of code, while others took hundreds of lines of code. Some tasks required hooks into the internal window procedure engine for all forms, to work, or requires subclassing of a control first (or even its children) to process everything necessary to accomplish the task.

The best example of such a high level command is the new EZ_StartDrag command.

This command alone has over 550 lines of code in it (maybe more) and it impliments the complex task of creating and moving a drag icon for both the listview and treeview controls. This is a very complex task, which requires subclassing the control (internally) and creating or using imagelists. Yet with one line of code you can impliment the drag icons for these controls.

There are many more examples of the high level nature of EZGUI. This is why I usually refer to EZGUI as an engine, rather than simply a library of code.

Also I haven't even mentioned yet a number of very high level features in EZGUI like its Canvas control, Sprite Engine with anti-aliasing and alphablending, the print engine, the graphics engine and more. The feature set is very extensive.

All this alone should speed up development time when building applications, but there is much more.

EZGUI 4.0 comes with the most advanced visual designer ever provided in the EZGUI line of software. The 1.0, 2.0 and 3.0 Visual Designers don't even come close to the advanced features of the 4.0 Designer.

For the first time, EZGUI users can build applications in a full RAD environment. No more copy and pasting of code. Now you can move seemlessly between the Visual Designer and your favorite code editor (works with the PB IDE and JellyFish) back and forth. The Designer will update your source code to match any changes in the Forms in your project. Using the new Smart or Intellegent Parser, the Designer literally rewrites your code for you and automatically runs your code editor of choice. You can build complete applications with dozens of forms as one complete project.

The Designer also has many ways to customize your applications code generation, via its project properties dialog. Change aspects of your projects code generation properties and you will get an application more suited to your style of coding. If there are not enough options for your coding style, then you can even write your own custom "code plugin" which can modify the code after the Designer generates it and before your code editor gets it.

The EZGUI Visual Designer is not like most programming RAD environments. It wasn't designed to emulate other programming environments, like VB. It was designed to optimize using the EZGUI runtime engine and its features. The Designer actually looks quite simple at first glance, but in reality it supports many advanced features.

One of my favorites, is the ability to hide the toolbar, statusbar, captionbar and menus of the designer in a "Full Screen" mode. This allows you to work unfettered with large forms that take up the whole screen.

EZGUI supports a layering feature, not found in most RAD tools. Similiar to graphics programs which can put objects on different layers, the EZGUI Designer can put controls on different layers. These layers can be shown or hidden when needed (also via code in your app). This makes implimenting Tab controls or those wizard style dialogs very easy. Layers are not tied to any one parent control (like a Tab control). They are independent and associated with the parent form.

The Visual Designer also supports all the controls supported by the EZGUI runtime (all the standard controls and most of the common controls). It also supports most of EZGUI's custom controls (Canvas, Turtle, Shape/HotSpot, masked edit, MCI) and even supports third party controls (which are in DLL form and support standard API's).

Unlike RAD tools that generate a lot of code and then you are left on your own, EZGUI provides a Visual Designer front end for fast development, a powerful code generator and smart parser to generate the GUI code and then a powerful GUI engine with a rich command set to handle all the tasks you need to build power and complex applications.

If your time is valuable and you need a fast development environment, EZGUI offers many exciting features that will make software development productive and fast.

If you have specific questions about EZGUI, feel free to post them on this forum, or email me at:

chrisboss@naxs.net

To be continued ...

posted 12-03-2006 05:38 PM         

The feature set of EZGUI 4.0 is very extensive, but here I will list just a few of the powerful features found in EZGUI 4.0 that help you develop state of the art applications.

First let's look at controls.

Not only does EZGUI support all the Standard controls, but is also supports most of the Common Controls.

Working with the common controls using the API is where things start to get a little bit tricky. EZGUI provides an extensive command set to support each control.

For example, when working with the Listview control, EZGUI provides commands to search a listview, to sort a listview, to customize it using ownerdraw or customdraw. It supports working with ImageLists which are very important for controls like the Listview.

The RichEdit control is very powerful, if one knows how to handle the more complex features of it. EZGUI provides commands (and events) to handle things like filling the control (or reading it) with huge RTF text strings (in the megabytes), setting text fonts, tab positions, paragraph settings and even hyperlinks. How about pasting RTF text from the clipboard into the RichEdit control.

Two new common controls supported in EZGUI 4.0 are the Rebar and Pager controls. While the controls seem simple at first glance, they may be difficult to impliment using the API. EZGUI 4.0 provides a feature where the child of a Rebar or Pager control is not other controls, but a Form. This way you can embed a form into a Rebar or Pager and then treat it like any other form, by putting as many controls on it as you like. This makes handling control events much easier, since the child controls always have a parent form, rather than a Rebar or Pager for a parent.

EZGUI 4.0 supports the Tab control, ToolBar, ProgressBar, TrackBar, StatusBar, UpDown control, Date Time control, Calendar control, Listview, Treeview, Rebar and Pager controls.

EZGUI also comes with a number of custom controls.

These are controls I have written, rather than builtin ones found in Windows. This actually gives you a number of extra components, not found in some other Design environments. EZGUI 4.0 comes with a Canvas control, Turtle Graphics control, MCI control, Masked Edit control, Drag Handle control, Shape/Hot Spot control, Files Listbox and Properties Listbox control.
If you paid just $20 for each control, this would add up to $160 and some of the controls are worth far more than just $20. The Canvas control alone is a complete graphics engine in itself.

The Canvas control is more than just a control to display a Bitmap. The graphics engine allows you to draw all sorts of things, from text, shapes, bitmaps, icons, imagelists, Gradients (and 3D Gradients), Polygons and PolyBeziers. The Canvas control supports double buffers, so you can draw on two different buffers and to copy images from one buffer to the other. It also supports DIB Sections. A DIB Section is where the Canvas control allows you to define the color format of the buffer (16, 24 or 32 bit) and gives you direct access to the bitmap pixel data. This allows high speed access to pixels. This is much faster than the Get Bits/Set Bits technique. That method requires copying the pixels (bits) to a memory string first, then modify them and then copy them back again. EZGUI gives you direct access to the DIB Sections pixel data, so you never have to move them. You modify them directly. In programs which modify large blocks of pixels, EZGUI's direct access would be significantly faster. You could easily impliment an image filter for the Canvas, like converting to GrayScale. You can read and write the pixel data using pointers.

Now if this wasn't enough, EZGUI 4.0 provides a new Sprite Engine. Sprites are image buffers which are drawn on top of the Canvas control, which provide for transparent pixels. This allows you overlay the Sprites onto a fixed background image. They have zorder, can be moved, shown, hidden, flipped, animated (multiple frames) and even AntiAliased. Sprites also support AlphaBlending, which means they can be semi transparent (or translucent). It's like looking through a colored piece of glass. The sprite engine even works on Windows 95! No DirectX, no GDI+, just pure GDI calls. While it may not compare to DirectX's speed, it is quite fast. It can be used for all sorts of business applications or to create animated controls of your own design.

All of this is built into EZGUI 4.0!

You don't have to purchase a separate graphics engine, since EZGUI comes with one.

The Canvas control and Sprite engine alone could be sold for $100 or more. Other Visual Designer environments don't come with such a complete graphics engine, so you can't compare the price of other tools with EZGUI, since it comes with so many other components.

As noted previously, EZGUI is very high level and it offers many very high level features, which only require a few lines of code to impliment in your applications. The Canvas control and Sprite engine is one example.

The Turtle Graphics engine is another. While the Canvas control is raster based, the Turtle Graphics control is vector based. You draw images by defining a string of turtle graphic commands (something akin to the old DOS Draw command). You can define an image using vector based turtle graphic strings and if you resize the image, it is scaled perfectly, since it is a vector based image. This is useful for building CAD like applications.

How about a Properties Listbox control ?
EZGUI's new control allows you add some advanced GUI features and it is built into the main runtime.

Many features which are often a pain to do using the API, are simple with EZGUI. For example, EZGUI 4.0 has a new simplified Thread Engine which not only allows you to create worker threads, but it has built in features to syncronize the worker threads with the main GUI thread. It uses Critical Sections internally to syncronize the sending of events between threads and also allows you to define your own critical sections for syncronizing things like the accessing of global variables between threads.

EZGUI provides commands for defining Tray Icons and Tray Icon Popup Menus, accessing the registry, accessing the clipboard with Text, RTF text and Bitmaps.

EZGUI's graphic engine provides features for drawing into any window DC directly or during ownerdraw events. EZGUI handles the cleanup for all graphics, such deleting bitmaps, brushes, fonts, etc. which your program creates, when the application terminates. You don't have to worry about all the possible resource leaks you may generate in code. EZGUI tracks such things for you and does its own house cleaning.

How about using regions to create non-rectangular forms or controls ?

EZGUI provides a simple command set that makes this easy.

How about those fancy ownerdraw menus or drop down lists (comboboxes) found in many applications today ? EZGUI 4.0 provides the new Simplified OwnerDraw command set which makes this easier than ever.

The thing to remember about EZGUI's command set, is High Level and Ease of Use. Many high level commands are provided which makes difficult tasks as easy as is possible. Once you get up to speed using EZGUI's advanced features, you will be able to write applications that once were left to advanced API programmers. If you can program using DOS Basic, you can write Windows applications using EZGUI 4.0 and with advanced features at that.

Have you stayed with the Console compiler, because you just can't make the move to GUI programming ? Then give EZGUI 4.0 a try and you will be surprised at what you can develop.

posted 12-07-2006 01:00 PM         

EZGUI 4.0's graphic engine is quite unique.

While PB 8.0 offers some great new graphic features and there are other third party graphic tools available, EZGUI's graphic engine offers some great features that can really enhance your applications.

Let me explain in a little more detail about what makes EZGUI graphic engine so powerful.

First, the Graphics engine went through some major changes in EZGUI 3.0, which has continued into version 4.0. In EZGUI 3.0 I introduced the first print engine for EZGUI. In an effort to not have to repeat code in the engine for different situations (in essence staying very modular), I reworked most of the graphic routines so they can be used in one of three ways:

(1) Draw directly on any given DC
(2) Draw on a Printer
(3) Draw on a Canvas control

The DC versions of the routines are the core of the graphics engine. The Printer and Canvas versions are simply wrappers over the DC versions, where the DC is already provided (for the printer or canvas).

This makes the graphics engine very powerful. While it makes the code for the printer and canvas control easier and cleaner (no need to track DC's), you still have access to the DC versions of the routines so you can literally draw on anything that will provide you a DC. This is very useful when working with third party graphic tools or controls and especially when working with EZGUI's own OwnerDraw features. All the DC graphics commands can be used to customize any control (or menus) that supports ownerdraw.

EZGUI 4.0 even introduces a number of new features such as accessing window DC's directly (or even the desktop) to draw on or to copy images from. If you need low level drawing features, EZGUI has them. If you need high level drawing features, EZGUI also has them.

Now the interesting thing about EZGUI's graphic engine is that there is no need to remember to free graphics objects, like Bitmaps, Brushes, Fonts, etc. While EZGUI allows you to free them via code, to simply free up resources used by windows, there is no need to, since EZGUI tracks them all and will delete all GDI objects when your app terminates.

Also there is no need to select objects into DC's and then have to remember to select the prior object back in. EZGUI doesn't require selecting of objects into DC's. You simply choose what to draw and EZGUI handles all the DC changes internally and always returns the DC to where it was previously, after you draw.

This way you concentrate on drawing and not on all the low level stuff of creating a DC, selecting DC objects, restoring DC's and deleting GDI objects.

EZGUI even provides a number of high level graphic commands which make things like Ownerdraw simple. EZGUI 4.0 has its own simplified command set for drawing 2D and 3D colored buttons and a variety of other control/menu items.

EZGUI provides a complete Printer graphic engine so you can easily write printer routines which handle most(if not all) of your printer needs.

Where EZGUI gets exciting is the Canvas control!

Rather than simply use a Static control (like PB 8.0 does), EZGUI 4.0 provides a real true Graphics control, designed from the ground up specifically for your graphics needs. Since the Canvas is a true window control, you can have as many controls as you like. You are not limited to some kind of set buffer limit for graphic buffers.

The EZGUI 4.0 Canvas control is very powerful and offers many very advanced features.

(1) It supports either Device Dependent Bitmap Buffers (the fastest repaint) or 16, 24 or 32 bit DIB section Bitmap Buffers. You chose which you prefer!

(2) It supports Double Buffers. One is a foreground Buffer (what you actually see) and the other is a Background Buffer. You can copy images from one buffer to the other and draw on either.

(3) It supports direct access to pixel data of DIB section Buffers. This is very important, since it allows you to write very fast pixel manipulation routines using pointers directly to the pixel data. You can write things like image filters, for example a gray scale image filter, very easily. Also the beauty of direct access to a DIB section, is that it is faster than using DIBSet or DIBGet API pixel functions (or the PB 8.0 commands) to set and get blocks of pixel data. Such functions require moving the data to a string buffer to manipulate and then moving it back again. This is two extra steps, simply to change the pixel data. EZGUI allows you to access the pixel data directly without having to move the data first.

Here is an example of an EZGUI routine which takes advantage of the Canvas controls DIB sections direct access to pixel data. This routine is an Image Filter which can convert the Canvas controls image (original taken from second buffer) to either GrayScale, Red Tinted, Blue Tinted or Green Tinted:

code:

' this is the format for 32 bit RGB pixels
TYPE EZ_RGB32
    B   AS BYTE
    G   AS BYTE
    R   AS BYTE
    Reserved AS BYTE
END TYPE
'
SUB UseFilterOnBitmap(BYVAL Mode&)
    LOCAL CW&, CH&, FirstPixel&, YB&, X&,Y&,PY&, V&
    LOCAL P AS EZ_RGB32 PTR
    EZ_GetCanvasSize "Form1", 100, CW&, CH&
    EZ_StartDraw "Form1", 100, CW&, CH&, ""
    ' copy 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
        YB&=CW&*4
        FOR Y&=0 TO (CH&-1)
            PY&=FirstPixel&+(Y&*YB&)
            FOR X&=0 TO (CW&-1)
                P=PY&+(X&*4)
                SELECT CASE Mode&
                    CASE 1
                        ' GrayScale
                        V&=(@P.R+@P.R+@P.G+@P.G+@P.G+@P.B)\6
                        @P.R=V&
                        @P.G=V&
                        @P.B=V&
                    CASE 2
                        ' Red Tinted
                        V&=(@P.R+@P.G+@P.B)\3
                        @P.G=V&
                        @P.B=V&
                        V&=V&+164:IF V&>255 THEN V&=255
                        @P.R=V&
                    CASE 3
                        ' Blue Tinted
                        V&=(@P.R+@P.G+@P.B)\3
                        @P.G=V&
                        @P.R=V&
                        V&=V&+128:IF V&>255 THEN V&=255
                        @P.B=V&
                    CASE 4
                        ' Green Tinted
                        V&=(@P.R+@P.G+@P.B)\3
                        @P.R=V&
                        @P.B=V&
                        V&=V&+80:IF V&>255 THEN V&=255
                        @P.G=V&
                    CASE ELSE
                END SELECT
            NEXT X&
        NEXT Y&
    END IF
    EZ_EndDrawByPtr
    EZ_EndDraw
END SUB

What kind of drawing commands are there?

Not only can you draw Text, Shapes (lines, circles, etc.) and Bitmaps, you can also draw icons, images from imagelists (which can have transparent pixels), Gradients, 3D Gradients, draw RTF text (rich text from a Richedit control), tile bitmaps and more.

EZGUI 4.0 introduces the new relative coordinate Polygons or PolyBeziers! This means, rather than define the actual coordinates for the shape (polygon), you can define its relative coordinates within a 1 x 1 square box (using decimal values) and then draw the shape as many times as you want in different locations on the Canvas control. EZGUI will even scale the polygon. You simply define the rectagular area where the polygon will be drawn and then EZGUI will calculate the actual coordinates for all its points for you.

Here is an example:

code:

' defines a upside down triangle
EZ_DefPoly  "(0,0)(1,0)(.5,1)(0,0)"
EZ_Color 0, 2
EZ_CDraw %EZ_Poly, 0,0, 32, 32,1, 1
EZ_CDraw %EZ_Poly, 64,64, 32, 32,1, 1

EZGUI 4.0 even allows you to draw on a Canvas control a vector image defined using its own Turtle Graphics macro language (which can also be drawn in a Turtle control as well), as if it is an object.

EZGUI even allows you to create Bitmaps and use them directly as image buffers

Now if this isn't enough, EZGUI 4.0 introduces its new Sprite Engine for use on Canvas controls.

Sprites are image buffers themselves which can be drawn on (or simply copy a Bitmap too) and are assigned to Canvas controls. Sprites can have multiple Frames, for animation purposes, can be shown or hidden, flipped vertically or horizontally and can be moved to any position on the Canvas control. EZGUI automatically updates the Canvas image so the sprites are merged with the Canvas control image.

Sprites can also be Anti_Aliased and one of the more exciting features is the new AlphaBlending, where the sprite is semitranparent (or translucent). Sprites can have fully transparent pixels as well.

Sprites are useful for more than just Game development, but can be used for all sorts of business applications. Imagine using sprites for overlays for images, like a weather map which might have multiple overlaps (roads, streams, weather).

Also EZGUI's graphic engine will run even on older operating systems, like Windows 95 without the need for any special runtimes (like DirectX or GDI+ or OpenGL). This allows you to support older computers, which increases the market for your software.

Since Sprites are themselves independent image buffers, they can be dynamically changed and drawn on at runtime. This means you are not limited to sprites which are simply loaded bitmap files. You can dynamically create your sprite images and even change them. Sprites can even be used as part of the drawing engine, as a middleman, to get anti-aliasing from other graphics commands. Draw using standard drawing commands on a sprite buffer and then tell EZGUI to draw the sprite directly on the Canvas controls image buffer (permanently). This will allow you to anti-alias the graphic object.

Now add to all of this the many other Graphics features in EZGUI 4.0, such as the Turtle Graphics Control (a vector based graphic control), the Shape/Hot Spot control, the MCI control (display video, play audio files, etc.) and more, and you have a powerful graphics tool for building advanced GUI programs.

Now remember, that all of this is part of the complete EZGUI package. Not only do you get all the GUI commands (Forms/controls) in EZGUI's runtime engine and its Visual Designer/Code Generator, but you also get a complete Graphics (and print) engine builtin. Its all one complete product!

If you want advanced graphics capabilities in your apps, while it still being easy to use, please take a serious look at EZGUI 4.0.

posted 12-21-2006 05:04 PM         

One of the first things people notice about EZGUI 4.0 is the price. With all the other lower price alternatives, why is EZGUI 4.0 priced so much higher?

First, it should be noted that EZGUI is in its 4th generation, unlike other tools which are only in their 1st or 2nd generation. I have had a chance to weigh out marketing factors such as price in earlier versions (EZGUI 1.0 sold for only $99). I found that the price often reflects the value of the product and it also effects such things as tech support. By targeting a lower price market, I found that it tended to effect decisions I made about the features I would put in the product and how much time I would spend on tech support.

Have you ever wondered why most of the big software companies today, charge you high prices for tech support subscriptions and any free tech support offered, likely never gets you in contact with a real person, or at least not quickly. Even phone support is done by machines, rather than real people. Why?

Because it costs a lot for real tech support and most people want low prices for the product.

In EZGUI's 3rd generation, I made the decision that by charging a slightly higher price up front, I would be calculating into the product decent tech support (quick, detailed and helpful).

To appreciate the quality of my tech support, simply scan these forums and see not only how often I post answers to questions, but how detailed it often is. I try to post source code when I can as well.

One of the things you can't see from the forums, is how much time may be spent in finding the answers. At times I have spent hours trying to track down a problem or in researching an answer. While most customers don't need that much help, when it is needed, I try hard to be there.

I also get a good deal of email from customers where they ask questions and you won't see this reflected on my forums. At times some of the email replies are very long and detailed explanations of things.

This is part of the cost of the product!

Now the rest of the products value has to do with both features and productivity.

First, when it comes to features, you need to actually calculate what is really being offered.

EZGUI is more than just a Visual Designer!

EZGUI does have a powerful Visual Designer which allows you to build applications quickly. That has value!

EZGUI is also a runtime!

The EZGUI command set is simply extensive!
While there are over 600 commands in the command set, many commands work on multiple control classes, so it is like having many hundreds of commands more. Two commands alone encapsulate over 150 API messages for use with a variety of controls.

EZGUI is not simply a wrapper over API functions or messages. Often the commands are quite high level. Some even consisting of hundreds of lines of code in them.

Now add to this, EZGUI's engines!

The engines in EZGUI go beyond just commands. They are internal engines which handle complex tasks (like drag and drop, subclassing, event generation, etc.) This is why when working with the common controls, it is so much easier, because you don't have to write complex WM_NOTIFY code in your apps. EZGUI is already processing the most important notification messages, processing them properly and generating easy to use events from them.

EZGUI 4.0 has over 100 actual types of Event it generates. You don't have to even write a single line of code in many instances to get these events. They just occur and the event engine passes them to your application. This is all part of EZGUI's internal engines.

Now these three features alone (Visual Designer, Runtime command set and Engines) are worth quite a lot.

Now add to this, the custom controls added to EZGUI 4.0. How much would you pay for each control type?

EZGUI 4.0 has:

- masked edit control
- MCI control
- Turtle Graphics control (vector based)
- Canvas control (raster based)
- Shape/Hot Spot control
- Drag Handle control
- Properties Listbox control
- Files Listbox control

What are these components worth to you?

If you purchase separate products for the following:

(1) Visual Designer
(2) Graphics Engine
(3) Printer Engine
(4) GUI Library
(5) Custom controls (like masked edit, MCI, properties listbox)

What do you pay for each of them ?

When you add up the price for buying separate components for many of these , and other tasks, how much does it cost?

With EZGUI you get all of it in one package!

Lastly, one aspect of value which is often overlooked is what I will call "code maintainability".

Especially when writing commercial applications, it takes time to write the code and you know the old saying "time is money". But also consider how much time is spent on maintaining code?

One aspect is in updating it and adding improvements. The other is in debugging code.

One of the reason programmers choose the BASIC programming language is because of easy to read code, fast coding and code maintainability. One can put aside a BASIC program and come back to it years later and they will likely be able to figure out how it works in a reasonable amount of time. Not so with some other programming languages.

Now BASIC for windows is complication by the fact that a lot of API code is necessary and that is definitely not readable or easily maintainable. Can you put aside your API code and come back to it years later and understand what it is doing?

While EZGUI does have a learning curve to it, like anything else, you will find the code is very readable. You can understand what it is doing. Now some Windows tasks are complex, so even the EZGUI code for that task may be a little more than simple, it likely will be much easier to read and understand than the comparable API code for that task.

Especially for software that will require long term maintainance, EZGUI offers you something that can't have a price put on it.

Simply put, do you value your time?

What is it worth to you?

EZGUI 4.0 makes a programmer productive at the highest level I personally can make it. That was my goal in its design.

If on average, when you have to handle a difficult programming task, if EZGUI only takes you 15 minutes compared to an hour using the API, how long will it take before EZGUI has saved you a significant amount of time?

Just do the math!

If it takes an hour to write a simple EZGUI application, that would take you 4 hours using the API directly and you get paid $30/hour, then you have saved $90.

I have a lot of experience in writing custom software for a variety of businesses and I know that most complex software has many hundreds of man/hours in them (sometimes even thousands). Just imagine the savings in the long run, when using a product as productive as EZGUI 4.0 is?

The value of a product is far more than what meets the eye. One must calculate all the benefits of the product and all the ways it may save.

posted 12-22-2006 12:08 AM         

Before I discuss some specifics here, I strongly encourage you to visit these forums and to post questions to EZGUI users, about there experiences in moving straight from DOS Basic (or PBCC) to PBWIN and EZGUI.

You might be surprised how much of a difference it made in their being able to migrate from DOS Basic to Windows.

Why?

There are a number of reasons, but I will enumerate a few here.

First, EZGUI uses a DOS Basic syntax (or similiar) for a number of things.

For example, EZGUI has a command:

EZ_Color

which is nearly the same as DOS Basics Color command. EZGUI predefines all the 16 standard QB colors (plus 16 more pastel versions of those colors). For example if you wanted black text on a white background, you would use:

EZ_Color 0, 15

EZ_Color effects many other commands that come right after it. Whereas in DOS, it would simply effect the PRINT command, in EZGUI it effects all the PRINT commands (one for DC's, one for Canvas control, one for printers), it effects the creation of controls (FG is text color, BG is background color), it effects drawing commands for shapes (rectangles, circles, etc.).

This makes your coding at least similiar to DOS Basic.

Another interesting feature is the coordinate system for Form and Control creation. EZGUI uses a character based coordinate system.

For example, you could define a form to be 80 x 25 (80 characters wide and 25 character rows high).

EZGUI uses a predefined character unit size at startup. It is the size of the system font character, when the system is using small fonts. This is 8 x 16 by default (the font setting on a system effects this).

So you might ask, how do you define forms and controls down to the pixel level?

Easy!

Character units can be defined in decimals!

For example, you could define a control to be 10.5 character units wide. This allows for precise sizing down to the pixel.

Just like defining control colors is easy, so is defining their font.

EZGUI defines 6 default fonts (system font, etc.) at startup. Similiar to how colors are given a color #, so are fonts. Fonts 0 to 5 are predefined. You can create your own fonts and they will start from 6 onward.

To use a font for printing or creating a control, you simply use the:

EZ_UseFont

command just before the drawing command or control creation command.

ie.

EZ_UseFont 5 ' terminal font

Its that easy! Even with the common controls!

The next thing that makes EZGUI easier for DOS Basic programmers, is that it is event based and not message based.

What this means, is that EZGUI apps don't require window procedures or dialog procedures. They simply are not necessary (you can use them in the rare instance you need to expand EZGUI beyond its abilities, but they are not normally needed).

EZGUI has an event based syntax.

EZGUI has a universal routine (called EZ_Events) where all events for all forms and controls are sent. You simply parse out the events for each specific form and each specific control.

One of the problems with API code, is that you often require a window handle for dialogs and a dialog handle, plus control ID, for controls.

Window (or dialog) handles require using global variables to track them.

EZGUI uses an easier method!

All Forms are given a name, like:

"MyForm"
"MainForm"
etc...

This means you create a form (dialog) with a name, and then always reference it in the future by that name (it is not case sensitive either when calling EZGUI commands). This is much easier for tracking what form you are working on.

Now controls are referenced by an ID number (can be defined as a constant too).

You can compare the use of Form names and control ID's to Street names and House numbers. Its that easy to follow! It makes coding much easier.

Much of the coding style when using the API is defined that way, because windows was written in C most likely (and not basic), so all of the function calls, etc tend to use C style syntax.

EZGUI was written in PB (6.1) and it's command set uses syntax more familiar to Basic programmers. EZGUI subs/functions use PB variable length strings, rather than asciiz. EZGUI commands uses simple character strings to define properties, rather than a multitude of constants.

For example look at this control creation command:

EZ_ListBox 150, 1, 11, 58, 6, "", "RSAJV"

Notice not only the character units (located at 1,11 and 58 x 6 characters in size), but also the property string at the end. The R property is raised border. The S property is a sunken border. The A property means alphabetize the list. The V property means add a vertical scrollbar.

Can you see how much easier property strings are, especially when the letter used is the first letter in the property description. Compare this to using a bunch of long API constants for defining window styles.

Most EZGUI commands use such a simple property string syntax. This makes it easier to remember the properties, rather than long constants.

The point is that EZGUI tries to keep the command set simple, like most DOS Basic commands are simple.

If you are having difficulty making the transition from DOS Basic (or PBCC) to Windows (GUI) apps, then seriously consider EZGUI 4.0.

There are a number of EZGUI users who are using it to migrate their DOS Basic (or PBCC) apps to true windows apps. EZGUI's whole design makes the transition much easier. If you doubt whether EZGUI could make that much of a difference, feel free to post on this forum (in the customer feedback forum) questions to EZGUI users themselves, who made the jump straight from DOS basic (or PBCC) to PBWIN and EZGUI. Hear their experiences! You might be surprised.

[This message has been edited by Chris Boss (edited 12-22-2006).]

posted 12-28-2006 01:17 AM         

Here are some posts on this forum with some discussions of new EZGUI users who were DOS Basic programmers making the jump to Windows. Also some experienced EZGUI users who did the same thing when they started, tell about their experiences.

I think reading such experiences will give a more realistic perspective about moving from DOS to Windows using EZGUI.

Enjoy!

http://chrisboss.hypermart.net/ubb/Forum1/HTML/000178.html

http://chrisboss.hypermart.net/ubb/Forum5/HTML/000012.html

http://chrisboss.hypermart.net/ubb/Forum5/HTML/000014.html

http://chrisboss.hypermart.net/ubb/Forum5/HTML/000121.html

http://chrisboss.hypermart.net/ubb/Forum5/HTML/000127.html

posted 01-05-2007 06:40 PM         

I have often used the term Engine when describing EZGUI. What does this really mean?

I refer to it as an engine, because EZGUI literally takes control of your applications event engine.

There are no Dialog or Window procedures in EZGUI apps (unless you do a hook to access them, which is not normally necessary).

There is no Message Loop in EZGUI apps.

The reason is that the EZGUI engine, takes control of your application and it runs its own internal window procedures and message loop.

When none of your code is executing, EZGUI is running its own internal message loop.

How does this work?

EZGUI is the first thing started up when your app is run. It then calls its own main procedure called EZ_Main.

In EZ_Main most startup code for an app is executed and then a Startup form is displayed.

Once the first form is displayed, control reverts back to the EZGUI engine. It is now running its own internal message loop, processing messages.

What happens next?

EZGUI processes many of the common window messages internally and translates them into something more meaningful to the programmer. It converts the messages into simpler Events.

For example, when a control is clicked it gets the %EZ_Click event. There is no need to know the specific API constants for each control class (type). The events are universal amoung all controls that support it. There are no messy messages to process. Your app just gets events.

Even the more complex controls like the listview and treeview get a variety of events. The EZGUI engine processes the WM_NOTIFY message internally and converts it into easy to understand events. This is more than just passing on messages. Often EZGUI will do some extra processing to get important info about the event and will pass that on.

A good example are scrollbars. When a scrollbar is scrolled, your app will get the %EZ_Change event for the control and it will pass the current position of the scrollbar. No API code necessary to process the message. Some of the more complex controls do a good bit of internal processing for events.

In essence EZGUI is making the processing of events as simple as possible.

Here is a flowchart of the EZGUI internal engines execution:

http://cwsof.com/details/programflowchart.htm

Screenshots of Visual Designer:

http://cwsof.com/details/screenshots.htm

While EZGUI has many lower level commands in its command set, it also has many very high level commands. EZGUI has many low level features to allow advanced programmers customize the engine, while it supports high level features which make programming complex tasks much easier. The high level features of EZGUI is what really makes it stand out from other products.

Here are a few examples:

The EZ_ToolBar command which creates a Toolbar and populates it with buttons. It is hundreds of lines of code internally. It handles many of the complexities of toolbars while making the implimentation as simple as possible.

The idea is to impliment very complex tasks into as simple a task as possible.

When writing pure API code, a programmer may often only use the simplist features of the function, while avoiding the more complex. EZGUI attempts to put even the most advanced features of the API into its command set, so a programmer can push the limits of Windows programming.

A really good example is the commands which display the common dialogs.

Now remember, that EZGUI is more than just a set of wrappers over API calls. It is an engine. This means it often impliments complex internal engines to give a programmer access to advanced features of the API.

The common dialog commands in EZGUI provide more than just displaying the basic dialog. EZGUI allows you to customize the look and feel of the common dialogs. For example, you can easily modify the buttons on the dialog so they are ownerdrawn, so they can utilize EZGUIs 3D button drawing commands. You can add EZGUI forms (with controls) to the dialogs to expand their look. You can easily center the dialogs or change their size. EZGUI gives you the ability to truly customize the common dialogs so you can go beyond their basic features. Internally EZGUI is automatically using the hook features of the common dialogs to access their dialog procedures. EZGUI processes a number of dialog messages so it can customize the dialog in a variety of ways.

Over and over again, EZGUI taps into the advanced features of the API to give programmers access to features they wouldn't have normally used before.

EZGUI's new sprite engine is an example of a very high level command set. Sprites are integrated into the EZGUI Canvas control. The Canvas control is a very advanced graphics control, supporting double buffers, DIB sections, etc. The sprite engine is very complex handling such things as anti-aliasing, alphablending, frame animation and more.

Another very high level feature is EZGUIs new Drag and Drop engine, which impliments drag icons for the listview and treeview controls. This is actually a very complex task and yet EZGUI impliments it with just a few lines of code.

The new Thread engine in EZGUI makes threading applications easier than ever. It is even easier to use than the native PB thread commands. EZGUI syncronizes worker threads with the main GUI thread (primary thread, which is your apps main process) using critical sections. You can easily send events between the worker threads and the main GUI thread. While threads are easy to create in PB, they often are not understood properly in the context of how Windows actually handles threads. EZGUI takes all of this into consideration and offers a simply and easy to use implimentation that helps you get the most out of threads, safely.

The key point to understand is that EZGUI is more than a set of API wrappers. It is an engine which handles complex tasks in as simple a manner possible, while still allowing the programmer to use low level features when needed.

One last engine to consider is EZGUI's "house cleaning" engine. Yes, EZGUI cleans its own house. Just like the BASIC language improved programming by handling string management for your, unlike other languages which required you to clean house manually. EZGUI handles much of the necessary housecleaning when it comes to things like Bitmaps, menu handles, brushes, fonts, imagelists. EZGUI tracks all of these things and makes sure it is all cleaned up (freed) when your app terminates (or sooner if something is only needed for a moment). You don't have to worry about restoring DC's, freeing brushes or pens, deleting bitmaps or fonts. If something is only used for a moment, EZGUI creates, uses (changes DC) and then frees (and restores a DC) the object for you. If the object is used long term (like a font or a bitmap) then EZGUI tracks it, so if you forget to free the object (which you can do using EZGUI commands), EZGUI will do it for you when your app terminates.

You don't have to worry about tracking all the resources in your app anymore.

The list of high level features in EZGUI is extensive. The things discussed above only scratches the surface of EZGUI's high level engines. There are many other high level features, like non-rectangular forms (using regions), tray icons, visual designer drag and drop engine, subclassing engine, graphics engine, print engine and more.

Some may think EZGUI is a tool for beginners (aka. the EZ in EZGUI). While EZGUI is easier to use than some other products and this does help beginners, it is also an advanced GUI engine which allows programmers to go far beyond the basics of Windows programming. EZGUI offers a number of features that experienced API programmers may not know how to do. This means EZGUI apps can push the limits of Windows programming.

posted 01-22-2007 02:45 PM         

Before I discuss this aspect, let me first say that I in no way want to degrade the value of competing products. Each product has its advantages.

The question here though, is what does EZGUI 4.0 offer that may not be offered by other Visual Design environments ?

While there may be a variety of standalone products that do some of the things here mentioned, the question is, are they part of an integrated product, especially a RAD development system.

The keyword here is Integrated!

Remember the features discussed here are not a bunch of different tools from different vendors packaged together (or worse purchased separately). They are features of a completely integrated software development tool.

You already know (from the above posts) that EZGUI is both a Visual Designer (RAD)/Code Generator plus a GUI engine. But what unique features does it offer that can make a real difference in software development?

Let's first take a look at its custom controls. The choice made in the controls supported, was "what is missing" from the standard windows controls that would be very useful to the average programmer. For example, it wouldn't make sense to add a grid control to EZGUI, since a Listview control can act like a simple Grid. To add a high end Grid control would be overkill, since it would be better to use a third party control, like EGrid or SIGrid which are highly advanced. EZGUI's custom controls, while very powerful, are controls which the average programmer would find useful for many different applications.

I added an MCI control, so users would have access to a variety of multimedia features, while not making it an overly complex control. The EZGUI MCI control is more than just a simple wrapper of some MCI functions. It is actually quite advanced in that it simplifies the use of MCI, making it easier to use, while still offering a number of advanced MCI features. The control can act a parent window for displaying movies, so there is no need to use a separate window. If all you need is the ability to play common movie formats (AVI, MPEG), play wave or MIDI files or a simple interface to anyother MCI device, then this control does it for you and all in a small footprint of only 31 KB (it is a separate DLL from main runtime).

EZGUI 4.0 has a very powerful Turtle Graphics control. This control is quite unique in that it is vector based (using a very simple Turtle Graphics macro language). There are times when you may need a graphic tool, which is both easy to use, scalable and is vector based. This control doesn't get fancy with stuff you don't need. Some software simply needs the ability to draw scalable drawings (line drawings) quickly, with a small footprint (it is only a 40 KB DLL). EZGUI even allows you to be able to draw a Turtle Graphic on another control (like a Canvas) besides the Turtle control and even on a Printer.

While these two controls are very useful for a programmers toolbox of controls, notice they are separate DLL's from the main runtime. The reason is, why bloat the main runtime, with something that might not be used as often, so they were put into separate DLL's.

Now EZGUI's Canvas control though is part of the main runtime. The Canvas control is the most used custom control in EZGUI, when it comes to graphics, so it is integrated into the main runtime. The other reason is that EZGUI's graphic engine is completely integrated, so some graphics features, like the Canvas are put into the main runtime. If a feature in EZGUI, is integrated into other features of the engine, then it is put into the main runtime.

The graphics engine is at the core of the EZGUI main runtime, so many graphics features are in it. EZGUI has a variety of low level graphics commands, of which other commands are built upon. For example, EZGUI can draw a variety of objects (shapes, text, bitmaps, imagelists) onto any given DC, on the Canvas control and on a printer. Rather than have three separate graphics engines, EZGUI bases its highlevel commands on a set of lower level ones, so there is little waste in repeating code. Even EZGUI's ownerdraw engine, is built on this core graphic engine. Internally, EZGUI calls itself quite often, building upon lower a level command set to build higher level commands. This internal integration actually saves in the long run, both in the size of an application (and the runtimes) as well as reliability.

This internal integration of features, is why EZGUI can do so many different things. EZGUI has builtin commands for drawing 2D and 3D colored buttons. No separate control is needed for this. EZGUI has its own OwnerDraw Button control, which can either be drawn via a users own code (using EZGUI graphics commands) or via built in highlevel button drawing commands. These high level button drawing commands are based on EZGUI graphics commands and also EZGUI's ownerdraw engine. By building upon lower level commands, EZGUI can build higher level commands with little extra overhead.

Another example if the benefits of this integration, are two new custom controls. The property listbox and files listbox controls. These are two very useful, advanced controls. They have many different applications for common software. Yet the overhead in EZGUI to create these controls, is actually quite small. Why ?

Because EZGUI is an integrated product!

These two controls are actually superclasses of the standard ownerdraw listbox control. EZGUI already has a core graphics engine. EZGUI already has ownerdraw engine. It didn't require all that much to build these two controls on top of the existing engines. The point is, that this integration, actually makes it easier to add more and more advanced features to EZGUI, while still maintaining a small footprint. Also it also means EZGUI is more reliable, since it builds upon itself and if the core engine is reliable, then the higher level commands built on it are more likely to be reliable.

This is why at least 80 to 90 percent of the EZGUI command set is in the main runtime. They benefit from this internal integration.

While it is true, you could use another RAD tool to build an application (visual designer) and then use other third party tools to add some of the same features found in EZGUI, it still won't have the same degree of integration that EZGUI has. This benefits you both in size of applications as well as in reliability.

EZGUI has one feature set, which I have yet to see in any other product for use with Powerbasic. That is its Visual Design engine. No, I don't mean the Visual Designer! I mean a Visual Design engine (drag and drop). You can actually build your own WYSIWYG Visual Designer type application with EZGUI 4.0! EZGUI's own Visual Designer, was built with EZGUI itself. Again this comes back to the value of integration. EZGUI has a low level subclassing engine which makes it easy to subclass controls. While the initial benefit is that you get access to window procedure of any control to process low level messages, EZGUI built upon this feature to add drag and drop features for building your own Visual Designer. EZGUI handles the drag rectangle (called rubberbanding) stuff and even has its own Drag Handle control to impliment those difficult drag handles. It's all integrated together (the drag handle control is a separate DLL, 18 KB in size). There are so many things you can do with the Visual Design engine.

One must appreciate that EZGUI is now in its 4th generation, and in each new version new features were added by building upon what was already there. Again, this means EZGUI often calls itself internally.

The latest addition to EZGUI is its new Sprite Engine. EZGUI 3.0 already had a Canvas control and a Graphic engine. EZGUI 4.0 simply built a Sprite Engine on top of this graphic engine. This new feature, again makes EZGUI stand out from the pack. Remember, this is not a separate graphic tool. It is an integrated product, where the sprite engine is part of the EZGUI engine. Since sprites are integrated with the Canvas control, and the Canvas control is integrated with the graphics engine, all of it was put into the main runtime DLL.

When programmers compare EZGUI to other products, they often just see different visual designers/code generators.

What makes EZGUI different is that it is much, much more!

It is a GUI engine with a variety of very high level tools integrated together. You don't have to purchase a separate graphic tool. You don't have to purchase a separate printing tool. You don't have to buy a lot of custom controls (since EZGUI comes with a variety of controls, plus its engine allows advanced customizing of existing controls).

EZGUI is truly different than the rest!

This is not to say that other tools don't have their place and don't have advantages of their own. But when one examines EZGUI, you see why it continues to use a runtime, rather than just generate source code. It would be very difficult to produce a 100% source code version of EZGUI (not counting also that I couldn't protect proprietary code), since EZGUI is so integrated. It had to be designed as an engine (in DLL form).

But what some may consider a weakness (runtimes) is also its strength, since its internal integration allows each generation of EZGUI to add very high level features, while still maintaining a very reasonable application size.

It is my opinion that at a certain point, an application built with EZGUI would be smaller than its 100% source code counterpart. The reason is that since the EZGUI engine does so much work for you, the actual EXE you compile is much, much smaller and because of its internal integration, the feature set is so large that to emulate all of it using 100% source code would produce a very large application. As an application gets larger and larger and more complex (using more and more of EZGUI's features), at some point the EZGUI application would be smaller than its 100% source code counterpart. True small utilities that you might write with EZGUI would be larger, but if you are writing large, complex business applications, the benefits of EZGUI will become apparent.

posted 01-25-2007 01:41 AM         

When a longtime DOS Basic programmer can make even an experienced C programmer wonder in amazement about how he built such an advanced GUI, something is working right!

This summerizes a true story, told to me by a customer.

I have seen EZGUI turn some DOS Basic programmers, who just couldn't quite grasp programming in Windows, into experienced Windows developers. Why ?

EZGUI was designed with such programmers in mind. The ease of use gets programmers started in Windows development, while EZGUI's professional toolkit gives them the tools they need to build advanced GUI's, not just simple ones.

If you program for a hobby, then EZGUI's price might be beyond your budget, but if you program for a living (professionally), then the price is a small issue compared to the results one gets with it.

EZGUI wasn't designed, just to make programming in Windows easier for beginners. There is a reason, that since EZGUI 3.0 I added the word Professional to the product name.

EZGUI 4.0 Professional is a tool for professionals!

EZGUI 4.0 allows you to build the most advanced GUI possible using the core features already built into Windows, even since Windows 95. It doesn't require runtimes from other compilers, like ATL or MFC. It doesn't use any bulky OCX's for controls. EZGUI calls the core operating system DLL's directly. Yet EZGUI pushes the limits of what Windows offers.

EZGUI was designed so you can build what you need, rather than have to keep adding other external controls. EZGUI's builtin support for both ownerdraw and customdraw, allow you to customize the look and feel of your applications for that professional look. EZGUI's own custom controls add functionality far beyond the standard controls in Windows. Especially EZGUI's Canvas control! It allows you to create very advanced graphic oriented GUI's.

Much of these details have been discussed above. The point is that EZGUI allows you to create GUI's that make your software stand out as leading edge products. If you have been looking for something to give your company an edge in building software for Windows, please seriously consider EZGUI 4.0.

What makes EZGUI unique is the extensiveness of its command set. Few, if any, other tools have anywhere as complete a command set.

Are there some things EZGUI does not have ?

Of course, there may be somethings that other tools have, that EZGUI does not. But does this mean EZGUI is incomplete? No!

EZGUI was designed so you can built it yourself, rather than have to add other tools to add functionality. While EZGUI does support third party controls in DLL form, it currently does not support ActiveX controls. Why ?

I won't add ActiveX support until I can do it by calling the OS directly to do it. I am still in a learning process when it comes to OLE (which COM and ActiveX is based on). I have seen other tools take short cuts in this, by calling ATL (which is not a core OS DLL, but a runtime of MS C compilers) or Jazzage (a third party product). I don't add things to EZGUI unless I fully understand the core OS functions which handle it.

Is the lack of ActiveX support too great a weakness? IMO, NO!

EZGUI was built to allow you to extend the functionality of much of the standard controls, by means of ownerdraw, customdraw and subclassing. EZGUI has builtin engines which handle all three which makes it easy to expand upon existing controls. EZGUI has an advanced graphics engine to support this as well.

For example, when designing the latest Visual Designer for EZGUI 4.0, I needed a control similiar to a listbox, but with a more graphic look, which could respond quite differently than the standard listbox. It was not too difficult to do by using an ownerdraw listbox and EZGUI graphics engine. To the outsider, it would appear that the designer was using some kind of third party control. In reality, it was simply using an ownerdraw listbox which was extending the features quite significantly, and all done using EZGUI commands.

EZGUI has an easy to use command set for implimenting 2D and 3D colored Button controls. No need for third party tools there!

Need a fancier TAB control? Simple with EZGUI's ownerdraw support.

Examples of customized controls:
http://cwsof.com/controls01.png
http://cwsof.com/controls02.png
http://cwsof.com/controls03.png

Want a non-rectangular Form (dialog)?
Easy with EZGUI. Simple select a bitmap and EZGUI creates the region for you and draws it as the background for the form.

The point is that EZGUI gives you the tools to build most anything you may need. Yes, you may still want to use a third party control for very, very advanced stuff (like EGrid, SIGrid or RMChart). While reinvent the wheel? Yet, EZGUI allows you to build your own unique controls and forms, far beyond the standard look and feel.

In the right hands, EZGUI can be used to build some of the most advanced GUI's one can imagine without having to call the Windows API.

If you want professional results, then EZGUI gives you advanced tools to build what you want.

[This message has been edited by Chris Boss (edited 01-25-2007).]

posted 02-03-2007 11:00 PM         

The EZGUI 4.0 command set is very high level and it offers you the ability to develop advanced GUI's with little effort.

I'll discuss just a few of the higher level commands in the engine and how they allow you to go beyond the basics of Windows programming.

(1) The common dialogs.

Ok, it isn't awfully difficult to display the common dialogs, but what does become more complex is the customizing of the common dialogs. EZGUI allows you to treat a common dialog as if it were a normal EZGUI form. This means you can add child forms to the common dialogs (and controls on them) easily. You can resize the common dialogs, center them, preprocess some of their events, set their colors and even convert their button controls to ownerdraw buttons and draw the buttons yourself using EZGUI's ownerdraw engine.

Here is an example of the Open File dialog which has been centered on its parent window, its background brush customized, its buttons converted to 3D buttons (ownerdraw) and a Canvas control added to it so you can display the file images (bitmaps).

http://cwsof.com/ezcmdlg.png

Does your programming tool or RAD tool give you such abilities ?

Here is the code to do this in EZGUI:

To display the Dialog:

code:

EZ_Color 0, -2
EZ_ChangeDlgButtons %App_ButtonShape
F$=EZ_OpenFile("Main","Select Bitmap:", "", "Bitmaps (*.bmp))|*.bmp|", "PRZNS")

Here is the common dialogs event code (yes it gets events like other forms) which creates a child form (which will have a Canvas control put on it):

code:

    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
                     EZ_Form "DLGCHILD", FormName$, "", CW!+1, .5, 26, 13,"P"
                     EZ_CenterForm "Main", FormName$,0
                 END IF
             CASE 1152  ' textbox on 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    

There is some more code for handling the Canvas control, but you can see from this how easy it is to modify a common dialog to change its look and to add child forms to it and to process its events for its own controls.

(2) Drag and Drop (build your own visual designer)

EZGUI makes it easy to build your own drag and drop application. It makes it easy to impliment rubberbanding (drag rectangle or circle or line):

http://cwsof.com/ezdragrt.png

It is easy to impliment actual drag handles:

http://cwsof.com/ezdraghd.png

EZGUI handles all the hard stuff for you, such as snap to grid, drag handles, actual dragging of controls and rubberbanding (drawing of drag rectangle).

Here is EZGUI code to define a form (called MAIN) as a drag and drop form:

code:

EZ_SetCapture("Main")

To make a created control dragable simply subclass the control using mode 1, just before creating it:

code:

EZ_SubClass 1  
' create the control here

To put EZGUI in Visual Design mode and to define attributes of the drag engine (cursors to use, snap to grid, etc.) uses code like this:

code:

EZ_SetCursor "F_READY", 7
EZ_SetCursor "F_DRAG", 6
EZ_SetDragRectAttributes 2, RGB(32,32,32), 0
EZ_SubClassMode 3
EZ_SetGrid 8, 8

Heres is the actual event code for the rubberbanding:

code:

CASE %EZ_Window
    IF CMsg&=%EZ_Drag THEN
        App_DragX1!=EZ_CharX(CVal&,0)
        App_DragY1!=EZ_CharY(CVal&,0)
    END IF
    IF CMsg&=%EZ_Drop THEN
        App_DragX2!=EZ_CharX(CVal&,1)
        App_DragY2!=EZ_CharY(CVal&,1)
        DIM AC!, AR!, AW!, AH!
        AC!=App_DragX1!
        AR!=App_DragY1!
        AW!=App_DragX2!-App_DragX1!
        AH!=App_DragY2!-App_DragY1!
        ' use rect size here to create a control here
        EZ_RedrawForm "Main"
    END IF

Of course there may be some more supporting code to impliment different aspects of drag and drop, but this is the core code necessary.

EZGUI 4.0 has a number of high level features which require little coding to impliment. The Listview and Treeview controls can impiment dragable items (and drag icons) using a few lines of code.

ie.

code:

CASE  %FORM1_LISTVIEW1
    IF CMsg&=%EZ_DragItem THEN
        ' defines imagelist # and image index
        ' and properties for drag and then
        ' starts drag operation
        EZ_StartDrag 1, 2,0,8, "TA"
    END IF

A Listview control can be sorted with just a few lines of code!

ie.

code:

EZ_SearchLVCol 0
EZ_SortLV "TEST",%TEST_List, 0

You can sort by column or every multiple columns combined.

The point is that EZGUI has many high level features which allow you to create advanced GUI's with a minimum of coding and no knowledge of the windows api is needed.

Whether is is ownerdrawn controls, advanced graphics, drag and drop, or EZGUI's own custom controls (ie. property listbox, vector graphics, sprites and animation, multimedia MCI), it has the command set and features needed to produce advanced GUI's.

posted 02-08-2007 05:16 PM         

EZGUI 4.0 is definitely different than other tools. It has a great deal of power, but at the core of the product is one key factor: Simplicity!

Any software developer has to make choices. A developer who creates a GUI Designer (and supporting engine) at the level of EZGUI, must make many choices about what features to support, how to impliment them and what coding style to use.

When comparing EZGUI to other products, often people point out feature to feature comparisons.

ie.

EZGUI supports "such and such a control" and so does Designer A and Designer B.

Designer A supports ActiveX controls and EZGUI does not.

What makes EZGUI different is not simply its feature set (albeit it is extensive).

It is the way features are implimented and the coding style it uses that really matters.

Let me explain:

For example it is relatively easy to write some wrappers over many simple API calls or messages. Some controls, like the listview, support an extensive list of messages.

When comparing tools, one may quickly notice that one tool has 50 wrapper functions for many messages. This may seem impressive at first glance. What really matters though is how important such commands are and how often they will be used.

EZGUI was developed in a very straightforward way. I simply asked "what features would a programmer most likely need or use". What ever was most useful, was added first to the engine. What ever was used rarely, likely isn't in the engine or was added last.

I didn't impliment features simply because they were easy to do so. I implimented features because I felt they would be necessary to at least a percentage of my customers (and even to myself).

The EZGUI Visual Designer is itself a 100% EZGUI application. As I improved the designer, I often added new features to the core engine whenever I needed something for the designer. The features added "were obviously useful".

When customers requested features, I determined which requests made the most sense and which would be the most useful to other customers and implimented them.

I had to make a lot of choices, when customers made requests. At times I even implimented the requested feature differently than requested. Why?

Because I took into consideration all of the other users of the product. I took into consideration how the feature effected the rest of the GUI engine. I took into consideration how similiar commands were already implimented and strove for consistancy among the command set.

In the long run, as EZGUI became larger and more complex, I strove to keep the engine consistant, simple and easy to use. Complex features would not be allowed to overly complicate the product.

If a feature, by its nature, was overly complex, I chose to impliment it at a very high level. It was better to have the programmer call one or just a few commands and then let the engine handle most of the task, instead of requiring the programmer to handle too many things per task.

This is why, for example, the ToolBar control is implimented via a single command. There was more involved than just creating the control. The buttons had to be defined. A Bitmap or ImageList had to be defined. Text had to be added to the buttons. EZGUI's toolbar command is very high level, yet still very simple to use.

As the developer I had to make choices of when to make something low level or high level. I would ask the question, "If I made this high level, would the average user be happy with it or would they likely seek lower level access to the feature"?

Another aspect of the need for simplicity, is "house keeping". Often a programmer thinks in terms of accomplishing a task and not the need to clean up afterwards. To illustrate:

Some people love to cook, but they often hate to clean up afterwards.

Programming is similiar!

This is one reason the BASIC programming language became so popular. While other languages bogged the programmer down with memory allocation for data blocks (especially strings), BASIC did much of the house keeping for you. You simply defined your variables and then moved on to coding. You didn't have to worry about any house cleaning afterwards.

The Windows API is also strapped down with lots of mundane "house keeping". If You create a Bitmap, remember to delete it later. If you create a Font or Brush, remember to delete it later. If you select a Brush or Pen into a DC, make sure you restore the DC to its previous state when done.

EZGUI was designed so you have to do as little house keeping as possible. If you load a Bitmap or create a color (internally a Pen or Brush), EZGUI tracks it and frees it when the app terminates. No need to remember this! When drawing, EZGUI handles all of the selection of objects into DC's and restores the state afterwards. The programmer can concentrate on drawing, rather than house cleaning.

EZGUI's event model is also based on the need for simplicity. A control (or form) gets most of its events routed through the same procedure (unless the Designer generated code parses it out to a separate procedure because the designer handles all of the coding for you or if the processing of such an event would likely require a lot of coding, so a separate procedure would only make sense).

How does EZGUI do this?

Most events don't require a lot of passed parameters. EZGUI passes the following parameters for all events:

Form$ - parent form name
CID& - controls ID number
CMsg& - event value (an EZGUI event constantis passed)
CVal& - a single parameter passed for the event
Cancel& - a return variable to Cancel the default processing of the event

Thats it!

No other parameters!

How is this possible?

Conceivably EZGUI can pass all of a controls events to a single procedure using this syntax. This makes it easy to track all of the action occuring with a control, since all of its event occur in a single procedure.

Most events that occur never need more than one parameter passed.

In the few instances where more than one parameter needs to be passed, EZGUI does one of two things:

(1) Combines two 16 bit values into one 32 bit value (ie. mouse coordinates) and then offers easy to use functions to parse them out.

(2) Passes a pointer to a complex structure and then gives you a function to read that pointer and parse out all of the parameters.

ie.

code:

SUB Form1_Listview1_Events(CID&, CMsg&, CVal&, Cancel&)
    SELECT CASE CMsg&
         CASE %EZ_NoCustomDraw
              Cancel&=1
         CASE %EZ_CustomDraw
              LOCAL SI&, I&, TmpI&
              I&=EZ_GetCDrawItem(CVal&, SI&)
              TmpI&=I& MOD 4
              SELECT CASE TmpI&
                  CASE 0
                      EZ_SetCDrawItem CVal&, 6, 0,15
                  CASE 1
                      EZ_SetCDrawItem CVal&, 7, 0,27
                  CASE 2
                      EZ_SetCDrawItem CVal&, 8, 0,26
                  CASE ELSE
                      EZ_SetCDrawItem CVal&, 9, 0,25
              END SELECT
         CASE ELSE
    END SELECT
END SUB

Notice how a number of the commands/functions above pass the CVal& parameter of the event. This allows EZGUI to pass internal pointers to structures without the programmer having to work with actual pointers themself.

Only a few advanced events require using this technique. Most only need to pass one value.

EZGUI allows you to more easily track events for controls so it is easier to code.

While some new users of EZGUI at first may find the syntax of EZGUI different (which takes a little getting used too), they soon find that it all makes sense and that there are very good reasons why EZGUI does things the way it does.

Productivity is based on many different factors, often some not fully appreciated at first. EZGUI was designed not only to be easy to code with, but also to be easy to read so maintaining software is much easier. Software has less bugs in it, because the code is more readable. Because EZGUI does so much house keeping for you, you don't read (in the forums) about EZGUI users having trouble locating resource leaks. Most EZGUI apps don't ever get into this problem.

If you develop commercial software:

How much is your time worth?

How much time do you spend debugging your software?

How reliable has your software been?

Can you go back a maintain software you wrote last year?

Have you been able to impliment those advanced GUI features you always wanted?

There is more to EZGUI 4.0 than meets the eye!

The investment is small in comparison to the benefits!

EZGUI was developed by a programmer who appreciates that "time is money" (as they say), who appreciates what is involved in writing custom software, who appreciates the importances of "getting the task done, without worrying about the details or mundane house keeping", who appreciates "what features" are necessary and what are not.

Please seriously consider EZGUI 4.0 if you are looking for a better way to write Windows applications.

posted 02-19-2007 11:49 AM         

Answer: The Standard version is really only for a select group who can live with less features.

I am currently working on a lower priced standard version of EZGUI 4.0 which may appeal to some.

You may wonder if that would be better suited to your needs, than EZGUI 4.0 Pro.

The Standard version (if released) would be a stripped down version of EZGUI 4.0. I have already removed a significant number of features from it so far and I don't know exactly what features it will finally support yet. The real question is, will it be suited to your needs?

If you are developing software professionally, I would strongly recommend the current Pro version since it will support all of the advanced features of EZGUI and would produce the most advanced GUI's possible with an EZGUI product.

Then what purpose would a Standard version serve?

There are PB users who program as a hobby or they are students. The Standard version would be more suited to them and at a lower price they can afford. Also some professional programmers don't need very sophisticated GUI's for their software, so the Standard version may offer them all the features they need. Another use for the Standard version will be for those who want a much smaller runtime. Currently EZGUI 4.0 Pro has a 515 KB runtime DLL and a some small supporting DLL's for some custom controls which range in the 20KB to 50KB range. The Standard version won't have any external custom custom controls and the main runtime DLL will be much smaller. Currently it is 322 KB in size, but the final version may be smaller than this. I am trying to make this runtime as "lean" as possible, while still offering a wide range of features. Some programmers just like to write small utility type programs and the standard version would be better suited to that.

But if you plan to write commercial level software with a complex or large GUI (many forms with many advanced controls), then the Pro version is what you really need.

As I finalize the feature set of the Standard version I will be able to post more info on what features it supports and how it compares to the Pro version.

posted 02-22-2007 04:22 PM         

Click here for an overview of EZGUI 4.0 Pro with some good pictures.

http://cwsof.com/details/ezgui40.htm

If you click on the ScreenShots link on the above page, you can also see some good screenshots of the Visual Designer.

posted 03-23-2007 12:39 AM         

First let me say that the custom controls offered by other tools are great and I in no way want to knock them.

One may ask though, what makes the custom controls with EZGUI 4.0 different?

There are a lot of controls one could create to add functionality to a GUI engine. What would programmers need?

I made some decisions about the custom controls to add to EZGUI based on the premise that general functionality outweighed overly specific controls, especially ones which only slightly improve the interface. Each generation of applications (especially from MS), add new controls which are great, but they only slightly improve upon already existing controls like Toolbars, Tab controls, rebars, Pagers, etc.

If you can impliment a similiar thing using an already existing control, then a custom control adds little more to your interface.

For example, MS has a variety of interfaces that really are no more than fancy versions of existing controls like Toolbars, Tab controls, Rebars, Pagers, etc. True, they are fancier and offer a few bells and whistles, but they don't significantly add to the functionality of an app.

The custom controls I added to EZGUI were chosen because they added significant features to the interface, that were not easily implimented some other way.

The first control I added was the Masked Edit control.

This is very useful for building interfaces which require fixed data inputs. This is not easily implimented using existing controls, so it adds significant functionality.

Next I added an MCI control. True MCI APIs' already exist in Windows, but they often are not easily understood. Also at times MCI requires a handler window, for such things as video. Since video, audio and MIDI are important multimedia features, any GUI engine should have some support for them. I chose MCI because it is quite universal, easier to work with and allows expansion. I also added an EZ macro command set to the control so you don't even have to know the MCI lingo. It is easy to add video, audio or MIDI to your app. Since there is no native MCI control, it only made sense to create one.

The next custom control I added is the Turtle Graphics control. It helped that I had already developed this engine even before I wrote EZGUI, but it was not originally a standalone control. I had to convert it to a true custom control.Turtle Graphics have the advantage of being vector based, rather than raster based. This means that you can autoscale any Turtle graphic image to any size. Also it allows you to create graphics with very little overhead (no stored bitmaps). Vector based graphics are a powerful tool which allows you to build all sorts of applications (CAD like apps). EZGUI's Turtle Graphics even supports some animation features, where the turtle coordinates can be automoved based on animation parameters.

The next custom control is the Shape/HotSpot control. This seems awfully rudimentary, but amazingly there is no native shape control in Windows. The Shape control can be a rectangle, ellipse or line and also can have a transparent background. The control can also act as a hotspot, which is not visible, but still responds to mouse clicks. You can put hotspots on top of say a Bitmap image (which is another control) so the user can click areas of the image and get feedback from the user.

The next custom control is the Property Listbox control. While many applications have such an interface, there is no easy way to impliment this using native controls. It only made sense to add such a control to EZGUI. Property Listboxes are very useful for building complex GUI interfaces.

I also added a Files Listbox control. Again this is an often needed control, but is not easy implimented using native controls.

The most valuable custom control in EZGUI 4.0 is the Canvas control. This is no simple image control. It is a powerful graphic control which comes with a complete graphics engine for drawing. It supports double buffers, DIB sections, scrolling and the new Sprite engine adds an advanced mechanisn for animation including anti-aliasing and alphablending. The beauty of this control is that it serves hundreds of purposes. Windows is graphic by nature and often the only way to communicate properly with the user is through visual pictures. The Canvas control allows you the ability to do almost anything you wish visually. If you can draw it, it can be done with the Canvas control. You can buy a third party graphic tool for use with your apps, but EZGUI comes with it built in. It is integrated with the entire GUI engine.

One more custom control, which you don't see every day is the drag handle control. This control, integrated into EZGUI's subclassing engine (drag and drop) allows you to build visual drag and drop type applications with real drag handles. EZGUI's own Visual Designer is itself a 100% EZGUI application. Its drag and drop features depend upon the drag handle control. It is also easy to use and does most of the hard work for you. No other GUI tool for Powerbasic has such a control. It allows you to develop a true WYSIWYG style application.

Lastly, I should mention the built in Ownerdraw engine in EZGUI, including its simplified command set. At times you may wish you had a control, like an existing control (ie. listbox), but you wished it looked a little bit different. With EZGUI's ownerdraw engine it is easy to create your own custom looking controls. This engine is so powerful, that I actually used it to create two of the custom controls in EZGUI 4.0 , the Property Listbox and Files Listbox controls (the visual part anyway). I also use this engine to create customized listboxes in the Visual Designer, which display icons next to items and checkboxes in another.

The core concept of EZGUI's custom controls (and ownerdraw engine) is to allow programmers to expand their interface beyond what can be done with native controls. You might say, I want to let programmers unleash their imagination when it comes to user interfaces.

The custom controls in EZGUI were added for very good reasons and they significantly add to your interfaces.

See some screenshots of EZGUI's custom controls (and ownerdraw features) here:
http://cwsof.com/details/ezgui40.htm