EZGUI - getting nosy...

Hi Chris,

I tried some of your examples like EZGUI-TestWin8-package and became a little... "interested". I read you have a lot of basic-language-experience so you certainly know MS Visual Basic previous .net - vb-Versions 2.0 up to 6.something I also used - and 6 was my favourite but sadly not fully functional on Win8 but I hope creating and using a GUI in thinBasic one day will work as easy as this...

Now back to topic:
Your EZGUI is made primarily to be used from Powerbasic? Is that right? Since the close relations of tB-roots to PB it would not be much effort to get it running in tB? Could tB possibly interpret the code created with EZGUI-Code-Generator even without to compile?

And now the important questions: Do the controls and windows raise own events on user-side - or does one also have to struggle with this weird callback-stuff which I'm not a friend of? Is there maybe an older and outdated version for trying out?

I looked into this a little and from what I gather, EZGUI would not work well with ThinBasic.

EZGUI's runtimes are not a bunch of standalone library functions. Instead it is an integrated GUI framework, which literally takes over your app.

It was designed specifically for PowerBasic, but in theory it would work with any compiler which supported OLE strings for variable lengths strings. PowerBasic uses the OLE API's for handling variable length strings.

So how does it work ?

Windows applications start in the winmain procedure. In PowerBasic, this can also be PBMain.

When the app starts up, the EZGUI runtime is called and the apps message loop is in the runtime. This first call never exits until the app is terminated.

The runtime now calls an alternate starting point in your app called EZ_Main where you can call any command in the runtime. This is where you would create your first form (using EZ_Form). Unlike ThinBasics syntax, similar to PowerBasic DDT, when a form is created (Dialog) it is immediately created and there is no need to call a Show command. The form can be defined as hidden if you like and later shown, but by default the form is created and displayed immediately.

All window classes get the WM_CREATE message when they are created. EZGUI's Form Class, when it gets the WM_CREATE message internally generates an event which the runtime forwards to the EZ_DesignWindow procedure in your app. The procedure is for all the forms in the app and the form name is passed to this procedure for the specific form just created. Here you can add controls to your form using any control creation commands in the runtime. At this point, the form exists but is not visible yet.

So how do you deal with events ?

Every EZGUI app must have three core procedures:

EZ_Main (where the app starts)

EZ_DesignWindow (one call made for each form in the forms WM_CREATE message, so you can add controls here)

and

EZ_Events

The runtime is in control of the app and only when it generates an event, does code in your app get called. All events for all forms and controls are sent to this one routine. Some EZGUI users who prefer to hand code their apps rather than use the visual designer, may actually handle everything in this one event routine for all forms/controls. The Designer generates code though which makes it more modular and parses out the events for forms and controls from this procedure to separate procedures for each form and control. The parameter is this universal event routine are:

SUB EZ_Events (FormName$, ControlID&, CMsg&, CVal&, Cancel&)

The event will get the forms name which generated the event.

It will get the ID for the specific control which generated the event (Forms have an ID of zero, so form only events have the ID of zero) (form scrollbars have IDs of -1 and -2)

UI defined events (ie. %EZ_Click, %EZ_DClick, %EZ_Change, %EZ_Selected). The runtime preprocesses all the window messages internally and converts them to EZGUI events.

CVal& contains a single LONG value associated with the event. For example when you scroll a scrollbar it sends the %EZ_Change event and the new position is passed on the CVal& parameter. Another example would be when you select an item in a listbox control (single choice) it gets the %EZ_Change event and the newly selected items index is passed in Cval&).

In cases where more data needs to be passed than what can be contained in one LONG value, CVal& contains a pointer instead. For every event which generates a pointer for CVal&, there will be a companion function in the runtime which can be used to get all the data. The first parameter of the command will be CVal& where you pass this value and the return values will be other parameters which are BYREF so they can return values. You never have to actually use pointers in your code for any EZGUI built in events. Any time an event passes a pointer in CVal& there is a companion command to retrieve the data.

For example, if EZGUI does not recognize a specific WM_NOTIFY notification message and can't preprocess it and convert it to an event, it will generate the %EZ_Notify event and pass a pointer in Cval&. You can then handle it like this:

Code:

---

CASE %EZ_Notify
    EZ_GetNotify CVal&, hCtrl&, ID&, NCode&

---

where it will return the control handle, control ID and notification code for the event. CVal& is simply passed as the first parameter and EZGUI knows what to do with it.

There are normally no Dialog procedures in EZGUI apps, only events.

That said, EZGUI was designed for easy integration with common API techniques, so you can tell EZGUI to use a Dialog Procedure for a specific form (using the EZ_UseDialogProc command). EZGUI will preprocess all the forms messages and then pass any unprocessed messages to your dialog procedure after EZGUI processes them. Each form can have one dialog procedure. If you want to override the GUI engine, you can also create a universal Dialog procedure (using EZ_HookDialogProc) for all forms and EZGUI will send all window messages for all forms to this one universal Dialog procedure before EZGUI processes them internally. This allows you to override the engine to change its behavior.

Most apps can be created without any Dialog procedures at all.


Here is an example of a minimal EZGUI app which was hand coded:

Code:

---

#COMPILE EXE
#DIM ALL
' --------------------
#INCLUDE "..\includes\ezgui50.inc"                          ' Load EZGUI Include file
' --------------------
'
GLOBAL ListFont&
'
' --------------------
#INCLUDE "..\includes\ezwmain50.inc"                          ' EZGUI Include file for WinMain
' --------------------
'
SUB EZ_Main(VerNum&)
    ' This is where your app starts up and first form is created
    EZ_Form "Window1", "", "Font Samples", 0,0, 60, 20, "C"
END SUB
'
SUB EZ_DesignWindow(FormName$)
    ' all forms generate one call to this routine when they are created
    SELECT CASE FormName$
        CASE "WINDOW1"    ' or any Form Name you choose
          EZ_Color 12, 7
          EZ_DefFont 10, "Arial", 30, ""
          EZ_UseFont 10
          EZ_Label 100, 1, 1, 20, 8, "Arial 30 point", "C"
          EZ_DefFont 11, "Courier New", 25, "BIU"
          EZ_UseFont 11
          EZ_Color 1, 7
          EZ_Label 101, 1, 9, 20, 3, "Courier", "C"
          EZ_Color -1, -1
          EZ_DefFont 6, "Terminal", 14, "FB"
          EZ_UseFont 6
          EZ_ListBox 102, 23, 1, 30, 8, "Apples|Pears|Oranges|Peaches|Grapes|Watermellons|Lemons|Limes|", "SAJ"
          EZ_UseFont -1
          ' define this font for later use
          EZ_DefFont 7, "Times new Roman", 18, "B"
          ListFont&=6
          EZ_Button 103, 30, 10, 20, 1.5, "Change List Font", "T"
          EZ_DefFont 8, "Wingdings", 24, "S"
          EZ_UseFont 8
          EZ_Color 1,15
          EZ_Label 104, 1, 14, 58, 5.5, "123456789ABCD HIJKLEFOPQR", "CF"
          EZ_Color -1, -1
          EZ_UseFont -1
        CASE ELSE
    END SELECT
END SUB
'
SUB EZ_Events(FormName$, CID&, CMsg&, CVal&, Cancel&) EXPORT
    LOCAL D$
    SELECT CASE FormName$
        CASE "WINDOW1"
            SELECT CASE CID&
                CASE %EZ_Window        ' This is the EZGUI constant for Forms ID which is zero
                CASE 103
                      IF CMsg&=%EZ_Click THEN
                        IF ListFont&=6 THEN
                            EZ_SetFont "WINDOW1", 102, 7
                            EZ_ResizeC "WINDOW1", 102, 23, 1, 30, 8
                            ListFont&=7
                        ELSE
                            EZ_SetFont "WINDOW1", 102, 6
                            EZ_ResizeC "WINDOW1", 102, 23, 1, 30, 8
                            ListFont&=6
                        END IF
                      END IF
                CASE ELSE
            END SELECT
        CASE ELSE
    END SELECT
END SUB

---

Attachment 8524

So the code above makes sense some explanations about EZGUI are needed:

Forms are defined by Names (using a string constant or even in a variable), rather than using a handle. If you need a forms actual window handle there is a function to get it (EZ_Handle), but most EZGUI commands don't require a window handle, but use the form name instead.

Colors (for Pens or Brushes in the API) are defined by index and no handles are used. The first 16 colors are predefined using the DOS Basic colors (0 to 15). The next 16 colors are predefined as pastel versions of the first 16 (16 to 31). You can then define as many custom colors as you like. This is why the EZ_Color command will be familiar to DOS Basic programmers. EZ_Color 0, 15 is black (FG) on white (BG).

