EZGUI - a GUI framework for PowerBasic
Yes, EZGUI is actually a GUI framework for use with PowerBasic.
I often use the term GUI engine, but that does not do it justice.
EZGUI is a GUI framework, no other way to put it. It puts power features into the hands of everyday programmers.
EZGUI is not a Visual Designer !
EZGUI comes with a Visual Designer, which was developed using EZGUI and it is a 100% EZGUI application. There is no other tool for use with PowerBasic that gives you the ability to build a full blown drag and drop visual designer without a single line of API code.
Now for hobby programmers and those on a tight budget, I am continuing the special offer on the previous version of EZGUI, which is version 4.0 and bundling with it my commercial DDT designer, so you can build apps using the EZGUI framework or build utilities using pure DDT and no runtimes. EZGUI 4.0 Pro originally sold for $249, but you can buy it now for only $39. Now that is a deal.
Now for professional programmers who want the latest and best when it comes to EZGUI, EZGUI 5.0 sells for $249 (4.0 users can upgrade for $159, so why not buy the 4.0 now and upgrade later and save).
So what does EZGUI 5.0 have that 4.0 does not ?
For those who use the Visual Designer, the improvements in the Designer alone are worth it.
Here is what is new in the Designer:
Here is what is new in the runtime:
Developer of "EZGUI"
Last edited by Chris Boss; Apr 8th, 2012 at 08:42 AM.
It appears that some may take issue with my use of the term "GUI Framework" when it comes to EZGUI.
The concept of a GUI framework is to act as a middle man between the operating system and ones application, so the application need not directly access the operating system for its UI features.
That is exactly the concept behind EZGUI. The majority of users can write large complex apps without any API calls at all (while still allowing integration with the API in the rare cases EZGUI can not so something).
Over the years some have equated EZGUI with terms like API wrappers. I can definitely say that EZGUI is not simply a set of API wrappers, nor is it just a new window class.
EZGUI is a GUI framework !
The entire set of runtime DLL's now amounts to about 1 megabyte and thats a lot of code for something written in PowerBasic. The main runtime is 700 KB in size and it has been designed with a significant amount of modularity, so that a lot of funtionality is reused by the runtime itself. EZGUI builds upon itself.
Let me provide an example:
Early versions of EZGUI implimented a graphics engine and ownerdraw. In EZGUI 4.0 when I decided to add two new custom controls, rather than build them from scratch, I simply superclassed a window class which already existed which supported ownerdraw and then used EZGUI's own ownerdraw engine to handle the drawing of the controls. By doing this I was able to impliment both the Files Listbox and Property Listbox controls with a minimal amount of code.
In EZGUI 5.0, I again superclassed my own Canvas control and then built upon it the new glCanvas control and then added the 3D scripting language (OpenGL) to it.
Believe it or not, it is this modular design of EZGUI and its internal reuse of its own code, which has made it difficult to convert it into an SLL. Right now, the entire library would have to be one SLL if I were to convert (which is why this will take some time) it. It is because it is not simply a set of wrappers, like some may suggest (which would be easy to convert to a modular SLL), but a GUI engine which is deeply integrated.
The idea behind EZGUI is that one can build extremely complex UI's with ever resorting to the Windows API.
Let's look at one example of how extensive EZGUI is.
I don't believe there is a single UI development tool for PowerBasic, which could be used to build a complete drag and drop Visual Designer without using a single line of API code (or that provides a complete library of its own to do so). Yet with EZGUI, its own UI library is so extensive that one could build a complete drag and drop visual designer style application and never once have to call the Windows API.
Now a GUI framework needs to be high level and low level. That is exactly what EZGUI is. It has many high level features, yet it has many of the low level features required to custom design things , which are not easily done even using the Windows API.
For example, EZGUI's canvas control has a supporting graphics engine, but it also has a very high level 2D Sprite animation engine. When the average PB'er is struggling to accomplish sprite drawing using things like GET/SET bits, XOR drawing or even TransparentBlt (see forums for examples), EZGUI has its own DIB based, high speed proprietary 2D Sprite engine, which does more than simply draw the sprites, but it can do frame animation, alphabllend sprites (to background and each other) and even anti-alias. EZGUI even impliments "dirty rectangles" for even faster update speeds.
This is why I keep trying to highlight that EZGUI is not a Visual Designer and should not be compared to other tools which are primarily designers. Yes, EZGUI has its own Designer, but that is because it is a unique GUI engine or framework, which requires its own Visual Designer. You just couldn't use another design tool with EZGUI, because it uses a different UI engine (not the Windows API or DDT).
This is why when potential customers consider EZGUI and they concentrate on the Designer aspects, but have a preference for either DDT or SDK style coding, I discourage them from buying EZGUI. It is not a Designer !
If someone is interested in EZGUI, it is important to look at it from the perspective of it being a GUI engine or GUI framework. Just like C programmers have to make different choices when they decide to use MFC or ATL, rather than the pure API, so too with Powerbasic and EZGUI. EZGUI is a replacement, so to speak, for using the Windows API or DDT.
By viewing EZGUI as what it really is, a GUI framework, then one will be in a better position to determine whether it is for you or not. Don't want a different framework than DDT or the API ? Then don't buy EZGUI, simply put.
EZGUI is not for everyone !
The majority of PowerBasic users will not be EZGUI users. EZGUI is not some kind of addon which can be used on top of what you currently may use (ie. DDT). EZGUI requires a mindset geared towards its own unique UI framework.
If you are just looking for another Visual Designer, then EZGUI is not for you.
If you think EZGUI is a DDT Visual Designer then EZGUI is not for you (even though I have produced some freeware DDT designers built using EZGUI).
If you think you can build your app using another Designer and then simply use EZGUI to add features to your app, then EZGUI is not for you.
EZGUI is a GUI framework, with its own ways of doing things. It has its own event engine, totally different than what is done with other design tools for use with PowerBasic.
You normally won't be writing dialog procedures or window procedures with EZGUI (although it does allow this for advanced users who require integrating some API code with the EZGUI framework).
You won't be writing control callbacks or message crackers with EZGUI.
EZGUI has its own event engine, which works totally different. I handles all the internal API stuff (like message cracking) and converts it into easy to use events. It does a significant amount of preprocessing of notification messages and converts them into a consistant set of easy to work with events.
EZGUI is a GUI engine !
EZGUI is a GUI framework, unlike anything else one may have used with PowerBasic.
So is EZGUI better than other ways of programming using PowerBasic ?
In the same way that with C++, some programmers find MFC easier to use, while others prefer the pure Windows API, while others forgo both and prefer a managed code style (ie. C#), the same is true with PowerBasic. There are DDT programmers. There are SDK programmers. There are programmers who prefer a specific Visual Designer and then there are EZGUI programmers. Each has its own strengths and weakness, so it would not be fair to compare them (apples to oranges as they say).
To be happy with a tool like EZGUI, requires a totally different mindset and that one appreciate what it really is. If you ask my long time customers, what really makes EZGUI powerful, they will usually say its the runtime, the GUI engine. The Designer is only "icing on the cake". It is not the cake though.
So does EZGUI really have so many features that one could call it a GUI engine or a GUI framework ?
Aside from forms (dialogs), all the standard controls and the common controls, EZGUI has its own event engine, a graphic engine, low level graphic engines (ie. draw directly into window DC's), subclassing engine, thread engine, drag and drop engine (WYSIWYG), print engine and more. It has its own custom controls designed to solve a variety of common tasks most programmers may eventually require.
- masked edit control
- shape/hotspot/splitterbar control (splitterbar only in 5.0)
- turtle graphics control
- MCI control
- 3D button controls (ownerdraw)
- drag handle control
- canvas control
- glcanvas control (only in 5.0)
- files listbox control
- property listbox control
Many of these custom controls could have been designed to stand on their own and be sold separately and would be worth a good penny, but they are all part of the EZGUI framework. Because EZGUI is so integrated, the canvas control, drag handle control, glcanvas control, files listbox control and property listbox control currently can not be separated because they depend upon being part of the entire framework to run.
It also should be noted that EZGUI is not a "mishmash" of open source projects thrown together to make a large whole. EZGUI is not made up of any third party controls or code from other sources. I have personally written every line of code in EZGUI, after years of research into the Windows API. It is the product of 10 years of development and now in its 5th generation. For example, I don't use any opensource code in my 3D graphic engine. I wrote from scratch the entire 3D opengl scripting language and built it into a custom window class of my own design. I did not use any open source code in my 2D sprite engine, but again it is a proprietary graphic engine.
Lastly, on the note of comparing EZGUI to other Visual Designers, all I can say is "don't". EZGUI is not a Visual Designer (even though it has its own).
EZGUI is more than simply a visual designer.
With things like 2D sprite animation, openGL 3D, 22 image filters, DIB engines, advanced image rotation, ownerdraw graphics, ten different custom controls, etc., does that sound like a Visual Designer to you ?
Now it sounds more like a GUI engine or GUI framework.
And that is what EZGUI really is.
Developer of "EZGUI"
Last edited by Chris Boss; Apr 9th, 2012 at 10:07 AM.
I've never been able to get my head around DDT, callbacks and the Windows API because I'm more accustomed to event-driven programming such as Delphi, Lazarus et al. You know the sort of thing: put a control on a form (such as a button) and then use the "On-Click" event to do something. Is this the sort of thing you mean by event engine. I've always found it much easier and quicker to use events than to mess around with callbacks and the like. Is the way that EZGUI works, if so, it could be exactly what I've been looking for.
While the Windows API is so extensive, it would not be possible to create a GUI engine or framework which completely replaces the API. That said, I have found that most programmers only use a small portion of the features found in the Windows API. So if one could build a GUI engine which handles the most common tasks, even advanced ones, then one could possibly have an engine which can nearly eliminate the need to use the Windows API.
Now of course it is important to make sure such an engine allows one to integrate API code in the rare cases when it would be needed.
EZGUI approachs this idea by using a runtime which has the responsiblity to handle all the communication with the Windows API for you, while providing easier ways to do things.
Normally when a PB app starts up, the app starts in the WinMain (or PBMain) function. An application created with EZGUI immediately passes all control to the EZGUI runtime, so it handles the WinMain stuff and it has its own internal message loop. When EZGUI is started up, three addresses to three required subroutines all EZGUI applications must have are passes to the engine.
which is where you can write your own startup code.
which is called when ever a form is created (occurs during a forms WM_CREATE message) so one can add controls to the form before the form becomes visible.
where EZGUI sends event for all forms and all controls, where they are parsed out to each form and control.
Normally with DDT or SDK style programming you write a dialog procedure/window procedure and you then process a number of notication messages or with DDT you alternately can let DDT forward the WM_COMMAND/WM_NOTIFY messages to control callbacks (which is basically simply a form of message cracking done by the compiler).
EZGUI does not simply forward API messages, because this requires a knowledge of each message and many times extra processing using the API.
EZGUI preprocesses messages and then converts them into easy to handle events. The preprocessing is the important part. Some preprocessing is simple, but others are may be quite complex. The point is that an event should provide the programmer with what they need to handle it, without having to resort to API code to handle it.
The first thing which causes confusion with Windows programming is that each control class has its own constants for a notification which may be the same thing. Why does a button control have the BN_CLICKED notification and the static control (which will encompass the label, image controls in DDT) the STN_CLICKED notification and common controls NM_CLICK ? EZGUI converts all these notications to a simple %EZ_Click event no matter what control type generated it. Now this may not seem like a big deal, but it makes code more readable and easier for the programmer to remember.
Now the click event is a simple one, but there are events which do much more complex preprocessing. For example a number of controls are similiar in their purpose, but simply do it in a slightly different way. The scrollbar, trackbar and updown (spinner) control all basicly do something similiar. EZGUI preprocesses their notification messages and then simply generates the same event for call called %EZ_Change and then passes the current scroll position of the control. There is not need to process the WM_HSCROLL/WM_VSCROLL messages or the like because EZGUI does this for you, so you simply get an event which tells you the control has changed its position and what new position is.
There are even more examples of very complex preprocessing. The point is that why should the programmer have to write code for each control for common tasks, which the GUI engine could handle for you.
So what does an EZGUI event routine look like ?
A control can have all of its events processed in a single subroutine, so there is no need for multiple functions as if one function is needed for each event (too much code). EZGUI is also generating events for controls for many different API messages, not just WM_COMMAND or WM_NOTIFY. For example event subclassing can be done and a simple %EZ_SubClass event can be sent to the same subroutine if you prefer.
Let's see how this decreases code size and also makes code easier to read an maintain.
Here is some event code from an ownerdrawn combobox control:
SUB TBAR2_FONTCOLORS_Events( MyID&, CMsg&, CVal&, Cancel&) SELECT CASE CMsg& CASE %EZ_Change ChangeFontEffect 6, CVal& CASE %EZ_OwnerDraw EZ_DrawComboBox "TBAR2", MyID&, CVal&, 4, 0, "C" CASE %EZ_OwnerSize EZ_SizeComboBox CVal&, 4 CASE %EZ_Loading FillFontColors EZ_SubClass 2 CASE %EZ_Loaded EZ_SubClass 0 CASE %EZ_EraseBG Cancel&=1 CASE ELSE END SELECT END SUB
EZGUI's event engine significantly decreases code size, because it preprocesses a lot of stuff for you, improves code readability and speeds of development time because you have less to code, but can do more.
Developer of "EZGUI"
This is just a simple explanation of the event engine, but EZGUI's event engine is very complex and extensive.
Here is the current event list for EZGUI 5.0:
Not every event is for every control or form type of course and many events are for advanced features such as the drag and drop engine. The point is that EZGUI does a signficant amount of message processing and event generation.
Developer of "EZGUI"
EZGUI also uses a unique way of passing parameters for events.
The CMsg& parameter contains the event value so you can see what event it is (see list above).
The CVal& parameter contains a single value passed associated with the event.
The Cancel& parameter allows you to pass back a value to cancel default processing.
In most cases, EZGUI does so much preprocessing for you, it only needs to send one value back to your app in CVal&. For example with a scrollbar, in the %EZ_Change event CVal& contains the scrollbars current position.
In some cases a good bit of data needs to be passed to the event, so what EZGUI does is simply uses CVal& as a pointer to structure. The EZGUI runtime also will provide a simple command which can be called to retrieve all the data of the structure, so normally you don't even need to define the structure at all.
In some cases, EZGUI provides a single command which can be used to do some high level action, and all you need to do is pass the CVal& parameter on to that command and the structure data is passed to the high level command and you never have to worry about structures at all.
This is how EZGUI handles ownerdraw for example, so lets' take a look.
Here is an example where an owndraw listbox control is being drawn using the EZGUI simplified command set, so notice how you simply pass on the CVal& parameter to these commands and all the data contained in that pointer value is handled by EZGUI:
SUB DMAIN_LISTBOX1_Events( MyID&, CMsg&, CVal&, Cancel&) SELECT CASE CMsg& CASE %EZ_Change CASE %EZ_OwnerSize EZ_SizeListBox CVal&,6 CASE %EZ_OwnerDraw EZ_DrawListBox "DMain", MyID&, CVal&, 6, 0, "BW7X+-G" CASE ELSE END SELECT END SUB
Now in some cases you may need to do some low level drawing and the CVal& parameter can be passed on to commands to retrieve the data so you can use it.
Here is an example of drawing a control using customdraw and you can see that the CVal& parameter, while containing a pointer, never needs to be accessed via the pointer directly using a structure. Commands are provided for handling the data:
SUB DMAIN_CDLISTVIEW_Events( MyID&, CMsg&, CVal&, Cancel&) SELECT CASE CMsg& CASE %EZ_Selected CASE %EZ_NoCustomDraw Cancel&=1 ' force custom draw CASE %EZ_CustomDraw LOCAL I&, SI&, T$ I&=EZ_GetCDrawItem(CVal&, SI&) SELECT CASE SI& CASE 0 EZ_SetCDrawItem CVal&, 90, 0,15 CASE 1 EZ_SetCDrawItem CVal&, 91, 2,26 CASE 2 T$=EZ_GetLVItemText("DMain", MyID&, I&,SI&) IF T$="In Stock" THEN EZ_SetCDrawItem CVal&, 92, 1,15 ELSE EZ_SetCDrawItem CVal&, 93, 4,28 END IF CASE ELSE EZ_SetCDrawItem CVal&, 90, 0,-1 END SELECT CASE ELSE END SELECT END SUB
So a very simple event subroutine syntax with minimal parameters can handle unlimited types of events and their data from the simple to the complex.
Developer of "EZGUI"
The key to EZGUI is code reusability !
If you write a small app, then likely the EXE and runtimes combined will be much larger than what you can do with DDT or the SDK.
But if you write very large apps, because EZGUI has so many features the code you write is much, much less and at some point an EZGUI app (EXE) and the runtime combined will be significally smaller than its DDT/SDL counterpart would be.
Also it takes time to write code. EZGUI is designed so you can accomplish more using significantly less code. Even with tasks which are not overly complex using the API, EZGUI still beats it in code size.
For example, check the forums for code for processing the WM_HSCROLL (or WM_VSCROLL) messages for scrollbars. Now look at it is done with EZGUI:
SUB MYSCROLLBAR_Events(CID&, CMsg&, CVal&, Cancel&) SELECT CASE CMsg& CASE %EZ_Change ' the value of CVal& contains the current position of the scrollbar END SELECT END SUB
Nearly no code required at all.
Imagine how much this saves you in coding when it comes to the complex stuff !
For example, EZGUI has a drag and drop engine. One feature is the ability to handle implimenting drag icons in a listview or treeview control. Internally EZGUI uses nearly 600 lines of code to impliment this feature and it can handle dragging items from one control to another, within the control itself and even dragging items to other forms. The event code to accomplish this only requires just a few lines of code, but EZGUI uses about 600 lines of code internally to handle this.
Developer of "EZGUI"
Another point to note about code reusability is how EZGUI is integrated even within itself.
Most code libraries are written as a bunch of stand alone routines. You can easily remove specific routines and leave the others without any damage to those routines.
Not so with EZGUI !
EZGUI is an engine, a framework.
It depends upon itself. It calls itself a great deal and it builds higher level features based on many of its own internal low level features. It reuses its own code to build higher level stuff.
This is why one could never attempt to emulate all that EZGUI does by writing a bunch of API wrappers. EZGUI is not a bunch of wrappers over the API. It is an engine. It is a GUI framework. It needs itself.
Because of this internal reuse of code and internal dependence upon itself, the feature set of EZGUI is huge compared to the actual size of the entire runtime.
Now some critics of EZGUI may simply view it as just a bunch of API wrappers, which they may feel they could easily do the same thing, but what they may fail to appreciate is the GUI engine/framework nature of EZGUI.
Now, if one simply attempted to do some of the same things EZGUI does by writing a bunch of API wrappers, consider this:
How much code would it take you to impliment event just a few of the advanced features in EZGUI ?
How much code does it take you to write just a property listbox control alone ?
How much code would it take you to build the basic drag and drop features of a visual designer ?
How much code would it take you to impliment a 2D sprite engine, which does frame animation, image flipping, collision detection, alphablending and anti-aliasing ?
How much code would it take you to impliment not only OpenGL drawing, but a complete OpenGL 3D scripting language with parser, STL 3D file format loading and saving and then embed all this functionality into a real custom control ?
How much code would it take you to build a variety of ownerdraw controls with complex a look and feel ?
How much code would it take you to add theme drawing to such ownerdraw ?
Now this does not even scratch the surface of all the features in EZGUI, but the point is that if one were to attempt to write all these things as a bunch of stand alone wrappers or libraries, likely the size would be much, much larger than with EZGUI. Why ?
Because EZGUI builds upon itself. It depends upon itself.
EZGUI is a true GUI engine, a GUI framework, unlike anything else available for Powerbasic.
Developer of "EZGUI"
If you would like to see how any EZGUI application actually looks, I posted the source code to my freeware 3D model viewer program on my web site.
You can download the actual 3D model viewer program here:
You can download the source code here:
You won't be able to recompile the source code, because it does not contain the PBR file with resources or the EZGUI include files.
Now remember, this is just a freeware app which I basically threw together in a short time to demonstrate EZGUI's 3D custom control. It is not a commercial application.
Now try to build even this simple application using the Windows API and see how much code it takes to write it.
Amazingly, this app will run on Windows 95 to Windows 8 (as long as the proper OpenGL video drivers are installed).
Developer of "EZGUI"
The $39 sale for the previous version of EZGUI (4.0 Professional) still continues and will be available for a limited time. It can end any time , so don't let it pass by.
EZGUI is a unique GUI engine, which will allow you to build very complex applications.
So why use EZGUI ?
Aside from ease of use, EZGUI also provides a programmer will many features not easily done using the Windows API (or DDT). EZGUI does the hard stuff for you. It also makes common tasks just easier to do.
EZGUI 4.0 can do:
- MDI (Multiple Document Interfaces)
You don't have to call any MDI API's either. Just add a property to both the MDI parent and the MDI children forms and you have a fully functional MDI application.
EZGUI goes beyond the PB command set when it comes to threads. It has both a low level and a high level (simplified) thread engine, which even syncronizes using critical sections. There is an event engine for threads, so you can easily keep the non-UI stuff separate from the UI stuff. All UI tasks should be handles by the primary UI threads, so EZGUI allows you to generate events from within a thread and then to easily pass data to the primary thread where you can then update the UI.
- Game Loop engine
EZGUI provides a game loop engine, embeded into its iternal message loop. Simply turn the game loop on and you get a regular game loop event. It even provides precision time commands so you can calculate frame rates.
- Display Help files
EZGUI 4.0 has commands for loading and displaying both types of help files (.hlp and .chm), so you can use either the old fashioned help files or the more modern HTML help files.
- Clipboard commands
Copy and paste from the clipboard text, rich text or bitmaps
- Unique color/brush commands
EZGUI supports a library of 3D brushes. It comes with a default library of 56 brushes, but you can create your own libraries. Rather than solid colors, 3D brushes have a degree of depth to them.
EZGUI has commands for comparing and averaging colors. The idea is to allow you to blend colors so you can customize the colors you use. For example, you could read in the system colors and then blend them with a common color to produce a unique appearance.
- Customize Common Dialogs
Some may be just happy to be able to display a common dialog or to do something like center it. EZGUI was designed so you can even customize the common dialogs. You can actually change how the look and work, even even embeding child forms into a common dialog.
- Universal control search functions
EZGUI has search functions designed to work with the Listbox, Combobox and Listview controls.
- Debug Window
A dynamic debug window is built into EZGUI. Simply display the debug window and then send text to it using EZ_DPrint and you can improve debugging of an application. One of the big problems with debugging a windows application is that it is event oriented, meaning you don't always know when code will be executed. A debug window helps you see what is happening in real time.
EZGUI's layer engine is unique. As far as I know, no other tool for PowerBasic provides a layer engine like EZGUI does. It is one of the most popular features in EZGUI. Build wizard style dialogs, define tab controls, etc. without the need for multiple child forms/dialogs. Controls can be put on different layers and shown and hidden by layer. EZGUI even calculates complex clipping regions when displaying layers to decrease flicker which showing a layer.
- DIB support
Easily create and work with DIB sections. DIB's (device Independent bitmaps) are superior to normal bitmaps. For one, you can access the pixel data directly without having to get/set blocks of pixels. DIB's can be huge. Windows has a limit for the size of a normal bitmap (40 meg I believe), while DIB's can be huge.
- Custom Controls
EZGUI's custom controls are far more useful, because they were designed for more common tasks and can be customized. The Canvas and Turtle Graphic controls are for graphic tasks. The property listbox and Files listbox controls are important, common use controls, not easily created yourself using the API, but yet extremely useful for many UI's. The MCI control has its own EZ MCI command set, so you can easily add common multimedia to your apps (videos, CD audio, MP3 and WAVE, MIDI).
The power of EZGUI is its runtime engine !
Do stuff you never thought you would in a Windows app.
Developer of "EZGUI"
EZGUI was designed for a number of reasons.
(1) Faster development time
(2) Ease of use
but one interesting thing about EZGUI has to do with the size of the applications you can build with it. I don't mean the size of the EXE. I mean the size of an application in terms of what it does.
How many PowerBasic programmers would be comfortable in build an app the size of say Adobe Photoshop, Microsoft Office, etc ?
EZGUI really shines when you start building very complex and large (in terms of tasks) applications. Why ?
Code reusability !
Some may laugh when I mention that many API's tasks which would require a dozen lines of code can be done with EZGUI with just one or two lines of code. Actually there are some commands in the EZGUI runtime, which internally are built upon dozens if not hundreds of lines of code. For example the drag and drop command (EZ_StartDrag) for use with the Listview and Treeview controls to do drag and drop icons (to drag items) has nearlly 600 lines of API code internally under the hood. EZGUI can define a full blown toolbar control, with all the buttons, with just one line of code (can't do that with the API).
The point is that the EZGUI runtime reuses code over and over again in a way, which makes the code you have to write significantly less that what you would have when using the Windows API.
This means the more tasks your app has to do, the less code it takes to do it, so you can code faster and it is easier to maintain. Now this may not seem like a big deal if you write small utlity style apps, but imagine trying to write applications the size of Adobe Photoshop or Microsoft Office ? Then the amount of code you actually write does really make a big difference. You can code faster, still have smaller apps in the long run and accomplish more.
EZGUI is not a set of API wrappers. It is a GUI engine, a GUI framework if you will. It is internally integrated. It reuses itself. It is highly modular in design. It is low level and high level. It has features likely not found in any other tool for use with PowerBasic.
For example, its layer engine is very powerful and there currnetly is nothing like it in other tools. EZGUI users find Layers one of their favorite features. Imagine working with Layers, even in the Visual Designer, up to 100 layers total.
EZGUI even has a page form engine. Page forms are child forms embeded in a parent form (like a control), but EZGUI can keep track of them, so when you show one, it hides the others. No need to keep track of dialog handles and lists of child dialogs. Just show one page form and the others are hidden automatically for you.
EZGUI decreases the number of global variables required to track dialogs (forms), because you just don't need them. EZGUI references forms by names (a string). Commands which reference controls and forms, simply pass the name of the form and EZGUI handles figuring out what the handle actually is internally. This decreases code (less variables needed) and improves readability.
EZGUI also provides a unique set of custom controls built in. From 2D Graphics (Canvas control with 2D Sprite engine), to MCI, Files Listbox and Property Listbox controls. Add to this all the customization features built in (ie. ownerdraw), so you can build your own unique controls, you have so many choices.
Now with this special offer on EZGUI 4.0 Pro for only $39, why wait. EZGUI 4.0 Pro originally sold for $249. And if you like 4.0, then you can always upgrade to EZGUI 5.0 Pro and it has even so much more.
Developer of "EZGUI"
Why EZGUI 5.0 ?
EZGUI 5.0 truly is a GUI framework which allows you to build very large a complex applications, which are easy to code and maintain.
What were some of my goals when designing EZGUI, especially version 5.0 ?
(1) Drag and drop design. Laying out the user interface visually was vital. But rather than building a designer which emulates Visual Basic, EZGUI's designer was built to take advantage of the EZGUI runtime and its many features. For example EZGUI comes with a number of its own custom controls and the designer leverages those controls and their features. For example you can load in custom controls you build using the EZGUI custom control engine, into the designer and use them visually. Also the designer supports EZGUI's new autosize engine and you can even test forms in the designer in test mode to see how it works. The Designer also can generate a lot of special code for you, specific to EZGUI itself.
EZGUI designers support the built in layer engine, which you likely won't see in other tool for PowerBasic. Controls can be placed on different layers and they can be shown and hidden in groups based on their layer.
The Designer also has some exciting new features such as the new Visual Bookmark drop down box. Yes, you can actually save any version of a form, while editing it as a bookmark and then select from different versions just by selecting it from a drop down combobox, but you actually see a visual snapshot of the form in the combobox.
(2) The runtime engine is where the real power is !
EZGUI's runtime engine, truly is a GUI framework, the likes of does not exist in any other product for Powerbasic. It is a set of integrated engines built as one entire engine, which does most of the work in your application. The modular design of this engine allows you to build huge applications with an amazing small footprint. If you normally write applications with just a couple of dialogs/forms then you won't appreciate this. But if you build applications with many dozens of forms with thousands of controls, then you will really benefit from this amazing engine. Many parts of the EZGUI runtime engine can do in just one or a few lines of code, what would normally takes dozens, even hundreds of lines of code using the Windows API. As an application gets larger and larger, this engine keeps your app as small as possible.
(3) Graphics, Graphics, Graphics !
When you think of a visual designer you don't normally think of graphics. EZGUI is not a visual designer, but is a GUI engine which comes with its own visual designer. EZGUI has an extensive graphics engine that goes far beyond the simple lines, shaped, text many are used to drawing. It even does 3D graphics using OpenGL ! It has extensive support for working with DIB's too. It even has its own image filters built in, when drawing bitmaps (22 included). Its 2D sprite engine makes 2D animation so easy, you can do stuff most PowerBasic programmers would love to do, but may not be able to. EZGUI does not use the slow GET/SET BITs style animation or XOR animation. It has its own high speed proprietary 2D Sprite engine, which can even do antialiasing and alphablending.
(4) Customization is the key !
Windows actually was very well designed in its ability to allow you to customize controls. The problem is that it is not easy to do and most programmers shy away from it. EZGUI solves this problem by handling all the mundane stuff for you, so you can concentrate on building controls just the way you like. Even its own Canvas control was designed for advanced customization and even low level access to pixel data.
(5) More controls than you know what to do with.
EZGUI comes with a number of its own custom controls, so you have more than just what comes with the Windows API. These custom controls were designed specifically to solve many common problems. Rather than provide a bunch of fancy UI controls which try to emulate something coming from Microsoft, EZGUI provides a number of common sense controls which are all useful for a variety of tasks. For example:
Files Listbox control:
This control is a like a mini explorer window. It is not complex, but it does the job and it uses the system icons so it looks like something from explorer. But it goes further. It even allows you to use your own custom icons for different file extensions, so you can produce something unique to your own needs.
Property Listbox control:
Property Listboxes are a common control type in many apps today, but there is no native property listbox control in Windows. EZGUI provides you with a powerful Property Listbox control which is even customizable.
This control is for more than just displaying a nice graphic. It was designed so you cab build upon it to actually create your own unique controls. Its 2D Sprite engine is not there simply for game builders. It is there so you can do real time animation to create a totally unique control for almost any need you may have. Build a dial control with it. Build a simulation window with it. Build a game with it. The sprite engine is there so you can create all sorts of unique animated controls. The Canvas control can even drawing using its own effect feature, where what you draw can be alphablended onto the image if you like. Sprites can be mini-canvases where you can dynamically draw in a movable sprite. Call it canvases within a canvas.
Everybody needs multimedia today ! EZGUI makes it easy. No need to call the MCI API's. Just use EZGUI's MCI control and it even has its own EZ multimedia scripting language built in. Working with videos, mp3 and audio files, MIDI and even audio CD's is easy.
Turtle Graphics control:
Vector graphics have many advantages. They are scalable. They also take little disk space (or memory if created dynamically). EZGUI's turtle graphic control has its own Turtle Graphic scripting language built in.
Shape/Hot Spot/Splitter bar control:
This control does many jobs. It can draw common shapes (line, rectangle, rounded rectangle, ellipse) and is a real control. It can act as a hot spot control, which basically is invisible, but can be put on top of other controls (ie. a picture control) and even though invisible it responds to mouse clicks so acts as a hot spot. It can also convert itself into a splitter bar control and is even customizable (meaning you can draw how the splitterbar will look).
Drag Handle control:
EZGUI has its own drag and drop engine built in so you can build WYSIWYG style applications, like a Visual Designer. EZGUI's own visual designer is itself a 100% EZGUI application and not a single API call was required in its source code. EZGUI has its own Drag handle control which is part of this engine. Only handful of PowerBasic programmers have been able to master the basics to building a drag and drop visual designer. EZGUI brings this power to everyone, so it is easy to do and without a single line of Windows API code.
My latest achievement is my glCanvas control. This is a hybrid control which gives you all the features of the EZGUI Canvas control, with a 3D scripting language built in on top. OpenGL is not easy for everyone and no OpenGL API code required. Just use the EZGUI 3D scripting language and you have real OpenGL 3D. It even supports industry standard STL 3D file formats, so you can display extremely complex 3D models with thousands, if not hundreds of thousands of polygons. EZGUI can load an STL model with a high polygon count at amazing speeds too.
I compared EZGUI's STL loading to some open source 3D STL model viewers and EZGUI was amazingly fast compared to them. For example I loaded an STL model with half a million triangles (500,000) and it loads in about 2 seconds, even on my 9 year old Windows XP computer.
Gamers who use 3D models really don't deal with such high polygon count models. Much of the power of 3D gaming is done by faking you out, by using low polygon count models with high quality textures (bitmaps) which give the appearance of high quality.
EZGUI was not designed for gaming. It was deisgned for practical business use and its STL 3D Model engine can handle very complex 3D models wigh high polygon counts.
Now even on a low quality video card or onboard GPU, the speed of STL displays are very good. Now imagine what happens when you use a high quality 3D card. EZGUI can even store the STL model into a vector array for even faster drawing by some new OpenGL capable 3D video cards.
(6) Events, events, events.
EZGUI's event engine allows you to have more control of dealing with user input. No need to process window messages like WM_NOTIFY, WM_HSCROLL, WM_COMMAND or others. EZGUI's event engine handles as much of the mundane as possible so you get simple, easy to use, events which make sense. EZGUI does as much preprocessing as possible so the event accomplishes more for you.
For example, the %EZ_Change event occurs for a number of controls and it passes useful info to your event code, so you just respond without any need to poll the control for more info. The scrollbar, updown control and trackbar control all get the %EZ_Change event and the event passes the current position of the control. No need to process a low level window message or to update the control or poll it for its current position. This is all done for you.
EZGUI does as much work for you as possible so you can concentrate of building your application to make it do something, rather than having to write a lot of low level API code just to start a task.
Developer of "EZGUI"