EZGUI

[JRS]

Chris,

Just in case Charles would refuse your generous offer for any reason, please consider me as an alternative beneficiary.

If Chris doesn't grant your request, the copy I have would be a better investment put to use in your hands.

[Charles Pegge]

Hi Chris,

I would be very interested to receive a copy of EZGUI, and see it in operation. I could investigate whether the outputs are directly usable by o2, or require a compatibility layer.

But before offering o2 as a potential 64bit compiler for EZGUI, I would like to get it through the Self-compile stage. (So far, so good. It may take another 3 weeks or so for run-time checks. (In its UPX-compressed form, it is about 123k, compared to the current 142k dll. )

[Chris Boss]

I was only highlighting EZGUI's performance with sprites, not making a full comparison between EZGUI and GDImage. The purpose of each tool is totally different. EZGUI is a GUI framework, not a Graphic framework.

I was also trying to highlight how much more EZGUI does than the core compiler (PB) does. Powerbasic programmers want all sorts of new features, but EZGUI has been doing many advanced things which the compiler can't even come close to doing. The PB compiler does not support sprites nor does it do 3D.

GDImage is an amazing graphic tool, no question there.

[Chris Boss]

Charles,

Send me an email to:   chrisboss@centurylink.net  or support@cwsof.com

Then I will send you the free copy of EZGUI 5.0 Pro.

[Chris Boss]

The key things a compiler requires to use EZGUI as a GUI framework are:

Support Include files for headers

EZGUI has two include files. One is simply all the sub/function declarations with things like constants and a few types defined. The second is actual working code. It contains a Winmain procedure which is where an EZGUI app technically starts. You do not define your own Winmain for an EZGUI, but must use its predefined Winmain. The WinMakes one call to EZGUI to a function called EZ_GUIRun. It passes parameters including three code pointers. This is where ones app starts up and EZ_GUIRun does not return until your app terminates. Then the Winmain ends and the app is terminated by Windows like normal.

What is in EZ_GUIRun and what are the three code pointers for ?

EZ_GUIRun contains all the initialization stuff for the framework and then executes a standard SDK style message loop, specific to how EZGUI works. EZGUI does your message processing, rather than you do it. You don't write a message loop for a normal EZGUI app.

The 3 code pointers are to 3 subroutines every EZGUI must have:

EZ_Main

This function is for your apps own startup code. You normally define things like the fonts, colors, etc. your forms will use and then must make at least one call to EZ_Form then command to create a new form. You can create more forms later in your code, but you must have at least one startup form created in EZ_Main.

When EZ_Main finishes, at least one form should be created by then and then control returns back to EZGUI's internal message loop.

Now every Form when create will generate a call to the second subroutine which a code pointer is passed to EZGUI, which is:

EZ_DesignWindow

This is kind of like processing WM_CREATE in SDK style apps, but it is a single routine called for every new forms created which has the name of the current form being created passed to it. One puts a Select case structure in it (one case for each form name) and then in that structure make calls to EZGUI commands to add controls or menus or other things.

Once the call to EZ_DesignWindow is finished, again control goes back to EZGUI.

Lastly, EZGUI forms all have their window procedures in the EZGUI runtime. EZGUI processes the most common ones and from them generates Events which it forwards to the third subroutine required:

EZ_Events

Events are much each to work with than window messages. EZGUI does a lot of complex message processing internally to make events easy to work with. For example in SDK style apps a scrollbar would require a lot of code in the WM_HSCROLL or WM_VSCROLL messages just to handle the movement of the scrollbar. EZGUI processes this for you and it generates a simple event, %EZ_Change, which it forwards to EZ_Events and it passes the event the newly calculated position of the scrollbar. It uses this same engine internally to also generate the %EZ_Change event for trackbars and the updown control as well.

EZGUI's event engine is where things are made much easier than in other styles of coding a Windows app.

Then to add to all of this is the huge command set EZGUI provides for you to do things within those events.

If a compiler can handle the include files (may need to be modified to match the compiler syntax), the winmain in one include and can pass code pointers then it can work with EZGUI. The only other issue is that EZGUI uses OLE strings for variable length string parameters, but O2 supports that.

[chrisc]

@Chris Boss

your propose EzGui for O2 will be good contribution for O2 advancement, thanxx a lot

[Mike Lobanovsky]

I would be very interested to receive a copy of EZGUI, and see it in operation.
...................
So far, so good. It may take another 3 weeks or so for run-time checks.

I will send you the free copy of EZGUI 5.0 Pro.

+2 and +1 from me to your respective karmas, gentlemen.

[JRS]

Chris,

I would need to run EZGUI in a SB thread to make callbacks work. I going to follow Charles lead with O2.

[Chris Boss]

John,

Interfacing EZGUI to a scripting language would be more complex than interfacing it with a compiler. O2 should be easy, if one can write a simple WIN32 app with it using a Winmain and can do code pointers. A scripting engine is different and it takes control of code execution flow and that may be challenging for EZGUI.

To use a scripting language I would recommend passing full control to EZGUI. Then rather than define the three callbacks EZGUI requires in the users code, define them in the scripting engine. Then when the scripting engine gets the callbacks, read the users code and then execute it and make the calls to the EZGUI runtime when they require them.

[JRS]

Chris,

EZGUI would need an IUP callback function like IupLoopStepWait to work threadless in SB.

[Chris Boss]

EZGUI is designed for a normal single three model (the apps normal process thread).

Like I said, with a compiler not a problem, but with a scripting language one has to consider how the script language works under the hood and whether it can handle passing control to an external DLL. If not it likely won't work.

[JRS]

SB isn't good fit for EZGUI. I hope to have some fun with it under O2.

[Chris Boss]

Charles,

I just sent you an email with a Free License for EZGUI 5.0 Pro. Please feel free to email me any questions, especially those specific to using EZGUI with the O2 compiler. I can provide extra details about how the framework works under the hood so you can better work with it using O2.

Also if you find it works well, then I will seriously consider making a "lite" version specific for O2 which I could offer as freeware. This would increase the capabilities of O2, since it would make it much easier for O2 users to do all the GUI stuff. EZGUI is much easier to work with than Powerbasic's DDT and it also is well designed for even hand coding apps.

EZGUI uses a unique approach to Form design:

(1) It uses a character based coordinate system. DOS Basic programmers will find It easy to work with. The Windows Dialog technically is based on Character Units, but a dialog unit is 1/4 of the width of the system font and 1/8 height of the system font. In older versions of Windows this came out exactly to an 8 x 16 pixel character, so a dialog unit was always 2 pixels in size. In later versions of Windows this changed, which is why Dialog units are a pain. EZGUI uses the variable width system font (rather the Dialog units fixed width) and averages the size of a characters to define its character unit size. You define coordinates using Character units, rather than dialog units. But what makes it unique is that you can define character units using floating point numbers. This means you could define a character coordinate of say 1.5 units. This allows exact positioning and sizing down to the pixel level.

(2) A number of resources are handles similar to DOS. For example, colors are defined using index numbers rather than handles for brushes and pens. EZGUI predefines 32 colors at startup, which are the 16 standard DOS colors and 16 more which are pastel (lighter) versions of the previous 16. You can then define as many more colors as you desire. So to define the colors for a form or control you would do this:

EZ_Color  FGColorIndex&, BGColorIndex&

and all the forms or controls created after this will get those colors, until you execute another EZ_Color command. So to make a control black text on white BG, you would:

EZ_Color 0, 15

Now that is just like DOS.

EZGUI handles the creation of brushes and pens in the background and then deletes then when the app terminates or when the EZ_FreeColor command. You can define hundreds of colors in EZGUI and free then on demand if you want to use different ones.

Fonts are handles just like colors. You define them with an Index and then you can simply select them as needed like this:

EZ_UseFont FontIndex&

No handles required and EZGUI cleans up when your app terminates.

To see how simple it is to code using EZGUI, here is an example of hand coding an app and you can see how little code it requires:

Code: [Select]

#COMPILE EXE
#DIM ALL
#INCLUDE "..\includes\ezgui50.inc"
#INCLUDE "..\includes\ezwmain50.inc"
' *********************  Application Constants and Declares ***************************
DECLARE SUB Form1_Events(CID&, CMsg&, CVal&, Cancel&)
%FORM1_LABEL1             = 100
%FORM1_BUTTON1            = 105
DECLARE SUB FORM1_BUTTON1_Click()
' *************************************************************************************

%UnitFlag   =   0        ' set to 1 to test unit width change

SUB EZ_Main(VerNum&)
    EZ_Color -1, -1
    EZ_Form "FORM1", "", "Your Dialog", 0, 0, 50, 18, "CK"
END SUB

SUB EZ_DesignWindow(FormName$)
    SELECT CASE FormName$
        CASE "FORM1"
              EZ_Color 0, 15
              EZ_DefFont 99, "Tahoma",  72, "BV"
              EZ_UseFont 99
              EZ_Label %FORM1_LABEL1, 1, 1, 48, 9, "Label  1", "CF"
              EZ_Color-1,-1
              EZ_UseFont -1
              EZ_Button %FORM1_BUTTON1, 12, 12, 27, 3, "Change Font Size", "T"
        CASE ELSE
    END SELECT
END SUB

SUB EZ_Events(FormName$, CID&, CMsg&, CVal&, Cancel&)
    SELECT CASE FormName$
        CASE "FORM1"
              SELECT CASE CID&
                  CASE %EZ_Window
                      IF CMsg&=%EZ_Close THEN
                      END IF
                  CASE  %FORM1_BUTTON1
                      IF CMsg&=%EZ_Click THEN
                          FORM1_BUTTON1_Click
                      END IF
                  CASE ELSE
              END SELECT
        CASE ELSE
    END SELECT
END SUB

SUB FORM1_BUTTON1_Click()
    LOCAL M$, MT$
    STATIC FW&
    IF %UnitFlag THEN
        M$="#"
        MT$="Units"
    ELSE
        M$="%"
        MT$="Percent"
    END IF
    IF FW&=0 THEN FW&=10
    IF FW&>=150 THEN FW&=10
    EZ_FreeFont 99
    EZ_DefFont 99, "Tahoma",  72, "BV["+TRIM$(STR$(FW&))+M$+"]"
    EZ_SetFont "Form1",%FORM1_LABEL1, 99
    EZ_SetText "Form1",0, CHR$(34)+EZ_GetFontName(99)+CHR$(34)+"    "+STR$(FW&)+" "+MT$+" width"
    FW&=FW&+10
END SUB

Unlike the Windows SDK or even DDT, EZGUI often uses simple text strings to define properties rather than use a bunch of bit flags in constants.

For example in the code above the EZ_Form command has a property string as the last parameter:

"CK"

The properties are usually just one capital character. In this case C stands for "Center Form" and K stands for Clipping (the controls) (C was already used for Center window, so I used K for Clipping).

For example a Textbox control would use the E character for Edit (meaning you can edit the text).

Once you get used to using these simple characters for properties one can almost memorize many commands.

Defining Fonts is similar. The line of code:

              EZ_DefFont 99, "Tahoma",  72, "BV"

Means define a new font with an index of 99, using Tahoma font at 72 point size and the property string "BV" means Boldface and Variable width.

[Chris Boss]

Screenshot of app for code in previous post:

[Chris Boss]

Entire apps can be made using EZGUI with just three subroutines (all EZGUI apps must have these three subroutines):

EZ_Main

EZ_DesignWindow

EZ_Events

Even with multiple forms one can still just use these three routines.