Fonts also are defined by index, just like colors, so no handles are required. The first six fonts (0 to 5) are predefined as the system stock fonts. The rest you can define your own custom fonts.

Coordinates for forms and controls are NOT pixels and are also NOT Dialog Units !

They are character coordinates, based on the average size of the default system font (which usually will come out to 8 x 16 pixels). They are scalable based on the end users font setting (DPI). You can also force the size to any custom size you want.

What makes these character units (similar to DOS Basic) different is that they are floating point rather than whole numbers. In DOS Basic you can only have complete character positions. In EZGUI you can define a decimal value of a character unit (ie. 10.5) which is how it can have pixel perfect accuracy, despite using character units.

Where did this concept of character units come from ?

Actually it was based on the Windows API Dialog unit concept. Dialog units are actually calculated based on the average size of characters of the system font too. But instead of using character units, a Dialog unit is defined as:

Horizontal unit (X) is 1/4 of a character unit
Vertical unit (Y) is 1/8 of a character unit

In 16 bit windows, the default character unit used for Dialogs came out to be 8 x 16 pixels , so 1/4 of 8 is 2 pixels and 1/8 of 16 is also 2 pixels, so in 16 bit Windows dialog units came out to a nice clean 2 x 2 pixels. DPI settings though mess this up.

EZGUI character units are scalable (based on DPI) and because they are floating point they can accurately define done to the pixel level. You get the benefits of Dialogs units (scalability), but the accuracy of pixels.

Also because character units are used, it is easier to hand code apps (even though there is a designer) because character units are easier to visualize in your mind than pixels.

If Eros ever wanted to create an EZGUI like command set for forms, controls, colors, fonts, drawing and events for ThinBasic, I would be happy to provide some help.

This core GUI command set is so easy for hand coding it would definitely make Thinbasic easier to use for defining forms and controls. I could provide him with the docs for EZGUI 1.0 which would cover much of the basic GUI stuff.

For example notice how easy it is to define a Toolbar using this syntax:

Code:

---

EZ_Toolbar 50, "#LargeSTD", "BBBBBBBBB|{New File |Open|Save|Close|Cut|Copy|Paste|Print|Redo}", "LONF24X24T"

---

The first parameter is the toolbar ID. Each button on the toolbar is simply that ID plus the position of the button, so if the toolbar has an ID of 50 the buttons would have IDs of 51,52,53, ....

The next parameter is a string which passes the bitmap (ezgui stores load bitmap reference names in a string). Built in bitmaps like the standard bitmap are defined with a string constant in this case #LargeSTD.

The next parameter is a string which defines the buttons. The BBBBBBBBB stands for 9 buttons in a row. A space when be a button separator, an X would be a checkbox button, an R would be a radio button, a D would be a drop down button and an A would be a drop down button with an arrow. Then comes the strings for the buttons between {} characters.

The last parameter is a property string which defines the properties of the toolbar control. In this above example, the follow properties are used:

L - display buttons in list form with text to left of icon
O - open edge toolbar
N - no divider line
F - flat explorer style toolbar
24X24 - size of icons in pixels
T - tabstop style

It would be interesting to create an EZGUI style GUI command syntax for use with ThinBasic.

Thanks for the explanation.

So if I understand right, all controls that are created within the current "active" window without having explicitely to specify to which window that control belongs- it just goes to the current one - that's pretty cool.

But somehow it does not create Events that call Functions(-if-exist) from the Forms name immediately, like "Window1_Label1_Click..." - I was hoping more for that kind of clear arrangement instead of having to select case and if these. In your example it looks still overviewable - but somehow the EZ_Events-Procedure reminds me of callbacks that I want to avoid because they are barely readable - so I don't understand what Case 103 means and why there's nothing in Case %EZ_Window.

Anyway- the Testwin8-code-example from your site looks convincing - but the handling in code seems not to be made for my kind of a lazy guy as I am.

Edit: I needed more than 20 minutes to study and answer the first post - I just saw two more now...

The EZGUI Designer handles all the extra coding to make it all more modular and readable.

Here is an example:

Code:

---

' Portions: Copyright Christopher R. Boss, 2003 to 2011 , All Rights Reserved !
' Registered EZGUI 5.0 users may use this code Royalty Free !
'
' ======================================
' [PROTECTED CODE]        Do NOT Edit !
' ======================================
'
#COMPILE EXE
#DIM ALL        '  This is helpful to prevent errors in coding
'
#INCLUDE "C:\ezgui45beta\includes\ezgui50.inc"                          ' EZGUI Include file for Declares
#RESOURCE ".\rcdata\proto1.pbr"
'
%FORM1_BUTTON1            = 100
%FORM1_BUTTON2            = 105
%FORM1_BUTTON3            = 110
%FORM1_BUTTON4            = 115
%FORM1_BUTTON5            = 120
%FORM1_BUTTON6            = 125
%FORM1_MCI1              = 130
%FORM1_BUTTON10          = 135
%FORM1_BUTTON11          = 140
%FORM1_PLISTBOX1          = 145
%FORM1_FLISTBOX1          = 150
'
#INCLUDE "C:\ezgui45beta\includes\ezwmain50.inc"                          ' EZGUI Include file for WinMain
'
SUB EZ_Main(VerNum&)    ' (PROTECTED)
    EZ_Reg %EZ_CUSTID,%EZ_REGNUM
    InitAppScale
REM
    EZ_DefImageFolder "Graphics"
    EZ_AllowCommandEvents  0
    EZ_DefFont 6, "Arial", 10, "V"
    EZ_DefFont 7, "Courier New", 10, "F"
    EZ_DefFont 8, "Times New Roman", 10, "V"
    EZ_DefFont 9, "Modern", 10, "V"
    EZ_DefSystemColor 32, 4
    EZ_DefSystemColor 33, 5
    EZ_DefSystemColor 34, 15
    EZ_DefSystemColor 35, 24
    EZ_DefColorL 36, &H00FFB164
    EZ_DefColorL 37, &H0014AB9F
    EZ_DefColorL 38, &H0047A7FF
    EZ_DefColorL 39, &H00D2AACF
    EZ_DefColorL 40, &H001CD5E3
    EZ_DefColorL 41, &H00BC8943
    EZ_DefColorL 42, &H006C6AB7
    EZ_DefColorL 43, &H00DD4489
    IF Main_Initialize(VerNum&) THEN
          EZ_FORM1_Display ""
    END IF
END SUB
'
SUB InitAppScale()
    EZ_DefCharSizeA 8,16
END SUB
'
SUB EZ_DesignWindow(FormName$)    ' (PROTECTED)
    SELECT CASE FormName$
          CASE "FORM1"
              EZ_FORM1_Design
          CASE ELSE
              OtherForm_Design FormName$
    END SELECT
END SUB
'
SUB EZ_Events(FormName$, CID&, CMsg&, CVal&, Cancel&)    ' (PROTECTED)
    IF PreProcess_Events(FormName$, CID&, CMsg&, CVal&, Cancel&) THEN EXIT SUB
    SELECT CASE FormName$
          CASE "FORM1"
              EZ_FORM1_ParseEvents CID&, CMsg&, CVal&, Cancel&
          CASE ELSE
              OtherForm_Events FormName$, CID&, CMsg&, CVal&, Cancel&
    END SELECT
END SUB
'
' ======================================
' [USER ACCESSABLE CODE]  You may Edit !
' ======================================
'
FUNCTION Main_Initialize(BYVAL VerNum&) AS LONG
    LOCAL RV&
    RV&=1
    FUNCTION=RV&
END FUNCTION
'
SUB OtherForm_Design(FormName$)
    SELECT CASE FormName$
          CASE ELSE
    END SELECT
END SUB
'
SUB OtherForm_Events(FormName$, CID&, CMsg&, CVal&, Cancel&)
    SELECT CASE FormName$
          CASE "{OPENDLG}", "{SAVEDLG}", "{OPENDLGX}", "{SAVEDLGX}", "{COLORDLG}", "{FONTDLG}", "{PRINTDLG}", "{PAGEDLG}", "{FINDDLG}"
          CASE "{ABORTDLG}"
          CASE "{MSGBOX}"
          CASE "{APP}"      ' Not a Form
              SELECT CASE CMsg&
                    CASE %EZ_NoTheme
                    CASE %EZ_Terminate
              END SELECT
          CASE ELSE
    END SELECT
END SUB
'
FUNCTION PreProcess_Events(FormName$, CID&, CMsg&, CVal&, Cancel&) AS LONG
    LOCAL RV&
    RV&=0
    FUNCTION=RV&
