First, I'd like to say thank you to all have purchased EZGUI so far. The response has been good.
For those of you who hesitant to purchase EZGUI, why not give it a try, since there is a 30 day Money Back guarantee if you buy the "Packaged" version (which includes a printed manual). (Sorry, the Money Back guarantee does not apply to the email version).
Even advanced programmers will like EZGUI. I recognized that EZGUI could appear to pose limits to experienced API programmers, so I added a few special commands to give you access to the internals of EZGUI.
There is the EZ_HookDialogProc command which allows you to intercept the windows messages before EZGUI processes them. You can create your own Dialog Procedure, which "preprocesses" things, before EZGUI does.
There is the EZ_HookMsgLoopProc which allows you to intercept messages within the EZGUI message loop.
You can get the handles to Forms (Windows), controls, brushes, Bitmaps, Icons and Fonts for use with API calls.
EZGUI has its own version of the SendMessage API call:
EZ_SendMessage FormName$, ControlID&, Msg&, wParam&, lParam&
It uses the EZGUI format of Form Name and Control ID, rather than an actual Window handle.
If you want to use custom controls (or common controls not supported by EZGUI), you can use the EZ_ControlEX function. It uses standard API constants for styles and will convert the character coordinates into pixels for you.
EZGUI has built in SubClassing for controls. It is easy to do.
EZ_SubClass 1
' create controls that will be subclasses
' ie. Button
EZ_Button %ButtonID, 1,1, 20, 1.5, "Button Text", "T"
EZ_SubClass 0
When your control gets events, you can process the %EZ_SubClass event. This event passes a pointer to an array which contains the current windows message (and wParam and lParam) and the controls handle.
EZGUI handles removing the subclassing when the control is destroyed, for you. SubClassing is now very easy to do.
EZGUI has many features that are difficult to impliment for an experienced programmer. One of my favorites, is the Keyboard Accelerators. With just one line of code, you can impliment a bunch of Accelerators for a Form (Dialog).
The commands for the Common Dialogs, do NOT require any API constants at all. They are easy to use.
Applying Colors and Fonts to controls is as easy as pie.
Implimenting a Tab control is amazingly easy !
There are two methods that Microsoft suggests in implimenting a Tab control. One is to create a separate Dialog (and procedure) for each tab. The second is to simply show and hide controls as you need them on one Dialog. The second method is what EZGUI uses. It would be very difficult to use this method with "any" standard RC editor (Dialog Editor). Controls would be overlapping one another in your Dialog Editor.
EZGUI solves this problem with the use of a "Layering" engine. Controls can be created and assigned to a particular layer. The Visual Designer supports up to 51 Layers. In the Visual Desiger, you can work with one Layer at a Time (and hide the others). In your code you can display a Layer (and Hide all the others) with a single command, EZ_DisplayLayer .
The use of Layers, is a feature even VB does not have.
EZGUI is "more" than just an easier way to develop PB apps. It actually offers you powerful advanced features. Even beginners can create apps that do things that more experienced programmers find hard to do.
There are some functions in EZGUI, that took me days of research before I could write them. Now you can do many of these things in minutes.
The best thing, is that the EZGUI DLL is only 122 KB (an extra 19 KB if you use the Image library for Toolbar bitmaps).
Also, you will find that very large apps, will be smaller than their 100% code counterparts, because after the first few Dialogs, you have a savings in code size because EZGUI is so modular, that you have a savings in code size. EZGUI uses just one universal Dialog procedure for every Dialog in your program. You could have 100 Dialogs, and yet you have only one Dialog procedure. Imagine having a Dialog with 20 Scrollbars. The code could get a bit overwhelming, processing each scrollbar separately. EZGUI handles it all with one internal procedure.
EZGUI is not just for creating small utilities. It is for creating large commercial applications on the level of what many VB programmers create. It is not unreasonable to be able to create a 50,000 line (of code) app with dozens of Dialogs with EZGUI. Thats what I designed it for.
------------------
For those of you who hesitant to purchase EZGUI, why not give it a try, since there is a 30 day Money Back guarantee if you buy the "Packaged" version (which includes a printed manual). (Sorry, the Money Back guarantee does not apply to the email version).
Even advanced programmers will like EZGUI. I recognized that EZGUI could appear to pose limits to experienced API programmers, so I added a few special commands to give you access to the internals of EZGUI.
There is the EZ_HookDialogProc command which allows you to intercept the windows messages before EZGUI processes them. You can create your own Dialog Procedure, which "preprocesses" things, before EZGUI does.
There is the EZ_HookMsgLoopProc which allows you to intercept messages within the EZGUI message loop.
You can get the handles to Forms (Windows), controls, brushes, Bitmaps, Icons and Fonts for use with API calls.
EZGUI has its own version of the SendMessage API call:
EZ_SendMessage FormName$, ControlID&, Msg&, wParam&, lParam&
It uses the EZGUI format of Form Name and Control ID, rather than an actual Window handle.
If you want to use custom controls (or common controls not supported by EZGUI), you can use the EZ_ControlEX function. It uses standard API constants for styles and will convert the character coordinates into pixels for you.
EZGUI has built in SubClassing for controls. It is easy to do.
EZ_SubClass 1
' create controls that will be subclasses
' ie. Button
EZ_Button %ButtonID, 1,1, 20, 1.5, "Button Text", "T"
EZ_SubClass 0
When your control gets events, you can process the %EZ_SubClass event. This event passes a pointer to an array which contains the current windows message (and wParam and lParam) and the controls handle.
EZGUI handles removing the subclassing when the control is destroyed, for you. SubClassing is now very easy to do.
EZGUI has many features that are difficult to impliment for an experienced programmer. One of my favorites, is the Keyboard Accelerators. With just one line of code, you can impliment a bunch of Accelerators for a Form (Dialog).
The commands for the Common Dialogs, do NOT require any API constants at all. They are easy to use.
Applying Colors and Fonts to controls is as easy as pie.
Implimenting a Tab control is amazingly easy !
There are two methods that Microsoft suggests in implimenting a Tab control. One is to create a separate Dialog (and procedure) for each tab. The second is to simply show and hide controls as you need them on one Dialog. The second method is what EZGUI uses. It would be very difficult to use this method with "any" standard RC editor (Dialog Editor). Controls would be overlapping one another in your Dialog Editor.
EZGUI solves this problem with the use of a "Layering" engine. Controls can be created and assigned to a particular layer. The Visual Designer supports up to 51 Layers. In the Visual Desiger, you can work with one Layer at a Time (and hide the others). In your code you can display a Layer (and Hide all the others) with a single command, EZ_DisplayLayer .
The use of Layers, is a feature even VB does not have.
EZGUI is "more" than just an easier way to develop PB apps. It actually offers you powerful advanced features. Even beginners can create apps that do things that more experienced programmers find hard to do.
There are some functions in EZGUI, that took me days of research before I could write them. Now you can do many of these things in minutes.
The best thing, is that the EZGUI DLL is only 122 KB (an extra 19 KB if you use the Image library for Toolbar bitmaps).
Also, you will find that very large apps, will be smaller than their 100% code counterparts, because after the first few Dialogs, you have a savings in code size because EZGUI is so modular, that you have a savings in code size. EZGUI uses just one universal Dialog procedure for every Dialog in your program. You could have 100 Dialogs, and yet you have only one Dialog procedure. Imagine having a Dialog with 20 Scrollbars. The code could get a bit overwhelming, processing each scrollbar separately. EZGUI handles it all with one internal procedure.
EZGUI is not just for creating small utilities. It is for creating large commercial applications on the level of what many VB programmers create. It is not unreasonable to be able to create a 50,000 line (of code) app with dozens of Dialogs with EZGUI. Thats what I designed it for.
------------------
Comment