|
Chris Boss
|
 |
« on: July 22, 2009, 09:32:02 AM » |
|
The first thing to understand is that EZGUI 4.0 pro was designed for building quality, advanced Windows software. The EZ in its name, while indicating that it was designed to be as "easy as possible" (which is a task for Windows programming) does not mean that EZGUI is for beginners only. I developed EZGUI so one could write very advanced GUI's. The EZ (Easy) part is because software development needs to be as quick as possible ("time is money" they say) so programmers can get their software "out the door" as fast as possible. EZGUI is not some kind of VB clone. It is neither object oriented. It is based on the EZGUI runtime GUI engine which simplifies the coding process so one does not need to access the Windows API directly. The EZGUI runtime does this for you. Just take a look at a few screenshots of some applications written using EZGUI 4.0 (and 3.0): http://cwsof.com/apps.htmNotice that while some have simple GUI's, others are quite advanced. Here are sme posts on the PB forums where I discuss some of its features: I will post more info about EZGUI 4.0 in this thread ....
|
|
|
|
|
Logged
|
|
|
|
|
Chris Boss
|
 |
« Reply #1 on: July 22, 2009, 09:34:40 AM » |
|
Remember, EZGUI 4.0 Professional is not just another Visual Designer.
It is a full blown GUI engine along with a Visual Front end.
Its those extras, that make a real difference:
- a full blown Print Engine - a full blown Graphics Engine - Animation using Sprite Engine, plus Alpha-Blending - a full blown OwnerDraw customization engine (with graphics to support it) - Custom Controls package (Turtle Graphics, Canvas control with DIB Section support and Sprites, Shape/Hot Spot control, Masked Edit control, Drag Handle control, Files Listbox control, Properties Listbox control) - a full blown Visual Design engine (build your own drag and drop visual designer application)
and lots more ....
This is not just a Visual Designer. It is a complete toolkit for all the most common needs for Windows programming.
The beauty of all of this is that it is easy to use as well. No Windows API knowledge needed. Now this does not mean it is just a beginners tool either.
EZGUI 4.0 Pro does more advanced tasks than probably most PB programmers ever do already. Unless you are one of the few very advanced API programmers, EZGUI probably does a number of advanced things you have never tried before (or can't figure out yet).
If you want an edge in software development, seriously consider EZGUI 4.0 Pro.
EZGUI can do things like:
- Customize the Common Dialogs (add child forms with controls, change the buttons to 3D, process events) - Impliment drag icons for the listview and treeview controls with just a few lines of code - convert Forms (dialogs) to transparent (layered) Windows on Windows XP and Vista - Build extremely advanced GUI's - Create Comboboxes (ownerdraw), which can display Font lists (each item a different font) or Color lists (each item with a different color box). - Display multiple styles of 2D and 3D colored Buttons (built into Designer as well) - Easily create Rebars and Pager controls and place forms on them - Customize Toolbars, including the background, tooltips - Customize the look and style of toolstips for controls like listview, toolbar, treeview, trackbar
Now I can't say enough about the new Sprite Engine. Move non-rectangular objects (images) around the Canvas control. Flip them vertically or horizontally, anti-alias the edges, animated using multiple frames, alphablend them to the background and other sprites
What Visual Designer can do all of this ?
Now if you are really into building graphic orientated applications, EZGUI is for you and it does not require things like DirectX, GDI+, OpenGL. It uses the GDI, DIB Sections and EZGUI's own proprietary Sprite engine. The graphics will work even on Windows 95 (how many graphics packages can offer these features and still run on Windows 95).
EZGUI's command set is extensive covering nearly ever aspect of Windows programming most people will ever need.
In the rare instance you need to do something EZGUI does not provide, EZGUI is designed so you can easily integrate API calls into it, even giving you access to a number of its internal engines (ie. you can hook into its internal window procedure for forms).
|
|
|
|
« Last Edit: July 22, 2009, 09:36:31 AM by Chris Boss »
|
Logged
|
|
|
|
|
Chris Boss
|
 |
« Reply #2 on: July 22, 2009, 09:35:56 AM » |
|
One of the advantages of EZGUI 4.0 Pro is that it is a complete package with many integrated parts.
Building the front end (the forms/controls) of your application is only the first part of the process. Once you have the visual part of your software created, you now need to make it do things. Thats where programming using the Windows API can get complicated.
EZGUI goes beyond this, by providing a number of engines to support your GUI. I designed EZGUI by simply asking myself, "what do most Windows programmers need to be able to do in their applications ?". I then added those features to EZGUI's runtime engine.
For example, most applications need to be able to print to the printer, so I added a complete print engine that is integrated into the GUI engine.
Each control supported has well balanced set of support commands to do the most common tasks. Here is where EZGUI excels. I didn't simply just start writing wrappers for easy to use messages. What I did was ask myself, "what common tasks would most programmers need to do with this control ?". In some instances, a wrapper to a simple message was all that was needed, but in many instances some very complex API routines had to be written. I didn't add routines, simply to bloat the runtime with a huge number of easy to write, but not often used commands. I added commands which are very useful and actually needed.
One example, is the drag and drop engine for the listview and treeview controls. The ability to drag items (an icon actually, your code does the moving of items). The drag icon coding it quite complex and not easy to write. Yet, since I felt it was a necessary feature for these controls, I added this to EZGUI's runtime engine.
Another example, is multimedia. MCI was the best choice here since it was easy to impliment and yet quite versatile. I wrote a custom MCI control. Why not just create simple wrappers for the MCI command API calls ? I felt that the MCI command set was a little time consuming to learn (so something easier was needed) and some may get find it confusing how to handle the client window for things like video.
The solution: Write a custom control which handles much of the hard stuff for you. The MCI custom control handles all the client window tasks for you so displaying video is easy. The control also has its own high level EZ (easy) MCI command set which is easier to use than pure MCI. You don't have to mess with an alias name for objects, etc. You simply pass commands like:
"EZOPENMOVIE |c:\somepath\somemovie.avi|" "EZPLAY"
The most common video, audio, wave and midi tasks are handle easily.
Another example of the design considerations that went into EZGUI 4.0 Pro are the custom controls.
Rather than create a bunch of high level interface controls to try to emulate features in other applications, such as Microsoft apps, I chose a more low level and versatile direction. Rather than simply add a bunch of custom controls with limited use, I added controls which would allow you to expand your GUI's into all sorts of directions. The choices are unlimited.
I did this in two ways:
First, for the common interface controls, rather than create a bunch of custom controls, I allow you to customize many existing controls any way you like. For example, EZGUI has a complete ownerdraw engine for customizing menus, buttons, comboboxes, listboxs, tab control and listview. There is a simplified ownerdraw command set to get started and an advanced lowlevel command set to accomplish unlimited choices. I also added a subclassing engine, which makes it easier to modify how controls work, how they draw their backgrounds, etc. There is a keyboard preprocessing engine which allows you to preprocess keys before a control gets them. And there is a complete graphics engine for any drawing you may need.
Next, I create a number of actual custom controls. Some high level, others more low level.
First is the Canvas control.
This is not simply just a drawing window. It is a sophisticated graphic tool. For example, it automatically can handle double buffers in the current graphic format or in 16,24 or 32 bit DIB sections. When using DIB sections you get direct access to the pixel data. This is not the same as using GET SET pixel buffers, where you have to move the data to a buffer, modify it and then move it back. You get direct access to the pixel data via pointers and you don't have to waste time moving data back and forth. This increases the speed of drawing significantly.
Not only is the Canvas supported by an complete graphics engine, but it has its own Sprite engine which can handle moving around non-rectangular objects (called Sprites) around the Canvas background. The Canvas control integerates your background image with the sprites on it for you, but they are separate in memory. Sprites can also be alphablended to the background and other sprites. They can also be animated using frames.
What Visual Designer has anything like this ? (graphics)
You would have to buy an advanced separate graphics package to get many of these features, but they are integerated into EZGUI.
Some custom controls are quite simple really, but yet they are very useful.
EZGUI adds the shape/hot spot control. The shapes are simple, but the control automatically handles the region generation for the shapes for you. To be truly non-rectangular a control must use a region. The control also can act as a hotspot control, which is basically a non-visible control (background shows through), which accepts mouse clicks. You can overlay a number of hotspot controls over a picture control to create a truly interactive image.
EZGUI provides a Turtle Graphics control with its own drawing macro language. The advantage of this is that the image is not a Bitmap, but is a vector image. Vector images can easily be scaled. They produce very tiny data files (simply write the macro string to a text file). Vector drawing is a powerful tool when used correctly.
On the surface these two controls seem simple, but they allow you to do all sorts of advanced graphics and to build your own unique GUI's.
Another, low level, yet powerful control and engine is the drag handle control (and support drag drop engine). EZGUI not only provides a way to subclass any control you create and add drag and drop (size and move) features to them (via its subclassing/dragdrop engine), but it even provides a unique drag handle control which can be used to impliment real drag handles. The control automatically displays all eight drag handles, handles the icon changes over each drag handle and also can have a buddy control attached to it. You drag the drag handles and the control automatically sizes or moves its buddy control. You can define the size of the drag handles and their colors.
WYSIWYG style applications are quite possible with EZGUI, because of its drag and drop visual designer engines.
What other PB tool offers you this ?
EZGUI also provides a number of advanced features which allow you to build some very complex applications.
One example is the Thread engine.
Oh, I can do that with PB Thread commands you say.
This is different. EZGUI goes one step further.
When using Threads two important factors need to be considered.
One, is dealing with the GUI. EZGUI provides a mechanism so you can keep GUI commands out of your thread code and keep all GUI commands, where they belong in the primary thread (its a long explanation of why this is so).
Second, there needs to be some way to control the syncronization between threads. I chose Critical sections. EZGUI uses critical sections to syncronize all threads and it provides easy to use critical section commands for you to add such support to your thread code (especially necessary with multiple threads).
Threads can easily be abused, so EZGUI provides mechanisms to keep them in check and to work well together.
The point is that EZGUI is more than a Visual Designer/Code Generator.
It is a full blown GUI engine which does all the dirty work for you, so you can concentrate on writing your applications.
|
|
|
|
|
Logged
|
|
|
|
|
Chris Boss
|
 |
« Reply #3 on: July 22, 2009, 09:38:32 AM » |
|
EZGUI 4.0 Professional is quite unique in that it is both a high level and a low level tool.
First, lets look at some of its high level features.
EZGUI provides a number of commands for displaying the Common Dialogs.
It goes a step further in providing mechanisms to gain more control of these dialogs. When EZGUI displays the dialog, it also automatically creates an internal hook procedure for all of the common dialogs (even the browse folder dialog). It then sets up an even processing engine for the dialog, so the controls on the dialog send actual events to your application.
EZGUI doesn't use handles for dialogs (forms). It allows you to define them all using a name (a string) (ie. "Form1"). EZGUI predefines a name for all of the common dialogs.
Here are the names
"{OPENDLG}" - Open File Dialog (Standard Type) "{SAVEDLG}" - Save File Dialog (Standard Type) "{OPENDLGX}" - Open File Dialog (Explorer Type) "{SAVEDLGX}" - Save File Dialog (Explorer Type) "{COLORDLG}" - Color Dialog "{FONTDLG}" - Font Dialog "{PRINTDLG}" - Printer Dialog "{PAGEDLG}" - Page Setup Dialog "{FINDDLG}" - Find/Replace Text Dialog "{BROWSEDLG}" - Browse Folder Dialog
Other EZGUI Dialogs which are not common dialogs, but EZGUI's own special dialogs.
"{MSGBOX}" - Extended Message Box "{ABORTDLG}" - Printer Abort Dialog
The even engine in the EZGUI runtime generates actual events for these Dialogs and their controls, so you can intercept them and add features to the dialogs.
This makes it easier to modify the dialogs, add child forms (with controls), change the dialogs position, etc.
EZGUI even allows you to convert all the buttons on a common dialog to 3D ownerdraw buttons, so you can change the look and style to match the rest of your application.
Much of EZGUI's high level code is in its Event engine. EZGUI does a significant amount of message processing for you in the background. For example, EZGUI knows whether a Form is a MDI Parent Form, a MDI Child Form or a regular Form and automatically handles the proper message loop processing for you. EZGUI does not use the Windows Modal message loop for its own Modal Forms (the common dialogs and messagebox do use the windows modal message loop). Instead it impliments its own Modal message loop. This gives access to processing things in the message loop of modal forms, that normally is not possible with the Windows modal message loop.
Some controls require a lot more setup code than do others and EZGUI adds high level control of this. One example is the Toolbar control. EZGUI has one command which can basically set up nearly the entire toolbar in one line of code, even defining all the buttons.
Obviously stuff like EZGUI's custom controls, Sprite Engine, Visual Design engine, subclassing engine are very high level.
Now as far as low level, EZGUI provides all sorts of low level commands for many different tasks. For example, EZGUI provides a high level simplified ownerdraw command set, it also provides a set of very low level commands for drawing things exactly the way you want them.
While there are a number of high level features in the Canvas control, you can also do some amazing low level stuff using the DIB section buffers. It is easy to impliment low level image filters, using the DIB section engine in EZGUI's canvas control.
Whether you need high level features to develop apps quickly or lwo level features to push your apps to the limit writing your own custom code, EZGUI has it.
The runtime itself has over 600 commands (subs/functions), but the actual features goes way beyond that. Why ?
A number of commands work with more than one control type (ie. search functions) so you are getting much, much more. A few commands (ie. EZ_SetAttr and EZ_GetAttr wrap over 150 different API messages) can do many different functions, like the EZ_DCDraw command, which actually wraps a number of different drawing features into one command.
Add to this, the custom controls and many engines in EZGUI (which do things for you automatically), the feature set is far beyond that of most tools.
|
|
|
|
|
Logged
|
|
|
|
|
Chris Boss
|
 |
« Reply #4 on: July 22, 2009, 09:40:15 AM » |
|
Let me discuss some of the features which are unique to EZGUI 4.0 Professional ( as a Visual Designer/GUI engine tool).
Layers:
The EZGUI Designer has a feature called layers. While the most common use for this is for Tab controls, it is not restricted to Tab controls. It can be used for most anything you want (ie. building wizard style dialogs).
What are layers ?
The Designer supports up to 100 different layers!
When you add controls to a Form, you can select what Layer they will be displayed on. Layer 0 (zero) is considered the background layer and is always displayed. Layers 1 to 99 are secondary layers.
When the form is displayed in your app, controls on layer 0 and 1 are automatically displayed while all the others are hidden from view. The runtime provides a command EZ_DisplayLayer which allows you to show and hide layers at will. The normal way is to display a layer and then all the other layers are automatically hidden, except the one you select to display and the background layer.
Layers allow you to work with just a single form, rather than multiple forms and to show and hide controls in groups. Especially when working with dozens of layers at a time, this is very helpful, since you don't have to have a separate form for each layer. Also it makes it easier to see how the form will actually look during development, since all the controls are on one form and you can show and hide them in the designer to see how each layer looks.
You can also combine layers and display multiple layers together, if you want.
Sprites:
The Canvas control comes with a Sprite engine. The term Sprite dates back to the old home computers of the 80's. A Sprite is a non-rectangular image which is treated separate from the background image (Canvas control) and it can be moved, shown/hidden, flipped and animated (multiple frames). If you were to do this yourself, you would have to not only find a way restore the background behind the sprite every time is was moved, but also a way to draw only certain pixels, since the image is not rectangular (actually it is rectangular, but there are transparent pixels). You also need to do this fast enough so it can run at animation speeds (at least 15 to 30 frame/sec).
EZGUI allows you to define as many sprites as you want and then associate them with a Canvas control. EZGUI handles the merging of the sprites with the Canvas (and each other).
EZGUI goes a step further and even provides anti-aliasing and alphablending. This is all done through EZGUI's own proprietary graphic engine and does not require DirectX, GDI+ or OpenGL.
Now at first glance, you might think "Is EZGUI trying to be a Game engine ?".
Well, EZGUI could be used to create games and I don't rule that out, but the primary use is for building commercial quality applications which require a more graphic orientated look and feel. You can actually create your own unique controls, using the Sprite engine and the Graphics engine. Sprites could be used for overlays on images of maps or something similiar. You could create a unique interface with sprites (yes, you can click on them). They could be used for simulations. The possibilities are endless.
The beauty of EZGUI's Sprite and Graphic engines is they are built into EZGUI (the Designer/GUI engine). You don't have to pay a lot for other tools just to do graphics. Its built in!
OwnerDraw:
EZGUI not only provides a simplified mechanism for handling ownerdraw for menus, buttons, listboxes, comboboxes, listviews and Tab controls (the event itself), but it provides two levels for doing the actual drawing. The first is the Simplified OwnerDraw command set. What other tool offers this ? With just one line of code in an event (%EZ_OwnerDraw) you can draw a customized control or menu.
If you need more, remember EZGUI has a Graphic engine built in, so you can also use a more level approach for drawing the controls. Doing even low level ownerdraw, is as easy as it can get using EZGUI. You don't have to worry the condition of a DC, restoring DC's to their original state or selecting objects in and out of a DC. EZGUI handles all the mundane stuff for you. You simply draw using easy to use graphic commands.
Drag and Drop - Visual Design engine:
EZGUI already has a subclassing engine, but it goes a step further. EZGUI impliments a drag and drop (or Visual Designer) engine, via the subclass engine. You can subclass any control you create, even third party controls (if created using the EZ_ControlEX function which is similiar to CreateWindowEx). They can be subclassed using the Visual Design mode. This allows you to drag the borders of the controls, drag the controls, etc. This allows you to the fancy stuff, like having two controls side by side and being able to drag their edges to change their sizes.
EZGUI also provides a special custom control, called the Drag Handle control for displaying drag handles on controls. This allows you to build actual Visual Designer style applications. You can create real WYSIWYG style applications.
EZGUI's own visual designer, is itself a 100% EZGUI application. I wrote the designer completely using EZGUI and no direct API calls. The runtime handles all the tough stuff.
Non-Rectagular Forms (using Regions):
EZGUI provides a high speed command for generating a region on the fly from a Bitmap (also used as the background for the form) so you can have non-rectangular Forms. This is not just some region code borrowed from the forums, but is a proprietary routine built into EZGUI which uses a very high speed technique which can handle even very complex regions quickly and on the fly. This feature is also built into the Visual Designer, so you can visually test your forms during development to see how they will actually look. There is no need to compile and run the application to see how they look.
The more complex the image is (the more ragged the edges and lots of holes) the slower it is to convert the image to a region. When i first learned how to do this, I found the standard region generating code to be too slow for complex images, so I designed a much faster technique which can handle very complex images very fast.
Not only can use generate a region on the fly for forms, but EZGUI can even do it for the Canvas control and a Turtle Graphics control. This means you can have non-rectangular graphic orientated controls as well.
|
|
|
|
|
Logged
|
|
|
|
|
Chris Boss
|
 |
« Reply #5 on: July 22, 2009, 09:41:15 AM » |
|
One may wonder why I chose the approach of using the Smart Parser, with the EZGUI Pro Designer.
Actually the concept was "customer driven"!
During beta testing, customers discussed how they didn't want an embeded code editor, since it would limit their choices for code editing features. They already had a favorite code editor and didn't want to change.
They asked me to come up with a way to allow them to be able to keep their favorite code editor.
The solution, was the "Smart Parser".
Actually, EZGUI's Smart Parser technology is quite powerful and plenty fast enough for quick development. I like to use it with the PB IDE. A number of my customers prefer to use it with JellyFish.
The Smart Parser also offers a number of ways to protect you from losing code, after changes to the GUI are made. For example, if you delete a control, what happens to its event code ?
Any visual designer that generates code, has to make a decision when a control or form is deleted, about what to do with the no longer needed code.
EZGUI 4.0 Pro's designer does two things.
One it moves the unneeded code, to a section of your source code and surrounds it with compiler directives so it won't compile. This allows you a chance to retrieve the code if something important was in it.
Second, the Designer makes backups of the source code , when ever it has changed it. There are three levels of backups, so you can always go back and find the code in a previous version of the source code.
Yes, this is a different approach, but it works well for my customers. They requested it.
|
|
|
|
|
Logged
|
|
|
|
|
Chris Boss
|
 |
« Reply #6 on: July 22, 2009, 09:42:28 AM » |
|
One aspect of EZGUI 4.0 Pro easily overlooked is its reliability.
As an experienced API programmer, one thing I have found is that when using the Windows API directly one must be very careful to make sure they read the API docs carefully. It doesn't take much to crash windows, if you are not careful. Not that it can't be done, but one must be diligent.
It is easy to have an error in an include file (a type, a constant) which could cause hard to find problems.
EZGUI gives you the benefit of not having to access the API directly, so you don't have as many problems.
I have gone to great lengths to research the API to make sure EZGUI works well on multiple operating systems (95 to Vista), that it knows what operating system it is running on and to make changes accordingly and to only load certain features of later operating systems dynamically (LoadLibrary) so that if an operating system DLL is not there (or the API not there), EZGUI simply ignores it or compensates.
In developing EZGUI I have found a number of quirks in Windows and EZGUI knows how to handle them.
EZGUI also does something, likely not found in many PB Visual tools and that is "parameter error checking".
Did you realize that I could have made EZGUI even smaller in size (the runtime) ?
It is amazing how small the EZGUI runtime is (about 515 KB) for all the features in it. Yet, EZGUI does a significant amount of parameter checking when you make calls to the runtime commands. EZGUI protects you from make dangerous mistakes. Instead of crashing your app, at worst EZGUI may just ignore a parameter or fix it.
Why ?
Passing bad parameters to API calls can be disastrous and difficult to debug. EZGUI protects the programmer from many such dangers when working with the API.
In the Windows API, things like pointers to structures or memory blocks is often used (the nature of C) and when you pass a bad parameter to them, things start going bad quickly.
Another consideration is that at times the API docs themselves are a bit cryptic. It is easy to misread what they say or simply not understand it.
I have done the extra research to fully understand the API's I used in EZGUI, so you don't have to.
The real question is, do my customers find EZGUI reliable ?
Customers have told me they rarely have found EZGUI to be the cause of any of their problems. Most EZGUI users can deal with finding the bugs in their software, since rarely do EZGUI apps crash when the user did something wrong in their code. When an app GPF's it is a little more difficult to debug.
Debugging in an event based program can also be difficult. EZGUI provides its own easy to use debug window (form) so you can add debug code to display data in real time. Simply print to the debug window in key areas of your program to see what is happening and when.
While no software tool can be foolproof, EZGUI is very reliable on multiple platforms.
Another consideration is the API's one chooses to use.
There is often more than one way to accomplish something in the Windows API. The problem is that some API's are more consistant among multiple operating systems (95 to Vista), while others are not.
Remember, that every new version of Windows (and service pack), changes have been made to the API.
Its hard to keep up with these changes to make sure your software runs as expected on all versions of Windows.
Now if you are the type that writes software only for the latest operating system and/or service pack then this may not be of concern to you. But if you write software which you would like to run on Windows ME, 2000, XP, Vista , even 95/98, then EZGUI can be of help.
The API's I used in EZGUI were specifically selected for better compatibility across operating systems.
Where it is absolutely necessary to be OS specific with a certain API, EZGUI tests the OS to see what version it is and then uses the appropriate code for the specific operating system.
The key is, you don't have to worry about all the details of each operating system. In the EZGUI help file, any commands which are unique to a later OS, it is stated what OS it will work on. The nice thing though, is the app will still run on an earlier OS, but it simply won't be able to do the specific task requested, since it is not available. OS specific API's are never called directly in EZGUI. EZGUI always loads those DLL's dynamically, gets the API's address and then calls it using call dword.
When using the API directly, compatibility across platforms is not easy to maintain. If you write your software on an XP system, you may not be aware of problems when it is run on 2000 or ME.
For businesses which write a lot of inhouse software, being able to write software which will work on legacy systems (95/98) is extremely valuable. With todays difficult economy, it makes sense to not waste any resources, including older PC's.
For those who write commercial software they sell, again you get a larger possible customer base if your software will run on multiple platforms. When the software sold by others only runs on XP or Vista and yours will run on 95 to Vista, who do you think can sell more software ?
Backward compatibility with legacy operating systems does not mean EZGUI is limited on the newer OS. EZGUI can do some amazing things on all the operating systems so you can develop state of the art software
|
|
|
|
|
Logged
|
|
|
|
|
Chris Boss
|
 |
« Reply #7 on: July 22, 2009, 09:44:04 AM » |
|
After all is said and done, what is the real test of a programming tool ?Simply put, it is the quality of the software developed using that tool, by its users. While many programmers are hobby programmers, most program for commercial purposes, either inhouse software for a business or software designed for sale to customers. The end user of the software, does not care how the software was written (whether in VB, PB, using the API or not). What they care about is the following: - The speed the software executes - The ease of installation (size makes a difference here) - How well the software does its tasks - The quality of the interface One can debate the value of the Windows API or using tools which shield you from the API, but the bottom line is the end user and what they think of the software. Does EZGUI 4.0 Pro "fit the bill" for a quality development tool ? Definitely and here's why: (1) Speed of developmentEZGUI gets programmers productive quicker, faster than many other methods of programming. It provides an easy to use Visual Designer, but where it shines is the runtimes command set. It offers so many easy to use commands, which lets you be productive in writing code. (2) Speed and small size.EZGUI's main runtime is tiny in comparison to what it provides and even compared to other visual deisign tools. The 515 KB main runtime DLL is nothing compared to the VB runtimes (and OCX's) and is tiny compared to dot.net runtimes. EZGUI runs quite fast, since it was written using PowerBasic. Also the code you write yourself (in PowerBasic) runs fast as well. You get the benefit of all the PB compiler offers, plus a fast, small runtime itself written in PB. Huge applications can be written with EZGUI/PowerBasic which can fit on a floppy disk. Another benefit of the runtime is that while initially the entire app may be larger (your EXE and the EZGUI DLL), as your app grows in size, there is a tipping point where an EZGUI app can actually be smaller in size than one written using 100% code (API). The reason is that EZGUI forces code reusability. Its modular design means that you don't have to keep writing the same style of code over and over again (ie. window procedures), since EZGUI does so much for you in the background. EZGUI EXE's (your compiled code) tend to be very small, since they have less code in them, since you tend to make more calls to the runtime, rather than have to write long complex routines yourself. True one could write very modular code, when using the API, but I often find many programmers tend not to do this. Often a programmer is concentrating in "how to accomplish as task", rather than how to reuse code and keep it modular to keep the size down. EZGUI forces modularity, since the runtimes do much of the work in an app and they are modular. (3) Quality Interfaces.One of the more important aspects of software is the quality of the interface (GUI). When using the API directly, the GUI's tend to suffer because the programmers often have a limited knowledge of the API. The more complex the controls, the less often they are used, by many programmers. Just ask yourself, how often are you using the more complex controls, like the Listview, Treeview, Rebar, Pager, RichEdit, etc ? Even if you use some of these controls, like the Listview, are you using some of the more advanced features of these controls (do you use Drag and Drop icons, imagelists, ownerdraw) ? Do you use the RichEdit control ? Do you handle font and paragraphing features with it? Do you use the hyperlinking feature of it ? Do you know how to print the contents to a printer or another window DC ? Do you know how to move large blocks of data to and from the control (in the megabytes) ? Do your interfaces go beyond the standard controls ? How much graphics do you do in your apps ? Do your apps have multimedia or advanced controls like a property listbox control ? Do you use ownerdraw menus or listboxes to spice up your apps ? The point is that, the test of a design tool is how complex and powerful the interfaces are that you can develop. Notice some screenshots of actual apps written by EZGUI users: http://www.cwsof.com/apps.htmIn particular, notice the screenshots of the programs written by Fathom Systems. This customer has done some amazing things with the software he has designed. The amazing thing is that the screenshots are of apps written using EZGUI 3.0. Click on the link above the screenshots for Fathom Systems to see their web site. EZGUI is being used by a company that produces some very advanced and powerful products. The provide software with many of their hardware solutions, written using EZGUI. Also the screenshots of the apps written by Russ Srole for Advanced Video Designs are also quite amazing. Those too were written using EZGUI 3.0. Likely, what these customers are doing with EZGUI 4.0 Pro will be (and are) amazing. Do your apps have such advanced interfaces ? Today, software companies come and go. It is a tough economic time and companies need some advantage to stay in business. If a development tool can help you produce a product in half the time, that makes a difference. If a development tool allows you to add advanced features "today", rather than force you to spend months learning the API, trying to figure it out, then that can make or break a business. The "only use the API" way sounds good, but it won't make a difference if your company is not in business any more because you can't develop software fast enough or good enough. A number of the more experienced longtime EZGUI users were only DOS basic programmers when they started using EZGUI. Now many of them are producing application after application for Windows and they have interfaces which even some experienced API programmers can't write yet.
|
|
|
|
|
Logged
|
|
|
|
|
Chris Boss
|
 |
« Reply #8 on: July 22, 2009, 09:45:37 AM » |
|
No matter what development tools one uses, it is of benefit to learn something about the Windows API. Even EZGUI users are encouraged to learn about the API and how things work. EZGUI also provides mechanisms so you can more easily integrate API code within EZGUI applications. That said, as an experienced API programmer myself, learning the API is not simple and easy. It takes a long time and many mistakes are usually made along the way. It took me a few years to master many API techniques. Sure, one may learn some basics within a few weeks or months, such as window procedures, classes, message crackers, message loops, etc. But the more complex stuff takes much, much longer to learn. The API docs are not an easy read, often terms are geared toward C programming (have to translate most stuff from C syntax to Basic syntax), some explanations are a bit cryptic and to figure them out, one may simply have to do so with trial and error. I'll be the first to admit that even EZGUI has a learning curve. All software tools do. But in comparison, EZGUI users start doing complex Windows tasks much quicker and easily than by using the API directly. Also EZGUI goes far beyond the basics. For example, one may in a short while learn how to display a common dialog using the API. But consider this: Do you know how to add controls/child forms to a common dialog, preprocess its events, convert the buttons on the dialog to user defined 3D buttons. center the dialog, draw a different background, etc. ? I would think that would take much longer to figure out. One could create a RichEdit control quite easily. But do you know how to move large blocks of either text or Rich text to the control or from it, modify fonts and paragraph states of individual text in the control ? Do you know how to print the contents of a Richedit control to a printer or another window DC ? Do you know how to do hyperlinking in the control ? Can you see my point ? Basics are basics, but when it comes to the more complex stuff in Windows it takes time to learn hot to do these things. Sure one may say, I can learn it given enough time, but with the limited resources a business may have, can you wait that long before you can start adding such features to your software ? Lastly, EZGUI is not simply just some kind of API shortcut. It is an advanced GUI tool! You can study the API all you want, but you won't be building your own custom controls if a few days or weeks (experienced programmers can). The basic API doesn't provide you with: - Property Listbox control - Drag Handle control and drag and drop engine - Files Listbox control - Vector based Turtle Graphics control - advanced Canvas control (with 16,24 or 32 DIB support) - Masked Edit control - 3D Colored Buttons It also doesn't provide you with a Sprite engine with alphablending (using the GDI). Yet, EZGUI provides all of this! http://cwsof.com/details/ezgui40.htmIn the software business there is a saying "time is money" and any tool which significantly increases development speed is worth usi
|
|
|
|
|
Logged
|
|
|
|
|
Chris Boss
|
 |
« Reply #9 on: July 22, 2009, 09:47:36 AM » |
|
The EZGUI approach:
EZGUI is in its fourth generation now and over the years I have followed this approach to its development:
(1) The GUI runtime was the most important part of the product. The use of a runtime separates EZGUI from other products and for good reason. By developing a GUI engine I would have complete control over how applications developed with it would run. The first goal was to develop an engine that was reliable. It is possible to crash (GPF) applications when one uses the API. The more complex API's used, the greater chance one will may inadvertantly produce a resource leak or some other flaw which could bring ones application to stop.
With a runtime, I could add paramater checking and safety checks to make sure the application remains stable.
The second goal was to add a significant feature set. The approach was to ask the simple question "what would most Windows developers want to be able to do in their apps ?". This meant more than simply adding basic control support. In each generation of EZGUI, I continued to push the limit of what controls could do. I also added my own custom controls to fill in the gaps.
The feature set though goes far beyond just the controls.
This is where EZGUI differentiates itself from other Design tools.
For example, one of the most common tasks most programmers need is to be able to print to the printer. EZGUI provides a complete print engine, but goes further than the basics. Not only can it print text, shapes, and bitmaps, but it can print Gradients, Turtle Graphics (vectors graphics) and even the contents of a RichEdit control (RTF). Also there is support for building your own Print Preview window (via the Canvas control being integrated into the print engine).
Many programmers want more control of how the controls look. EZGUI again goes beyond other tools, by providing a custom draw engine (change the font and colors of items in some controls) and an ownerdraw engine (draw the items in some controls and menus exactly the way you want).
EZGUI's choice of custom controls also differentiates it from other tools. Rather than a bunch of high level UI controls, some of the custom controls are slighty more low level, so you can be more creative. The Canvas control has an integrated Sprite engine for building animated graphic orientated controls. The MCI control adds multimedia capabilities (video, audio, MIDI). The drag handle control is used for building drag and drop (WYSIWYG) style applications. The Turtle Graphics control gives you a powerful vector drawing engine.
Some of the more high level custom controls are the Files Listbox control, Property Listbox control and the Masked Edit control.
The runtime engine goes even further.
Some very complex tasks are built into the engine. One example is the drag icon feature, which impliments drag icons for the listview and treeview controls. This is very complex code and not easily done using the API. With EZGUI's runtime it is built in and easy to use.
EZGUI's Sprite engine is another very complex feature. Most API programmers don't have time to spend trying to build a complex Sprite engine. EZGUI's sprite engine not only animates (moves, hides/shows, animate frames) sprites (non-rectangular objects), but it also does click (mouse) and collision testing for objects. It also offers alphablending and anti-aliasing (not an easy thing to do). All of this is done via software (within EZGUI) and does not require DirectX, GDI+ or OpenGL.
The feature set is so extensive I can't do it justice in a few posts.
(2) Visual Design and Code Generation. EZGUI provides a Visual Designer/Code Generator specifically tuned to the EZGUI runtime. Rather than attempt to emulate Visual basic or some other programming language, the Designer was designed to be attuned to the GUI runtime and its features. Many of the features of the runtimes are built into the Designer. For example, it supports things like Shaped Forms (non-rectangular Forms based on a Bitmap image). It supports 3D and 2D colored buttons. It supports all of EZGUI's custom controls (except drag handle). It has a Toolbar Builder Dialog, a Properties Listbox Builder Dialog, a menu Editor and a Turtle Graphics editor. It supports EZGUI's layer engine. Many of the options or properties for Forms and Controls are unique to EZGUI, since they are features of its runtime. For example you can define a Form as a Page Form (a child form on other Forms), a Rebar Form (a form designed to be used within a Rebar control) , a Pager Form (a form designed to be used within a Pager control), an Owned Form (works differently than a Page form, but is still a child form), etc.
By combining a Visual Designer specific to its runtime, EZGUI provides a powerful tool for building advanced Windows applications.
|
|
|
|
|
Logged
|
|
|
|
|
Chris Boss
|
 |
« Reply #10 on: July 22, 2009, 09:48:57 AM » |
|
Benefits of an extended runtime engine:
Today with the economy affecting so many businesses, the old adage "time is money" comes to the fore when it comes to software development. The faster you can develop applications, the more it affects the bottom line of a company.
When developing an application there are multiple steps in the process. The first step is the visual design and basic layout. Each Visual Designer has a different approach and some may even be faster than others in this. But once you are past the basic layout of the Forms/Controls then you get to the hard part:
Making your software do something. Interacting with the GUI.
Where EZGUI shines is when you get to this step. The runtime engine is rich with features to allow you to do most anything you may need.
EZGUI users who take the time to learn how to use its many features are the happiest users, since they continue to solve problems, find solutions and build the core to their applications.
Its when you want to accomplish something unique and different that EZGUI helps out greatly.
For example, let's say you need to do the following. How quickly can you find the answers using the API ?
ie.
- Customize a Common Dialog or Browse Folders dialog by adding controls, processing events for existing controls on the dialog, changing the dialogs buttons look or painting a different background.
- Search items quickly in a Listview control within any combinations of columns (ie. match text in columns 1, 3,4 and 7 only as a group)
- impliment drag icon in a listview control and impliment autoscrolling when drag icon is at top or bottom of the list.
- customize each item in a listview, drawing custom images or text in different colors, fonts, etc.
- play a silent animation (AVI) in an animation control and to move to specific frames as desired.
- Play a video (mpeg, avi) in a control and to generate an event when the video ends or generate a flag event at specific intervals (time) or at specific positions within the video
- process a mouse click event for Listview control and to get not only the item index clicked, but the actual client coordinates of the click, the relative coordinates of the click within the subitem and the subitem (column) the click occurred. in just a couple lines of code.
- paint a custom background of a MDI Client control.
- customize a Tab control so it is uses custom colors (requires ownerdraw and background painting)
- paint a 3D background for a Toolbar control
- display a non-rectangular Form using a region based on a Bitmap background image (and paint the bitmap background)
- create 3D custom buttons or 2D custom buttons (using colors)
- Print the text of a RichEdit control to a printer or even to a window DC (ie. Canvas control)
- animate movable images (non-rectagular) over a graphic background, using frames for objects (object is animated) and anti-alias it and alphablend it
- display a Files Listbox using your own custom icons, rather than the system shell icons
- impliment a Rebar control using multiple Forms as Bands
- draw Polygons or PolyBeziers using relative coordinates, rather than absolute coordinates
- track mouse and bitblt contents of area where mouse is to a graphic window in real time (as mouse moves across the screen)
- Display the Windows Video Open File Dialog
- Enumerate every control on a Form (get a list) and get each controls ID, handle and type or class
- create a game Loop instead of a standard message
- process dropped files from Windows Explorer
- use a precision timer to exact timing (more exact than the standard timer which is limited to around 20 ms)
- estimate the speed of the CPU (real speed in execution)
- create DIB section Bitmaps and draw directly on them via their bits (no GET/SET blocks of pixel data needed, but direct access)
- Display either type of Help file (HLP or HTML)
- create your own custom Print Preview window
- get a specific list of resources in your EXE or an external DLL
- define Tray Icons (in task bar) and process the events for them, including being able to display a right click popup menu for the tray icon
- impliment a drawing drag rectangle for graphic programs (press mouse button down, then drag and a drag rectangle is drawn on the background (called "rubber banding") and then erase it when mouse button comes up
- custom paint the background in controls
- impliment a "snap to grid" like in Visual Designers when using drag/drop with controls.
Can you see how EZGUI goes beyond the basics, but gives you a feature set which deals with many advanced tasks.
Save time in software development.
Solutions to complex tasks is what EZGUI offers.
|
|
|
|
|
Logged
|
|
|
|
|
Chris Boss
|
 |
« Reply #11 on: July 22, 2009, 09:51:53 AM » |
|
Areas where EZGUI excels:
(1) Support for Legacy systems.
A good number of software developers tend to lean towards the "leading edge" operating systems (ie. XP, Vista) leaving behind all users of previous operating systems.
Is there any benefit in supporting legacy operating systems ?
Yes there is.
In a business environment there are often a number of older PC's which have plenty of life left in them, which could end up simply being thrown away just because newer software won't run on them.
Think of the value of being able to develop software (either inhouse or for customers) which can still run on say Windows 95/98 or ME. Money wasted on phasing out the older computers, simply because they can't run newer software, is saved and can be better spent elsewhere (not to forget the benefits to the environment in not throwing away perfectly good computers).
Your target customer base is greater because you don't have to leave out those who have no desire to upgrade their computer unneccesarily.
EZGUI was designed specifically to be backward compatible with older operating systems (Windows 95 w/ IE 5.0 installed). It doesn't mean though that you don't get the benefit of newer operating systems. EZGUI checks to see what operating system is running and makes certain features available on the new OS. It does this though by dynamically loading some operating system DLL's and calling some API's by address, rather than explicitly (declares). If the feature is not available on a particular operating system, EZGUI will use the next best thing or if not possible simply ignore your request.
This means you can use EZGUI to build apps that take advantage of a number of the later features of Windows (if you plan to only support more current OS's) or you can target all the 32 bit Windows operating systems.
Also EZGUI uses a number of proprietary tricks to offers features, not normally found on legacy systems. For example the Sprite engine can run on any version of Windows and no DirectX, OpenGL or GDI+ is required.
Also since EZGUI provides support for a number of advanced GUI features, such as 3D and 2D colored buttons, Shaped Forms (not rectangular Forms based on a bitmap and region), alphablending sprites, etc. you can create apps that look like they were designed for a more current operating system, but look great even on Windows 95.
(2) Ease of coding complex tasks.
EZGUI users often repeat the same comment about how much easier it is to do a number of things with EZGUI compared to doing it with the API. At times EZGUI can do a complex task with a single line of code, that would otherwise require a dozen or more lines of complex API code.
For example, EZGUI can create a Toolbar, with a selected bitmap (builtin ones), all the buttons and text with just one line of code.
The EZGUI EZ_Toolbar command contains 374 lines code in it, not counting the calls it makes to other internal routines within the runtime (which could add up to dozens more lines of code, maybe more).
Another example is the EZ_StartDrag command.
This command impliments drag icons and autoscrolling for both the listview and treeview controls. This one command accesses over 500 lines of code.
Such commands are more than low level wrappers over a few API's, but are extensive high level GUI commands.
This is where EZGUI saves you a significant amount of time. When it comes to many complex tasks, EZGUI makes it simple and fast.
(3) Features not found in other Designers, such as Layers
One of the most used features in EZGUI, which AFAIK is not found in any other Designer is its Layer engine. Where other design tools require you to use a unique child form for each tab on a Tab control, EZGUI uses the much easier layer system to accomplish this. In the Designer, you can switch layers to put controls on different layers, one for each tab of the tab control and you can visually see how your tab control will really look. You only need one form (the parent form of the tab control).
Layers are an easier way to work with the Tab control visually.
Layers don't require a tab control either! They are separate from the control itself and can be used for all sorts of stuff.
Layers can also be combined. You can show layer 1 and 2 together, layer 4 and 8 together, etc. You can even group layers so they act a separate groups (ie. layers 1 to 5 used for Tab 1, layers 6 to 10 used for tab 2, layers 11 to 15 used for something else). In fact, EZGUI supports up to 100 layers in the Visual Designer.
Also the ZOrder is automatically taken into consideration when working with layers. For example, you can set controls with Tab order numbers unique to their layer. When the designer and code generator handle layers they order the controls based on their layer first and then by their tab order number.
|
|
|
|
|
Logged
|
|
|
|
|
Chris Boss
|
 |
« Reply #12 on: July 22, 2009, 09:53:55 AM » |
|
Some areas where EZGUI's Visual Designer does some nice tricks:
(1) Working with Tab controls.
AFAIK, EZGUI is the only Designer which supports the use of Layers and it makes working with Tab controls visually easier than any other method. You don't need a separate form for each Tab. You can use one form and then simply put each tabs controls on a different layer. You can switch between layers quickly to see what each one looks like. You can even display all the layers at one time if you need to.
(2) OwnerDraw Buttons
EZGUI has built in support for ownerdraw buttons and you see them as they will look in your app. The Designer can generate 2D colored buttons, 3D colored buttons, elliptical 3D buttons and even display EZGUI macros on 3D buttons (ie. those shapes found on VCR buttons). You can also create your own Button plugins to change how the buttons look and visually work with a totally different 3D button look all your own. The plugin will then generate the proper code for you app to have your custom buttons (put it in an include).
(3) Copy and paste controls with extra features.
EZGUI provides some extra features for working with controls. You can copy a group of controls (use CTRL Key and mouse to select) and the copy them. Now when you paste the controls you have 3 options:
- Paste Offset (at new location, but in same relation to each other) - Paste Exact (paste in exact same position) - Paste Cascade (paste at location, but cascade the others from first control)
Another nice feature is that you can copy controls from one form and then paste them on any other form in your application. Select the controls on one form and copy. Then select another form and then paste them on it.
You can even close the current project, load a new one and then paste the controls on the form of another project.
(4) 3D Brushes for backgrounds of controls and forms.
Most designers only allow you to work with solid colors for backgrounds. EZGUI provides 56 builtin 3D brushes to use for form/control backgrounds. EZGUI's 3D brushes (called Patterns) are kept in a separate DLL. A template is provided to create your own pattern DLL and the designer can load a different pattern DLL. You can then use these 3D patterns for the background of any controls which will support them (some controls don't work well with 3D patterned brushes).
EZGUI's patterns are 8 x 8 pixels, which is what Windows 95/98 supports, but I would think it should be possible to use larger patterns on Windows XP and Vista. The Designer displays the patterns in about 1 32 x 32 pixel area, so 32 x 32 pixel patterns would look nice in the designer. I haven't tested this out, but I don't see why it shouldn't work. At the least though you can definitely work with 8 x 8 pixel patterns and you can do a lot with that. EZGUI uses the CreateBrushIndirect API function to load 3D brushes. The API docs say that while Win95/98/ME only support 8 x 8 brushes, Win NT/2000 and later supports larger brushes.
Because EZGUI's runtime and Designer load the brushes from a separate DLL, this makes it easy to add your own custom 3D brushes to both the runtime and the designer.
Heres the default builtin 3D brushes:
(5) Save Forms as Templates
You can forms as templates. Templates are then saved in a special folder and only certain attributes of the form are used. Templates are then displayed in the "New Form" dialog. When creating a new form, you can select a template and the new form will be layed out for you, with any controls on that template. You don't have to worry about filenames of the forms to use them. They are kept separate from regular form files (and a different extension) and you simply select them by their description.
(6) Auto generating Timer and Thread code
EZGUI provides its own TIMER and THREAD command set (it does not use PB thread commands internally, but calls the API directly) in its runtime.
The Designer allows you to define up to 2 Threads and 1 timer per form. The code is autogenerated for you so you can easily add threads and timers to your apps.
(7) Completely design your Toolbars in the Designer
Because the Designer has its own ToolBar builder dialog, you can design your toolbars visually. Simply load in the toolbar bitmap you have created using any graphic software (put the images side by side in one bitmap). The Toolbar Builder dialog allows you to define each button, its text and the image to use and other attributes. If you use Toolbars a lot in your apps, then a Toolbar builder dialog is a necessity.
|
|
|
|
|
Logged
|
|
|
|
|
Chris Boss
|
 |
« Reply #13 on: July 22, 2009, 11:36:58 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.
|
|
|
|
|
Logged
|
|
|
|
|
Chris Boss
|
 |
« Reply #14 on: July 22, 2009, 11:38:17 AM » |
|
Part 2: Ease of use and Rapid Development
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.
|
|
|
|
|
Logged
|
|
|
|
|