END FUNCTION
'
'<<BEGINFORM>> "FORM1"
'
' ======================================
' [PROTECTED CODE]        Do NOT Edit !
' ======================================
'
SUB EZ_FORM1_Display(BYVAL FParent$)    ' (PROTECTED)
    EZ_Color 0, 25
    EZ_Form "FORM1", FParent$, "Test app", 0, 0, 111, 45, "CF"
END SUB
'
SUB EZ_FORM1_Design()    ' (PROTECTED)
    LOCAL CText$
    EZ_Color 1, 25
    EZ_UseIFont "Tahoma", 12,"BV"
    EZ_ODButton %FORM1_BUTTON1, 1.625, .8125, 16, 4, "Button", "T"
    EZ_Color 1, 25
    EZ_UseIFont "Tahoma", 12,"BV"
    EZ_ODButton %FORM1_BUTTON2, 2, 5.8125, 16, 4, "Button", "T"
    EZ_SetRegion "Form1", %FORM1_BUTTON2,-2,0
    EZ_Color 1, 25
    EZ_UseIFont "Tahoma", 12,"BV"
    EZ_ODButton %FORM1_BUTTON3, 1.625, 10.8125, 16, 4, "Button", "T"
    EZ_SetRegion "Form1", %FORM1_BUTTON3, 1,0
    EZ_Color 0, 20
    EZ_UseIFont "Tahoma", 12,"BV"
    EZ_ODButton %FORM1_BUTTON4, 20.625, .8125, 16, 4, "Button", "T"
    EZ_Color 0, 20
    EZ_UseIFont "Tahoma", 12,"BV"
    EZ_ODButton %FORM1_BUTTON5, 20.625, 5.8125, 16, 4, "Button", "T"
    EZ_SetRegion "Form1", %FORM1_BUTTON5,-2,0
    EZ_Color 0, 20
    EZ_UseIFont "Tahoma", 12,"BV"
    EZ_ODButton %FORM1_BUTTON6, 21, 10.8125, 16, 4, "Button", "T"
    EZ_SetRegion "Form1", %FORM1_BUTTON6, 1,0
    EZ_Color-1,-1
    EZ_UseFont 4
    EZ_MCIControl %FORM1_MCI1, 2, 23, 46, 18, "S"
    FORM1_MCI1_Set ""
    EZ_Color 1, 25
    EZ_UseIFont "Tahoma", 12,"BV"
    EZ_ODButton %FORM1_BUTTON10, 2, 15.75, 16, 4, "{{BIG_SAME_ARROWDN}}", "T"
    EZ_SetRegion "Form1", %FORM1_BUTTON10,-2,0
    EZ_Color 0, 20
    EZ_UseIFont "Tahoma", 12,"BV"
    EZ_ODButton %FORM1_BUTTON11, 20.5, 15.75, 16, 4, "{{BIG_DOUBLE_SAME_RRECT}}", "T"
    EZ_SetRegion "Form1", %FORM1_BUTTON11,-2,0
    EZ_Color-1,-1
    EZ_UseFont 9
    CText$ = "Category 1|Text{T}OK|Color{C}&HFF0080|Drop Down List{D}One[One;Two;Three;Four;Five]|File{F}myproject.bmp[Bitmap Files;*.bmp;]|Dr"_
            + "op Down{D}Item 1[Item 1;Item 2]"
    EZ_PListBox %FORM1_PLISTBOX1, 54, 5, 50, 9, CText$, "STV"
    EZ_Color-1,-1
    EZ_UseFont 9
    EZ_FListBox %FORM1_FLISTBOX1, 54, 18, 52, 23.5, "", "STV"
    FORM1_FLISTBOX1_Init "Form1", %FORM1_FLISTBOX1
END SUB
'
SUB EZ_FORM1_ParseEvents(CID&, CMsg&, CVal&, Cancel&)    ' (PROTECTED)
    SELECT CASE CID&
          CASE %EZ_Window
              FORM1_Events CID&, CMsg&, CVal&, Cancel&
          CASE  %FORM1_BUTTON1
              FORM1_BUTTON1_Events CID&, CMsg&, CVal&, Cancel&
              IF CMsg&=%EZ_OwnerDraw THEN
                    EZ_Draw3DButton "Form1", %FORM1_BUTTON1, CVal&, 25, 1,  EZ_ODIFont
              END IF
          CASE  %FORM1_BUTTON2
              FORM1_BUTTON2_Events CID&, CMsg&, CVal&, Cancel&
              IF CMsg&=%EZ_OwnerDraw THEN
                    EZ_Draw3DButtonRR "Form1", %FORM1_BUTTON2, CVal&, 25, 1,  EZ_ODIFont
              END IF
          CASE  %FORM1_BUTTON3
              FORM1_BUTTON3_Events CID&, CMsg&, CVal&, Cancel&
              IF CMsg&=%EZ_OwnerDraw THEN
                    EZ_Draw3DButtonE "Form1", %FORM1_BUTTON3, CVal&, 25, 1,  EZ_ODIFont
              END IF
          CASE  %FORM1_BUTTON4
              FORM1_BUTTON4_Events CID&, CMsg&, CVal&, Cancel&
              IF CMsg&=%EZ_OwnerDraw THEN
                    EZ_Draw3DButton "Form1", %FORM1_BUTTON4, CVal&, 20, 0,  EZ_ODIFont
              END IF
          CASE  %FORM1_BUTTON5
              FORM1_BUTTON5_Events CID&, CMsg&, CVal&, Cancel&
              IF CMsg&=%EZ_OwnerDraw THEN
                    EZ_Draw3DButtonRR "Form1", %FORM1_BUTTON5, CVal&, 20, 0,  EZ_ODIFont
              END IF
          CASE  %FORM1_BUTTON6
              FORM1_BUTTON6_Events CID&, CMsg&, CVal&, Cancel&
              IF CMsg&=%EZ_OwnerDraw THEN
                    EZ_Draw3DButtonE "Form1", %FORM1_BUTTON6, CVal&, 20, 0,  EZ_ODIFont
              END IF
          CASE  %FORM1_MCI1
              FORM1_MCI1_Events CID&, CMsg&, CVal&, Cancel&
          CASE  %FORM1_BUTTON10
              FORM1_BUTTON10_Events CID&, CMsg&, CVal&, Cancel&
              IF CMsg&=%EZ_OwnerDraw THEN
                    EZ_Draw3DButtonRR "Form1", %FORM1_BUTTON10, CVal&, 25, 1,  EZ_ODIFont
              END IF
          CASE  %FORM1_BUTTON11
              FORM1_BUTTON11_Events CID&, CMsg&, CVal&, Cancel&
              IF CMsg&=%EZ_OwnerDraw THEN
                    EZ_Draw3DButtonRR "Form1", %FORM1_BUTTON11, CVal&, 20, 0,  EZ_ODIFont
              END IF
          CASE  %FORM1_PLISTBOX1
              FORM1_PLISTBOX1_Events CID&, CMsg&, CVal&, Cancel&
          CASE  %FORM1_FLISTBOX1
              FORM1_FLISTBOX1_Events CID&, CMsg&, CVal&, Cancel&
          CASE ELSE
              FORM1_Events CID&, CMsg&, CVal&, Cancel&
    END SELECT
END SUB
'
' ======================================
' [USER ACCESSABLE CODE]  You may Edit !
' ======================================
'
SUB FORM1_Events(CID&, CMsg&, CVal&, Cancel&)
    SELECT CASE CID&
          CASE %EZ_Window
              SELECT CASE CMsg&
                    CASE %EZ_Loading
                    CASE %EZ_Loaded
                    CASE %EZ_Started
                    CASE %EZ_Close
                    CASE ELSE
              END SELECT
          CASE ELSE
    END SELECT
END SUB
'
SUB FORM1_BUTTON1_Events( MyID&, CMsg&, CVal&, Cancel&)
    SELECT CASE CMsg&
          CASE %EZ_Click
          CASE ELSE
    END SELECT
END SUB
'
SUB FORM1_BUTTON2_Events( MyID&, CMsg&, CVal&, Cancel&)
    SELECT CASE CMsg&
          CASE %EZ_Click
          CASE ELSE
    END SELECT
END SUB
'
SUB FORM1_BUTTON3_Events( MyID&, CMsg&, CVal&, Cancel&)
    SELECT CASE CMsg&
          CASE %EZ_Click
          CASE ELSE
    END SELECT
END SUB
'
SUB FORM1_BUTTON4_Events( MyID&, CMsg&, CVal&, Cancel&)
    SELECT CASE CMsg&
          CASE %EZ_Click
          CASE ELSE
    END SELECT
END SUB
'
SUB FORM1_BUTTON5_Events( MyID&, CMsg&, CVal&, Cancel&)
    SELECT CASE CMsg&
          CASE %EZ_Click
          CASE ELSE
    END SELECT
END SUB
'
SUB FORM1_BUTTON6_Events( MyID&, CMsg&, CVal&, Cancel&)
    SELECT CASE CMsg&
          CASE %EZ_Click
          CASE ELSE
    END SELECT
END SUB
'
SUB FORM1_MCI1_Set(BYVAL C$)
END SUB
'
SUB FORM1_MCI1_Events( MyID&, CMsg&, CVal&, Cancel&)
    SELECT CASE CMsg&
          CASE %EZ_Click
          CASE ELSE
    END SELECT
END SUB
'
SUB FORM1_BUTTON10_Events( MyID&, CMsg&, CVal&, Cancel&)
    SELECT CASE CMsg&
          CASE %EZ_Click
          CASE ELSE
    END SELECT
END SUB
'
SUB FORM1_BUTTON11_Events( MyID&, CMsg&, CVal&, Cancel&)
    SELECT CASE CMsg&
          CASE %EZ_Click
          CASE ELSE
    END SELECT
END SUB
'
SUB FORM1_PLISTBOX1_Events( MyID&, CMsg&, CVal&, Cancel&)
    SELECT CASE CMsg&
          CASE %EZ_Change
          CASE ELSE
    END SELECT
END SUB
'
SUB FORM1_FLISTBOX1_Init(BYVAL FormName$, BYVAL IDNum&)
    LOCAL P$
    STATIC FirstFlag&, ImgListNum&
    IF FirstFlag&=0 THEN
          ImgListNum&=-1
          FirstFlag&=1
    END IF
    EZ_FLUseImageList FormName$,IDNum&, ImgListNum&
    EZ_FLSetStyle FormName$,IDNum&, "DSF"
    EZ_SetText FormName$,IDNum&, EZ_AppPath+"*.*"
END SUB
'
SUB FORM1_FLISTBOX1_Events( MyID&, CMsg&, CVal&, Cancel&)
    SELECT CASE CMsg&
          CASE %EZ_Updated
          CASE ELSE
    END SELECT
END SUB

---

Attachment 8525

The above example contains a number of ownerdraw buttons, a property listbox control, a files listbox control and an MCI control.

Now this looks much better- especially the code below line 230 is much closer to the kind of basic that I like. Still the stuff in the user-editeable sections above which confuses me a little - but in general pleases much more to read than win32-gibberish-callbacks :)

The generated basic code - propably powerbasic - seems to work without any change on the first sight.

EZ sounds like fun to me and fast results when it comes to create some windows-app with some controls - and also easy if it comes to change maybe just the position and size of a button to squeeze another one in or fast re-arrange the whole stuff when I think - the graphics-display might look better on the left instead right and the buttons above instead of below etc.

Now EZGUI needs some entry-point - some tB-function-Pointer to EZ_Main that gets passed when TBMain-Function launches EZGUI-Runtimes?

Where's the hook? Why do you think it won't work? Does the script have to be compiled?

I'm just some hobbyist that codes for fun and not a professional programmer so I have not that big insight - especially not when it comes to win32 and other crimes MS commited at their users ;)

In Internet slang, a troll (/ˈtroʊl/, /ˈtrɒl/) is a person who sows discord on the Internet by starting arguments or upsetting people,^[1] by posting inflammatory,^[2] extraneous, or off-topic messages in an online community (such as a forum, chat room, or blog), either accidentally^[3][4] or with the deliberate intent of provoking readers into an emotional response^[5] or of otherwise disrupting normal on-topic discussion.^[6]

I think I talked to Eros about this in the past and Thinbasic because it is a scripting language , it would not interface with the EZGUI runtimes properly. If EZGUI was just a set of API wrappers, it might have been possible to port some of it to thinbasic modules, but it isn't.

Now a better solution would be to create an EZGUI emulation as a thinbasic module.

I don't have this listed on my web site anymore, but you can download this DDT based Visual Designer for use with PowerBasic:

(Link Removed !)

It generates PowerBasic code and uses DDT for the GUI stuff. There is an include file which has an emulation layer to make it more like EZGUI, including event generation. The source code should be portable to ThinBasic and could be used as the basis of a ThinBasic - EZGUI module for easier coding.

Why not download it and take a look at the code. While it is only rudimentary, it could be the basis of an open source project to build an EZGUI like command set for ThinBasic. Because it is uses PowerBasic DDT commands (which is how ThinBasic current handles GUI stuff), a thinbasic module built using it would be compatible with the current GUI command set in thinbasic too.


Download the designer ASAP, since I will leave it available for only a short time. I don't want this designer distibuted enmass. At minimum you can use it and make a copy available to Eros and Petr and see if it could become the basis of a ThinBasic EZGUI module. If you are interested and it would work I would be willing to open source the include file.

Downloaded-thanx- now have some stuff to study...

Ok ! I removed the download now. Feel free to pass it on to Eros and Petr.

I tried - drew a form and some button on it - thereafter used the Generate Application Button but when I try to run it in PB10 I get an Error 426 like "Variable Expected" - code-lines looks like this:
#IF %EZLIB_UseAdjust
SUB EZLIB_AddDlgOffsets(BYVAL WS&, BYVAL EXS&, AW&, AH&, BYVAL MFlag&)
LOCAL H&, W&, hDC&, hOldFont&, TM AS TEXTMETRIC, SZ AS SIZEL, DW!, DH!
cursor is in front of DW!, DH! - seems they added a new keyword. But after changing DW to DWW it works :D

EZGUI is very good work but is not nothing ultra simple or better or easier to use than
already tB events at all.
Rene...
I don't get it why is classic win32 event callback way to hard for you ?

The include file was for PB 8.0 and there is an alternate include file for PB 9. Try the PB 9 version. If that does not work, then simply change the variables which are now keywords (the DH and DW variables are now keywords) in the subroutine and the compiler error will be gone.

You might be right Zlatko - it's not as easy as it sounded first - I have not find out yet how to change the caption of my button :D - and I don't like he PB-Editor because one does not have built-in overview as thinAir has. Always have to F2 to look for a function...

Win32-callbacks are cumbersome and chaotic. The code is barely readable and one always needs those strange abbrv. f. words one does not know and follows no rules because of those many exceptions. Microsoft-pages are bogous and written in a language I don't understand and searching for some abbreviation for some event where I even don't know if it exists nor its name and then it does not exist the way that would be locigal (except %BN_Clicked) hours and hours without finding the solution is no fun.
And the stupid about this is: I used MS Visual Basic for years. And they don't have "Callbacks".
Every Form has its variables, properties, functions and events. Also the controls. And you don't have to program over and over the same stuff with a 100 embedded select cases and ifs - but you can concentrate on the things you want to create.
Just write your code in the generated code-skeleton which is clearly structured and you just have two dropdown-combo-boxes above the code window - at the left one you pick the controls or dialogs name - on the right one you choose the event - and whoops: There's the function! Just type your code that shall happen if that control or form experiences a certain event - and done.
Then move on to next control_event... and they had it that way already in the early 90s. So I never needed to learn callbacks because it was always done internally. And now having to do this all "manually" feels like the wheel has been invented already but mankind does not use it.

Just an update: Hope you're all busy coding and carving your ideas :D -EZGUI is nice work- I like the visual editor and how it's made- but it lacks a few important controls as trees and grids. Maybe not included in the free version but in the commercial one- who knows. I think the pre-defined events are not ample - just click is definetely not enough- it needs a whole lot more from rclick,mclick, -wheeled, -btnHold(mousebtn), -OnDrag, -OnDrop, -mousemove(x,y,btn) , -keydown, -keyup, -keyhold to -activate, -gotfocus, -lostfocus, onchange (scrollbars/sliders/textfields or textboxes), onResize, changeselection on list and (not available) trees or property lists- seem very important to me. Basically a good approach - just that it does not seem allow to alter properties of once defined controls- if so- then sorry_ i've no use for...

The DDT Designer you downloaded is a "Utility" designer for building small utlity style apps using a minimal GUI. I was planning on a more powerful version later, but wanted to see how well the DDT designer did in the market. Most PB'ers use PBForms, so the designer was not popular and I didn't make a more powerful version. I offered the designer as freeware for awhile, but after some time I felt it may have confused potential customers about my commercial product EZGUI professional (which is totally different), so I stopped making the download of the DDT designer available.

The designer you downloaded does not reflect the commercial product, which uses NO DDT, but instead the EZGUI framework.

The commercial product not only supports all the standard Windows controls, but also the following more advanced Windows controls:

Toolbar
ToolTips
StatusBar
ProgressBar
Trackbar
Treeview
Listview
UpDown
DateTime
Calendar
Tab control
Pager control
Rebar control
Animation control


it also supports MDI (multiple document interface) and has a MDIClient control.

it also supports the RichEdit control (versions 1.0 to 4.0)

aside from the native controls it also has the following custom controls:

Canvas control with 2D proprietary Sprite engine (and graphics engines)
Drag Handle control (for drag and drop engine for building WYSIWYG style apps like a visual designer)
Files Listbox control (a mini explorer like listbox control)
glCanvas control (based on OpenGL with a 3D scripting language)
MCI control (for video, audio, MIDI, CD audio and more)
Property Listbox control
Shape/Hotspot/Splitterbar control (serves multiple purposes)
Turtle Graphics control (vector based graphic control with a turtle graphics macro language)


beyond this is also has an ownerdraw and customdraw engine for customizing existing controls. For example it easily does 2D and 3D color Button controls using ownerdraw. You can even customize the common dialogs.

So the commercial product is a totally different animal than the freeware DDT designer you downloaded and even its visual designer is far superior.

The reason I suggested you download the freeware DDT designer is the include file with it. It has an emulation layer which provides EZGUI like commands and events, but uses DDT as the engine. This could be easily ported to ThinBasic, since ThinBasic emulates the PowerBasic GUI command set.

Your visual designer is great- no doubt- and also how it creates a script-skeleton. Ok- the version you uploaded might not come close the product you have on the market- but just an "onLClick"-event does definetely not serve all needs. I have a problem to find the simplest thing: just to change caption of a button control or just to end the program if the button I drew gets clicked- perhaps your documentation in the "big, real version" is better - if not you won't have much word-of-mouth-advertising. If you're real "buisiness man" as John suspects I would work on that - or at documentation. But I think you're one that just haves fun creating functions and is happy if they work - as I am happy if my functions work- that's why I'm creating lots of... I want to be happy often. For "commercial quality" it needs more explanation for the "stupids" - and not just rudimentary as for the cracks which are in the stuff. But what shall I say- I only saw "freeware-preview". Your visual designer is great stuff and it deserves to be honored... but the creation of events is quite ...small ? - sorry don't know english word for less than minimal meets requirements

Two things you mentioned in your post about controls:

Events

One must be careful in how they view events. Many of the events found in modern object oriented languages, just don't exist normally in WIN32 coded controls or they require extra work to impliment. What many developers who use dot.net languages may not realize is that some events require a lot of background work to make them possible. For example, low level events like keyboard, mouse button (not a click, but button down and up) require subclassing of the controls. Some special events like drag and drop events either don't exists in the API or are very rudimentary.

Now in WinForms apps (dot.net) likely the dot.net platform builds upon the WIN32 API to make such events available or adds what did not exist.
In WPF apps, new controls have been created in the dot.net runtimes so they likely were able to build such events directly into them.

ThinBasic is built on top of the WIN32 API's, so adding such events require a bit of work.

Altering properties

If referring to altering properties after the control is created, once again the WIN32 API does not always allow this. In the API docs certain properties (more accurately window styles) are not allowed to be changed after the creation of the control (requires destroying the control and recreating it). Some window styles can be changed, but sometimes a specific window message must be used to accomplish this rather than just use the SetWindowLong API function to change them directly.

Object Oriented languages most programmers use today, shield programmers for the low level WIN32 API's and they are built on top of it, often changing how things really work. In the WIN32 there are no Objects as you know them. There are window classes (controls), but they are not object oriented. Instead Windows (under the hood) is message based, rather than using methods and properties.

Now in recent years many new features have been added to Windows using COM based classes, which are more object oriented, but this is stuff which was built on top of the WIN32 API, rather than replace it.

ThinBasic (and its parent PowerBasic) though build upon the WIN32 API and this is reflected in the GUI command set. The PowerBasic GUI command set is a set of wrappers for the WIN32 Dialog Class APIs. Likely thinbasic is too (or it simply uses the DDT command set directly). This is why there are dialog procedures, callbacks, etc (actually PowerBasic control callbacks are simply message crackers for two API messages WM_COMMAND and WM_NOTIFY).

One of the reasons why PowerBasic producs such small and fast executables is because it relies on the low level WIN32, rather than upon a much larger more complex framework, like dot.net.

Most programming languages (aka. Visual Studio) are based on very high level frameworks and particularly on object oriented coding styles. The WIN32 API was based on a more functional (or procedural) based coding style, often referred to as flat API's. The WIN32 is "lean and mean" . Dot.net and other modern OOP frameworks tend to be "fat and bloated".

Consider this:

When I first upgraded to Windows 95 (from 16 bit Windows 3.1) my PC was a 486 (or 586) CPU with only 8 megabytes (not gig) of RAM. Windows 95 ran great on that PC. It was less than 50 mhz in speed too. Todays PC's have 200 to 300 times as much RAM as it did and CPU's which are 25 to 50 times faster (maybe more). So what happened to Windows ?

In the early 2000's, Microsoft moved away from the WIN32 (and MFC, ATL, etc.) to dot.net (managed languages). Emphasis was put on heavy object oriented coding styles. Software began to slow down because it overloaded the PC's and the hardware manufacturers had to keep pace, just to keep the PC running decently with the software, not better. Has OOP produces the panacea programmers had hoped for ?

Some experienced programmers have had second thoughts about OOP and the effects it has had on performance (and as you know PowerBasic programmers are all about performance).

You might find interesting some articles on my blog where I write about this:

http://cwsof.com/blog/?p=612

http://cwsof.com/blog/?p=412

http://cwsof.com/blog/?p=397

http://cwsof.com/blog/?p=395

Now some may take issue with my views on OOP in these articles, but please following any links in the articles to stuff written by others.

One good example is a white paper written my Richard Mansfield. Who is he ?

Maybe most are too young to remember him, but for us old timers he is someone who really knows a lot. He used to be the editor of the Compute Gazette magazine (Commodore 64 stuff) and he also wrote a lot of books on programming. I learned how to program in 6502 machine language from his excellent book. He also wrote a lot of books on Visual Basic and later VB dot.net.

I once read about a comment that Alexander Stepanov once is suppose to have said about OOP, calling it s Hoax. Whether this comment is accurate or not, I don't know, but from what I have read about him he tends to be more procedural oriented in coding style. Who is he ? He worked for Bell labs with all those legends in the field. He was instrumental in the writing of the C++ Standard Template Libraries and he use to work for Adobe and taught classes for their programmers.

ThinBasic has its heritage with PowerBasic and PowerBasic is a strong procedural based language, perfect for the WIN32s. Of course it does support some OOP (classes), but it is not required though.

Ok, what does all of this have to do with programming language design ?

A great deal.

In object oriented languages one is used to things like:

Form.caption = "some text"
Button.caption = "some text"

Button.top = 20
Button.left = 30

In the WIN32, this does not exist. In the WIN32 to change the text of a dialog or a button control one would either call a flat API or send the window a message like this:

SetWindowText hWindowHandle&, SomeTextinAsciiZFormat

or

SendMessage hWindowHandle&, %WM_SETTEXT,0, VARPTR(SomeTextString_which_isNullTerminated)

The PowerBasic compiler (which ThinBasic emulates) uses a command like:

DIALOG SET TEXT hDialogHandle&, "some text"

or

CONTROL SET TEXT hDialogHandle&, ControlID&, "some text"

These commands are simply wrappers for the above WIN32 methods.

You can see that WIN32 coding is a far cry from object oriented coding.

True WIN32 coding is more procedural in style, while dot.net coding (and other Microsoft languages) are more object oriented.

Objects are something inherent to modern programming languages, rather than the core of Windows.

This love affair with OOP is what has caused Windows to bloat into the monstrousity it is now.

Microsofts C++ expert Herb Sutter discusses this in his talk "Why C++ ?":

http://channel9.msdn.com/posts/C-and...b-Sutter-Why-C

He explains how Windows Vista was Microsofts attempt to do everything with the operating system using a managed language (aka. dot net) and how it was a failure (slow and bloated basically) because of this. Why ?

Because performance can only be found using native coding (in Windows this means the WIN32) and more low level approaches to coding. Now personally I don't think he goes far enough, because C+ programmers still use a degree of OOP, but he faces the real problem with modern computer devices (including mobile), which is poor performance and managed languages just don't cut it.

Now personally I would go a step further. OOP has added too much extra overhead to our software today, making it more difficult to debug and also bloated.

Don't believe this ?

Ask any professional programmer today to try to develop some software and tell them they can only use a computer with less than 1 gigabye memory and a CPU which is less than 1 ghz. They would laugh in your face and say it can't be done. Now ask them to develop some software using a 10 year old Windows XP computer with only 256 meg ram and a 20 gig harddrive. Again they would laugh in your face.

Now tell them you want the software they develop to run just as well on a Windows 98,XP or 2000 machine with only 256 meg ram or less as it does on a modern PC and they will say it is impossible.

But it is possible and it can all be done using native coding using the WIN32 API.

Look at how tiny ThinBasic is. The entire installation (once installed) is about 28 megabytes. Impressive. This is why the use of PowerBasic really makes a difference in its development.

Here is a list of all the Events in EZGUI 5.0 Professional:

Note: Some are specific to certain controls, some are specific to non-controls like the common dialogs or tray icons or the like.

• %EZ_Close
• %EZ_Click
• %EZ_DClick
• %EZ_Focus
• %EZ_NoFocus
• %EZ_Disable
• %EZ_Change
• %EZ_Timer
• %EZ_ToolTip
• %EZ_UnKnown
• %EZ_Command
• %EZ_Notify
• %EZ_Redraw
• %EZ_CtrlError
• %EZ_PrintError
• %EZ_AllowEdit
• %EZ_DragForm
• %EZ_SysMenu
• %EZ_DClickCap
• %EZ_NoDClick
• %EZ_DoMDIMsg
• %EZ_GameLoop
• %EZ_KeyDown
• %EZ_KeyUp
• %EZ_KeyPress
• %EZ_Enable
• %EZ_HelpShow
• %EZ_HelpShowC
• %EZ_HelpShowM
• %EZ_HelpShowID
• %EZ_SysKeyDown
• %EZ_SysKeyUp
• %EZ_SysKeyPress
• %EZ_ActivateMe
• %EZ_FinishMCI
• %EZ_FlagMCI
• %EZ_AppFocus
• %EZ_NoAppFocus
• %EZ_CBDropDown
• %EZ_CBDropUp
• %EZ_NoAutoSize
• %EZ_ChangeZOrder
• %EZ_ChangeSize
• %EZ_ChangePos
• %EZ_PollCtrl
• %EZ_NextCtrl
• %EZ_CaptureOff
• %EZ_AllowFirstCtrl
• %EZ_RTFLink
• %EZ_Updated
• %EZ_ConvBtnPos
• %EZ_DoDefFocus
• %EZ_Compare
• %EZ_InitPropDlg
• %EZ_Loading
• %EZ_Started
• %EZ_Loaded
• %EZ_FreeNow
• %EZ_LButtonDown
• %EZ_LButtonUp
• %EZ_LButtonDC
• %EZ_MButtonUp
• %EZ_RButtonUp
• %EZ_DragClear
• %EZ_DragPos
• %EZ_SubClass
• %EZ_Drag
• %EZ_Drop
• %EZ_Size
• %EZ_DropFiles
• %EZ_Cancel
• %EZ_NoDrag
• %EZ_DragItem
• %EZ_Move
• %EZ_Dropping
• %EZ_DragItemDrop
• %EZ_Maximize
• %EZ_Minimize
• %EZ_Restore
• %EZ_MouseMove
• %EZ_MouseEnter
• %EZ_MouseLeave
• %EZ_Sizing
• %EZ_AutoSizeStart
• %EZ_AutoSizeEnd
• %EZ_ScaleMe
• %EZ_SelectCursor
• %EZ_TrayLButtonDown
• %EZ_TrayLButtonUp
• %EZ_TrayRButtonDown
• %EZ_TrayRButtonUp
• %EZ_TrayDClick
• %EZ_HotMouseMove
• %EZ_HotMouseEnter
• %EZ_HotMouseLeave
• %EZ_FormSizable
• %EZ_TextUpdated
• %EZ_AttrUpdated
• %EZ_ColorUpdated
• %EZ_FontUpdated
• %EZ_SelUpdated
• %EZ_ClearUpdated
• %EZ_BitmapUpdated
• %EZ_IconUpdated
• %EZ_CmpSet
• %EZ_CmpGet
• %EZ_OwnerDraw
• %EZ_OwnerSize
• %EZ_NoCustomDraw
• %EZ_CustomDraw
• %EZ_EraseBG
• %EZ_PaintSP
• %EZ_EraseSP
• %EZ_Thread
• %EZ_ThreadP
• %EZ_ThreadCode
• %EZ_Post
• %EZ_Collapse
• %EZ_Expand
• %EZ_Selected
• %EZ_SMSelected
• %EZ_MenuClose
• %EZ_MenuShow
• %EZ_UnSelected
• %EZ_Terminate
• %EZ_ScrollBG
• %EZ_ScrollBGKey
• %EZ_DragItemID
• %EZ_DragItemDraw
• %EZ_NoLeftSize
• %EZ_NoRightSize
• %EZ_NoTopSize
• %EZ_NoBottomSize
• %EZ_MinMax
• %EZ_EditSetSel
• %EZ_SaveSetSel
• %EZ_LVClickInfo
• %EZ_LVDClickInfo
• %EZ_SetODChildID
• %EZ_FindDlgTerminate
• %EZ_FindDlgFindNext
• %EZ_FindDlgReplace
• %EZ_FindDlgReplaceAll
• %EZ_ShowCommonDlg
• %EZ_ChildFocus
• %EZ_ChildNoFocus
• %EZ_ChildReturn
• %EZ_ChildEscape
• %EZ_ChildShow
• %EZ_ChildHide
• %EZ_ChildUpdate
• %EZ_NoTheme
• %EZ_NoVirtualSize
• %EZ_SysChange
• %EZ_PTimer

If you consider my comments about how one converts API messaging to an Event oriented engine, this is why I built a GUI framework rather than simply a GUI library. I had to build an event engine which would do all the extra work to generate all these events.

Sorry about them not being in alphabetic order, since I just copied them out of products include file.

John,

Rather than post lots of opinions, why not post something more constructive. Opinions are cheap, why not instead:

• Post some examples of thinbasic code for the benefit of others
• post some explanations about complex programming subjects (ie. the WIN32 API)
• teach something useful, such as how to solve a particular problem

You may not like what others say or do and you have the right to your opinion, but why not for once post something constructive rather than destructive.

I would appreciate if your controls would have properties- and that is not difficult to achieve - even if no oop-langauge. The events is a class higher- Your designer is great- no doubt. I just miss the possibility to change properties of once designed objects - did I overread something? I tried to change the caption of a simple button when I click it- but I had to give up because I did not find any explanation how to- otherwise I could certainly have done it. But honestly: This is not the commercial product- so I can not really compare. But if I would get this as a try-out-version - I would not buy it. It's a lot of work to do it better than that- in any case. But since I have no time pressure I would save myself the money and would have the fun to create it myself (no offense- please do not understand wrong- I'm just a lazy end-product-user as lots of them out there. I'm trying to create some TB-GL-UI myself and I was nosy how you did it (now it's admitted) and I would not dare to sell my stuff - I'm hobby-user- and I make my stuff available to all other hobbyists out there because I lke the attitude of providing informazione for everyone and exchange experience for free ( No fear- your stuff stays here or gets deleted eventually but never gets out here unasked nor unpermitted - and your approach is certainly no model I would copy) . Maybe you take this as a hint to improve - or the version I saw was just a "reduced snoop'in preview" - but honestly: I would not spend the money for it. The stuff I made myself is already much easier to handle (except your designer- which is great and where you are way ahead - but the events are petty) but currently I search for some way to create UI-controls that are important but secondary ( I want to concentrate on other stuff) and I don't see any reason to chagrin myself with that, so currently I'm coding nothing but wait for Eros to release long desired 1.9.8 with loads of fixes and new functions ( sadly probably without this one) . So the worlds faith lays in Eros hands :D

EDIT: I already used up more than 1 and 1/2 hours to reply so there are posts I did not read when I posted...so I have to check out- maybe next post follows ( if it's not just John that posted his unasked opinion ;) )

OK- John- you're right- without reading your post - I know you have the right - you have the right to be right- you're an american and those deserve their rights naturally- others have to fight for them and don't desvere the freedom without the battle because their ancestors are no immigrants in a foreign country that killed the native inhabitants... so much for that- we're still talking about ezgui here... if you like it or not- please open your own thread if you want to get rid of your JS-Special-B.S.

Rene,

The DDT Designer you downloaded does not use a property list for changing properties. Instead you double click the control to display a full property dialog instead where you can change the captions, colors, fonts, etc.

What I was referring to about not being able to change properties after a control is created was refering to the runtime when an app runs and you want to change properties while the control exists. The designer gets around this when you click apply in the property dialogbox by simply recreating the control using the changed properties.

Most people are used to the Visual Basic style designer environment and expect a property list. My designers instead expect you to double click a control to display a property dialog, which is more suited to the complexity of properties and options which need to be set (especially is this so in my commercial product).

Actually, my 5.0 product does now have a small property list for common properties, but also uses the double click to display the more complex property dialog.

One thing about EZGUI 5.0 Pro is that it has a drag and drop engine built in. This means it could be used to build your own visual designer and it does all the hardwork. It would be nice to see someone build a full blow drag and drop environment for ThinBasic using it. It can do all the drag and drop stuff, has its own property list control too and all that would be needed would be a code editor control, like the one used in ThinAir. EZGUI supports third party controls in DLL format, so one could use such a code editor control with EZGUI.

I have noticed that one of the biggest issues with many independent BASIC languages (free and commercial) found on the web is the challenge of building a true drag and drop environment for development. There are a number of code editor controls available, but no drag and drop engines. EZGUI was designed so you can build your own tools and build WYSIWYG style applications.

My own commercial designer does not utilitize the property listbox control as much as I would like, but that is because I didn't want to rebuild the designer from scratch, but continued to improve the existing designer over each generation. I have been using property dialogs rather than property lists for some time in the product. This does not mean though one could not build a designer which trully emulates a visual basic like environment using EZGUI. It only lacks the code editor control, but there are a some excellent freeware ones available, which one could use.

I would love to see a full blown drag and drop environment built for Thinbasic.

I don't have the time to spend building one myself, but if any EZGUI user desired to do so I would be happy to be of some support to them to help them build it.

No- in-designer mode is really easy and very clear how to change properties of "objects" as controls. I'm complaing I can not find any possibility to change properties (as a caption) in Run-time. So either they are undocumented - (and I can not do anything about this then since I don't know function names to change them) or if they really were static - they are of no real use but just nice to look at once.

Rene,

Maybe check out some videos I have on my youtube channel. They provide a better understand of what EZGUI can do and how its designer works.

Designer tutorial #1: http://www.youtube.com/watch?v=QiB8BJG4Cnk

Designer and ownerdraw: http://www.youtube.com/watch?v=y0iuwC5k64U

Designer Visual Bookmark feature: http://www.youtube.com/watch?v=KadElIm940E

Working with Tab order in Designer: http://www.youtube.com/watch?v=FSB7fo6O_Gw

Project Palette window in designer: http://www.youtube.com/watch?v=uQ78B9plx3g

Using layers in the Designer: http://www.youtube.com/watch?v=BmWbCRFVMIM

Using user designed custom controls in designer: http://www.youtube.com/watch?v=SbX8dwa3-Xk

All the controls supported by the designer: http://www.youtube.com/watch?v=cY2oZbMHoiM

Some of the runtime features: http://www.youtube.com/watch?v=RZDnxwsceOI

Wow !

I simply posted links to my videos in the above post. I didn't expect the forum to embed the videos automatically.

Sorry about that. Looks a little overwhelming.

Rene,

The DDT designer you downloaded only is for generation of the UI. It was expect that users would be familiar with the DDT command set for changing things like text in a control at runtime, so it is not documented. I assume thinbasic has something similiar to PowerBasic DDT.

In PowerBasic to set a controls caption for example would be like this:

Code:

---

CONTROL SET TEXT hDialogHandle&, ControlID& "Some text"

---

In the commercial product to work with controls there is an EZGUI command set based on the runtime engine.

In EZGUI 5.0 Pro you don't use handles for dialogs (forms). Instead all forms are referenced by a name.

For example, the create a Form would look like this:

Code:

---

EZ_Form "MyForm", "", "My caption text", 0,0, 60, 20, "C"

---

To change the forms caption text would be done like this:

Code:

---

EZ_SetText "MyForm", 0, "My new caption text"

---

To create a button control would be like this:

Code:

---

%MYFORM_BUTTON1

---

Code:

---

EZ_Button %MYFORM_BUTTON1, 30, 10, 20, 1.5, "I am a button", "T"

---

To change the buttons text would be like this:

Code:

---

EZ_SetText "MyForm", %MYFORM_BUTTON1, "Some new text"

---

For example to add items to a listbox would be done like this:

Code:

---

EZ_AddItems "MyForm", %MYFORM_MYLISTBOX, "Apples|Pears|Oranges|Peaches|Grapes|Watermellons|Lemons|Limes|"

---

Forms have names and controls have ID's (numbers) which can be represent by a constant if you like.

It is like how we have Street names, but houses have numbers. In EZGUI Forms are like streets (with names) and the controls are like the houses (with numbers).

Now I read post 4 above: You're right about dot-net. that's why I say vb6 is best what MS ever released- all others as vb-dot-net equals with Johns opinions :) I was angry that MS went the dot-net-way- there was the direct (x/input) way open in 2003 also- but they went the .net-way... instead of going for the grail... dot-net is as cumbersome as callbacks... so OpenGL overtook in easy handling when Vista and 7 were released. But there's no language that comes close to vb6 (only basic4Android can stand the competition - and getting better) on windows-systems for my kind of there's currently nothing better than thinBasic available- I searched long and I was willing to pay a few bucks if it were good- none can fulfill my expectations. TB has greatest core and cool 3d - but UI is currently... lets say sumptuous... There's a big gap on the windows-driven-desktop-pc-market that no available language is able to satiate - MS trapped themselves caught between MS Small Basic and vb.net which both are far away from main-stream (where the money is) - either for minimalists or (free vb-net-express) for pro-professionals that code for a living and have to deal with the stuff that MS commits or are willing let MS overtake their computers ( on Win8 you have no more rights- you have to ask MS before you install software and have to accept any of their updates unasked...- just kidding!) but they left a large hole when they stopped support for vb6 because they did not release any better follower but just filthy dot-net which is cumbersome dirt-crap that none wants to use if not urged to with a shotgun :D

until I was done writing my posts there are a few more already- I have to study at least half of them :D

Edit: Thanx for the videos- but your designer is that easy- no video needed. Designer is well documented - and I found everything but the button to create app without help. The problem is on the other side (while runtime) - i have not found any explanation how to change caption or size of something...I just wanted to see if my button-click gets recognized- but it does not even END if I write END into the Button-Click-Event. And END is valid pb-method to end program as in the good old times

Quote:

---

Originally Posted by Chris Boss

...
In PowerBasic to set a controls caption for example would be like this:

Code:

---

CONTROL SET TEXT hDialogHandle&, ControlID& "Some text"

---

---

???

this can not be called easy.
Easy would be:

Code:

---

myButton(123).Caption = "some new caption" ' (within same code unit)
' at maximum:
myDialog.myButton(123).Caption = "another caption" ' ( from other unit/module/anywhere)

---

The time has come...
tick tack...
please Eros remove this idiot one and for all from this forum ...:D

Rene,

As a VB 6.0 user you find this blog article of mine interesting:

http://cwsof.com/blog/?p=608

The title is:

Classic Visual Basic’s end marked a key change in software development

Now as far as my commercial EZGUI product (EZGUI 5.0 Pro) is concerned, those who have never used it just don't grasp the power of this tool.
The power is in the GUI engine, not the designer.

John is incorrect in calling EZGUI too low level. The new Designer is very good and is a decent RAD tool, but the real power is in the GUI engine and that is not entirely low level. It does have low level stuff so you can do almost anything (by customizing), but it has many very high level features, you won't find in the PowerBasic compiler nor in any other RAD tools for PowerBasic.

The 2D Sprite engine for example is very powerful.

The 3D scripting language for its OpenGL based 3D control is very, very powerful. For example it can load STL 3D models (3D printing model format) with millions of polygons in a few seconds and displays them instantly.

For example:

Attachment 8526

This model has over 138,000 polygons in it and it loads and displays instantly.

Unlike gaming model formats which are low polygon count models which fake realism using quality texture maps and shaders, EZGUI gains realism, even in a single color, with models because of the high polygon count. I have loaded models with over 2 million polygons in a few seconds and they display instantly.

It is these kind of things which make my product different. It is more than a visual designer.

Begin off topic

Quote:

---

Unlike gaming model formats which are low polygon count models which fake realism using quality texture maps and shaders

---

This is currently changing, with more horse power it was not rare to see just characters modeled with 50 000+ polygons 3 years ago... 2 last GPU generations with tesselation units can pump it up even more. With dawn of physically modeled materials there is lot of nice things to look forward in gaming arena ;)
But I agree everything rasterization based is faking by nature, that's what makes it fun to code hehe.
End off topic


Petr

yes- we got a little away from ezgui here- very interesting reading on your site- and not just the vb-article. There were a lot of unaccomplished promises alike "OK, we create another language that will be as easy as classic vb and it even will be built-in to Windows8" - what did they do? "MS Small Basic" - supposed to be "a language for beginners" but is just another MS-crime... enough about that...

Thank god there's such thing as thinBasic - otherwise I probably would have given up on coding already and just play games - My "current project" is to create some multiple useable GUI to TBGL: I have it done in "manual mode" already but the difficulty is for the visual-design-mode I need to use "UI"-module mostly because the designer should not use the user-chosen fonts in the designers menus, tools, property-lists, trees etc. And there's the hook- everything else I get done without any problem - I have my very own windows inside TBGL-window- with controls, menus, focus, zorder, properties and events -all written by myself- but when it comes to use callbacks and UI-controls, that have no real properties which can be set, but just a dozen different handles - I'm screwed.
Now I await yearningly next tB-version because I want to rewrite it using some new memory-functions that will save lots of currently useless allocated meemory since I used some Union for all controls- means a small Timer-control with just 2 Properties - 8 Bytes needed - allocates the same memory as a treeview - which needs a few hundred bytes. Thereafter I want to start again creating some visual designer for my "in-TBGL-window-windows" which has to be done using real windows-controls.

Thats why I was nosy how EZGUI works - if it probably creates "pseudo-classes" that make those dialogs & controls some kind of objects and generates clearly defined events so one does not have to bother with "the stuff underneath".

Because thinBasic already has a lot of useful core-functions to emulate objects (this still missing for perfection) and already has a lot of controls available in "UI"-Module, I think it would be possible to create some "UIPlus"-extension-module for the lazy ones, which provides some visual designer including a code-skeleton-generator for rapid-application-developement - even without having real objects nor classes and supports the user-written-code with some automatic parsing callbacks to events, updating changed properties etc.

Eros already did an important step lately, adding Dialogs-names - which are part of later functions- & properties- i.e. "private" variables-names. UI as currently is, can still be available for users that love to use callbacks or want to keep their apps small & "cpu-usage-footprint" low - whatever that means - in my apps using UI with more than 2 controls always ends up in an unreadable large noodle of code.
I imagine it would write one "Ini-File" per Dialog that just holds the dialogs & controls names & layout ( so they can easy be reused or changed) and a code-generator that just generates a new or browses some existing script for function-names and adds the missing or the needed Ini-file-names (if more dialogs added) to some "protected" TB-UIPlus-StartUp-Function which overrides TBMain if present.
Maybe it can be set during design to some Property-List which default-events to generate - and still be possible to add/remove them later manually.

It would be a big win-win-situation because all users would not just gain the time, that they would need to create all this repeatedly used stuff over and over again but also the time they need to learn and understand stuff that they're not really interested in. Some astrophysician might want to write some table about the moon influencing asteroids that will hit the earth - but if he had to understand what microsoft comitted :comp1: before he can start to write it might be too late...
It probably will attract a few others to use tB for creating their windows-apps - because its so fast 'n easy.:comp5: In any case they could create their stuff in less time, which means they can eventually create more apps during their lifetime - and life is short - so have to begin as soon as possible and in any case before that asteroid hits the earth.

Open Source does not make a development system any better than a commercial tool. What matters it the organization behind the tool. Few opensource software projects have real potential unless they have a large organization behind it which has some resources behind it. One good example is Blender. Very good organization behind it.

Now while I am sure Oxygen is a great tool, it is just a one man operation like many other open source software projects and the commitment, while there today, could easily be gone tommorrow. At least when software is built by a small company (or one person) when it is a commercial operation, it has a greater chance of commitment since they depend upon it for a living and it won't be just dropped if they lose interest.

The truth is that no software company is guaranteed long term success. Among small businesses, the majority fail in time. This is just a fact of life. Among large companies, a few wrong choices and even they can at minimum lose market share or even fail. Look at Apple. They almost went bankrupt at one point and if Microsoft hadn't helped bail them out, they may have.

And even of the software developer stays in business, they may make choices at one point which can overnight make there software obsolete. Look at classic Visual Basic and all the resources invested in it by developers and when Microsoft just dropped it in favor of managed languages (aka. VB dot.net), it nearly destroyed thousands of developers who could not make the switch to dot.net.

So what is a developer to do ?

Make choices which work for them, at least for the next couple years. If PowerBasic disappeared today, I would have at least 3 to 5 years before I felt the loss from it. Why ?

Because I write for the WIN32 and know how to leverage it so I can write apps for all versions of Windows. The WIN32 isn't going anywhere anytime soon. But what about my potential customer base ?

I have already started to make the shift from a tool developer to a developer for consumer apps. The market for addons for anything but the "big" development tools (aka. Visual Studio) is small at best and limited in scope. Now, actually if PowerBasic were to disappear today, it would actually likely benefit me to some degree, since existing PB'ers would be looking for resources , no longer available from PowerBasic and I would likely be one of the few third party developers who has one of the richest set of resources which could be turned into all sorts of tools for PB. I could break up EZGUI into smaller tools if I wanted to. The point is, there would be some kind of market for me for at least a few years, giving me time to find alternative markets. I am also current researching options for developing end user apps, which won't be limited by whether PowerBasic exists or not.

In all honesty, I rarely need any of the new features in each new iteration of PBs compiler, because I can write most advanced features myself. I don't need DDT. I don't currently need the COM, but may use it in the future. I don't need the PB graphics or print engine. Actually PowerBasics new GUI features have always been behind what I have been doing.

Yet the quality of their compiler can last me for years to come. EZGUI 5.0 almost was written in PB 6.1, rather than a later version, but the only reason I switched was because I tapped out the limits of the 6.x compiler (just too much code to compile). I then switched to PB 9.x for EZGUI 5.0 and it should be good for me for at least the next five years or so. I also have PB 10 too, but am only using it to write SLL's write now.

My goal right now is to switch to consumer apps, rather than tools, but keep my tool development going as an aside, rather than the primary thing. I will need better stuff for building consumer apps, so I will continue to improve EZGUI and I will make the new versions available to my existing customer base (and any new ones, as long as PowerBasic is around). My customers using EZGUI make it better, because they provide valuable feedback about it and test it to the limit. This will make any consumer apps I develop better, because I too will use my own development tools for such software.

I really don't think a compiler like Oxygen is really a decent replacement for I currently have. All I would need is a few core features missing and I would just have to wait until its developer added the features. I don't need to be a beta tester for an open source developer right now. I need a dependable programmign language with a solid history. OK, PowerBasic (the company) is not perfect and at times they have made mistakes, but who hasn't ? Unless you are one of the big guys (Google, Microsoft, Apple) , all software companies face big challenges.

As for OpenSource, it has one big problem !

It is FREE !

Yes, that is a problem for one important reason. Those who use OpenSource tend to always want things free, which means they tend to not want to pay for any software. This is one reason why Linux has been hurt. One programming language developer , who use to write a compiler for Linux and Windows (cross platform), told me that Linux was a problem because they want everything free and it was hard to sell that market a compiler, when they could get one for free. He wanted to switch to a purely Windows compiler , which is why we talked because he was considering getting me to to help with a GUI engine (he was using a cross platform engine). Sadly he died a number of years ago and nothing became of it for me, but I learned something valuable from my conversation with him.

FREE (or OpenSource) doesn't always mean better. The old saying "you get what you paid for" holds true.

I have paid good money over the years for the PowerBasic compilers (and have even had some happy customers get together to buy me one version too) and have never been disappointed. I got what I paid for, a quality native code compiler. I am not a C programmer and I dislike the dot.net stuff, so BASIC is my primary language of choice and PowerBasic is my primary BASIC compiler of choice.

Quote:

---

Originally Posted by Chris Boss

... Unless you are one of the big guys ...

---

No- we're certainly not. But there's a lot of folks left in the dark since 2008 - when MS dropped supporting classic vb. Folks that as myself never could become friends with dot-net that urgently search and only find on android-systems.Or in tB - I'm screwed because I bought a Windows8-computer that is so much married with Win8, that if the harddrive dies (partition D: on main-drive) - it'll be of no use any more since a win8-update to newest standards will take 7 GB or 1 and a half days to update...and not be possible with a dead HD, ...the only way will be switch to linux then. But as someone not mentioned said: tB is running fine on "wine" :D