GUI windows in LB v.4.5.1 - for beginners

[bushrat]

I'll restate the title of this post - it's for beginners, I'm one myself - I'll also state I am not an expert in anything.

This thread is intended to be a collection of posts originally posted under "Liberty BASIC v.4.5.1." and "LB v.4.5.1. Installation"
I thought I'd assemble the GUI posts there under a title more reachable for those like myself who are/were struggling to get a handle on LB GUI windows. Not that the LB documentation doesn't explain it but there are a few aspects of GUI window programming which for beginners need emphasising.

The GUI window is a very neat way of collecting information from the user about initial variable values, ranges of variable values etc. all of which were previously handled by input statements. You can't go wrong with input statements you can go wrong with GUI windows protocols unless you learn their fundamentals.

I'll start off soon with a simple example of an LB GUI window using 'statictext' statements only, but also using the commands 'trapclose' and 'wait'. The form and location of these in the coding were my biggest stumbling blocks to writing the code for my first attempts at LB GUI windows.

'trapclose' and 'wait' preamble.
--------------------------------
As a beginner I saw both 'trapclose' and 'close' commands used in LB GUI window coding. I wondered why both were necessary. It turns out when using LB you are indirectly interacting with both Microsoft Windows routines and Liberty Basic routines - with any language running under MS Windows you are always doing that, but LB has a very close relationship with MS Windows especially where LB GUI windows are concerned. I'm guessing that LB is accessing MS Windows own window generation routines to produce what you see as your 'LB window'. So there are two 'systems' you need to communicate with to write your 'LB window'. This is why both commands 'close' and 'trapclose' are necessary.

'Close' tells MS Windows the program wants to close a file (I'm presuming it's MS Windows which is really doing the file handling) whereas 'trapclose' tells LB the program wants to close the file. Both systems need to be informed of these program commands.

'Wait' - is a command with a very wide scope. It tells MS Windows/LB to halt, stop dead, and wait for an input device to signal something (an input event). That something could be a keystroke on the keyboard, a mouse click on a button, etc. which is immediately identified by the event handler and directs/redirects program control accordingly.
It is important to understand the consequences of issuing a 'wait' command are not necessarily tied back to the point in the program where the 'wait' command was issued. There could be many 'wait' commands in a GUI coding and depending on the specific input event, program execution could resume in many places.

So 'wait' is a kind of synchronous interrupt. It is puposely injected to achieve some specific redirection of program control at that point in the program. In case you're not aware, MS Windows and all operating systems are constantly listening for interrupts. Say the user issues a 'CTRL C' at some random point while a program is running, then (sometimes, but never on my machine) the running program will terminate. This would be an asynchronous interrupt. If operating systems didn't constantly listen for and respond to interrupts nothing would ever get done.

All that said, let's return to a simple LB GUI window.

A handy GUI.
============
I use 'Confirm' and 'Notice' commands a lot of the time, but they are not always appropriate. Once issued they won't let you get past them until you've given an answer at which point any screen output is lost?
The following GUI window lets you examine displayed results during a running program, print a hardcopy if desired, and decide whether you wish to continue the program with displayed results.

'program: Random shopping list.
'=====================
[reStartProgram]
for i=1 to 6
q(i)=int(rnd(1)*9)+1
next i
print "shopping list"
print "-------------"
print q(1); " party hats"
print q(2); " sausages"
print q(3); " hamburgers"
print q(4); " buns"
print q(5); " beers"
print q(6); " hand grenades"
print "(stay away from my parties...)"

'GUI 'Halt'
'==========
WindowWidth = 340
WindowHeight= 200
UpperLeftX=320
UpperLeftY=80

statictext #inspect, " Halt for shopping list inspection.", 45, 25, 300, 15
statictext #inspect, " ------------------------------------------", 45, 40, 300, 15
statictext #inspect, " Use 'File/Print' at this point for a hardcopy of shopping list", 30, 60, 400, 20
statictext #inspect, " then bring up this window to continue the program.", 30, 80, 400, 20

button #inspect,"Continue",[okInspect],UL,120,115,80,35

open "Halt" for dialog as #inspect '<-- think of the window #inspect as a file
#inspect "trapclose [exitInspect]"
wait '<-- run without the 'wait' and see what happens...

[okInspect]
close #inspect '<-- command to MS Windows - close #inspect
goto [reRunProgram]

[exitInspect]
close #inspect '<-- command to LB - close #inspect - END of GUI window.


[reRunProgram]
cls
confirm "Do you accept the shopping list?"; answer$
if answer$="no" then [reStartProgram] else goto [guestList]

[guestList]
print "Guest list"
print "----------"
print "Jane"
print "Suzy"
print "Ruby"
print " - they should be enough.. "
print
print "endRun"
end

I'm not going to discuss the window dimensions/positions or syntax of the 'statictext' commands they are clearly explained in tutorials and LB 'Help' - except to mention they must come before opening the dialog.
There is only one 'wait' command in the above so there is no confusion about where the program will halt and it's the mouse click on the button which reactivates the program after the 'wait' command.

That wraps up the first post in my GUI windows series. Feel free to comment. I know the above coding is rough but wanted to keep the GUI window as uncluttered as I could. Also I haven't yet figured how to properly insert code into posts, so to run the above you'll have to copy and paste as a new LB program file.

[Rod]

Liberty is an event driven BASIC. Interrupts if you like. You create an event and define the code block that will be called. So trapclose [close] sets up the windows close click event and [close] will be called when this happens. Equally timer 100,[cycle] sets up a timer event that will be called every 100ms and [cycle] will be called.

Keypresses,timers,buttons,mouseclicks and more are all events that can be caught and handled.

Your program will check for events having fired at only two points, SCAN and WAIT. WAIT is most useful as the program simply sits where it is and waits for an event to fire. SCAN checks on the fly whether events are outstanding.

The simplest programs have several code blocks for handlers that end in a WAIT statement. Code that loops can better use SCAN.

[Walt Decker]

As presented, the example code will not work. Each of the controls requires a unique tag(name) subtended to the form name, e.g STATICTEXT #FOO.STA1, STATICTEXT #FOO.STA2.

[tsh73]

It does work - but only because nothing is ever done with these controls.
Which is pretty often the case for statictext

[Walt Decker]

Jun 30, 2023 10:16:23 GMT -5 tsh73 said:

It does work - but only because nothing is ever done with these controls.
Which is pretty often the case for statictext

That is not the point.  Supposedly this is for beginners.  As such sample code should be correct.  None of the controls are correctly formatted.

[bushrat]

Jun 30, 2023 12:40:57 GMT -5 Walt Decker said:

Jun 30, 2023 10:16:23 GMT -5 tsh73 said:

It does work - but only because nothing is ever done with these controls.
Which is pretty often the case for statictext

That is not the point.  Supposedly this is for beginners.  As such sample code should be correct.  None of the controls are correctly formatted.

I accept your criticism - so please show everyone how it should br written.

[Walt Decker]

Your code corrected.

'
'program: Random shopping list.
'=====================
[reStartProgram]
for i=1 to 6
q(i)=int(rnd(1)*9)+1
next i

print "shopping list"
print "-------------"
print q(1); " party hats"
print q(2); " sausages"
print q(3); " hamburgers"
print q(4); " buns"
print q(5); " beers"
print q(6); " hand grenades"
print "(stay away from my parties...)"

'GUI 'Halt'
'==========
WindowWidth = 340
WindowHeight= 200
UpperLeftX=320
UpperLeftY=80

statictext #inspect.h1, " Halt for shopping list inspection.", 45, 25, 300, 15
statictext #inspect.h2, " ------------------------------------------", 45, 40, 300, 15
statictext #inspect.h3, " Use 'File/Print' at this point for a hardcopy of shopping list", 30, 60, 400, 20
statictext #inspect.h4, " then bring up this window to continue the program.", 30, 80, 400, 20

button #inspect.cont,"Continue",[okInspect],UL,120,115,80,35

open "Halt" for dialog as #inspect '<-- think of the window #inspect as a file
#inspect "trapclose [exitInspect]"
wait '<-- run without the 'wait' and see what happens...

[okInspect]
close #inspect '<-- command to MS Windows - close #inspect
goto [reRunProgram]

[exitInspect]
close #inspect '<-- command to LB - close #inspect - END of GUI window.

[reRunProgram]
cls
confirm "Do you accept the shopping list?"; answer$
if answer$="no" then [reStartProgram] else goto [guestList]

[guestList]
print "Guest list"
print "----------"
print "Jane"
print "Suzy"
print "Ruby"
print " - they should be enough.. "
print
print "endRun"
end
'

A different way

'
'program: Random shopping list.
'=====================
CR$ = CHR$(13) + CHR$(10) '<--- carriage return + line feed

'[reStartProgram]
DIM q(5)  '<--- arrays start at zero; zero to 5 = 6 elements

GOSUB [READ.SHOPPING.LIST]
GOSUB [BUILD.HALT]
[reStartProgram]
wait '<-- run without the 'wait' and see what happens...

[okInspect]
'close #inspect '<-- command to MS Windows - close #inspect
goto [reRunProgram]

[exitInspect]
close #inspect '<-- command to LB - close #inspect - END of GUI window.
END
[reRunProgram]
confirm "Do you accept the shopping list?"; answer$
IF answer$="no" then
 CLS
 GOSUB [READ.SHOPPING.LIST]: GOTO [reStartProgram]
ELSE
 CLOSE #inspect:  GOTO [guestList]
END IF

[guestList]
CLS
print "Guest list"
print "----------"
print "Jane"
print "Suzy"
print "Ruby"
print " - they should be enough.. "
print
print "endRun"
end

[BUILD.HALT]
'GUI 'Halt'
'==========
WindowWidth = 340
WindowHeight= 200
UpperLeftX=320
UpperLeftY=80

statictext #inspect.sta, " Halt for shopping list inspection." + CR$ _
                       " ------------------------------------------" + CR$ _
             " Use 'File/Print' at this point for a hardcopy of shopping list" + CR$  _
             " then bring up this window to continue the program.", 45, 25, 300, 110

button #inspect.cont,"Continue",[okInspect],UL,120,115,80,35

open "Halt" for dialog as #inspect '<-- think of the window #inspect as a file
#inspect "trapclose [exitInspect]"

RETURN

[READ.SHOPPING.LIST]
for i=0 to 5  '<--- zero to 5 = 6
 q(i)=int(rnd(1)*6)+1 '<--- item number
next i

print "shopping list"
print "-------------"
print "Item "; q(0); " party hats"
print "Item "; q(1); " sausages"
print "Item "; q(2); " hamburgers"
print "Item "; q(3); " buns"
print "Item "; q(4); " beers"
print "Item "; q(5); " hand grenades"
print "(stay away from my parties...)"
RETURN
'

I would not do it either way. I would use SUB/FUNCTION procedures instead, but that is just my coding style.

[bushrat]

Thank you for corrections.

I completely accept your POV that if someone is showing others examples of how to do something then such examples should be formally correct.

What I'm trying to do here is simply relocate GUI posts from the earlier thread 'LB v.4.5.1 Installation' to maybe help others find GUI stuff that could help them.

I don't know why but I'm still not comfortable with GUI coding even though I've reread a lot of posts on the topic and have received some great pointers from Anatoly, Rod etc.

It's not as if I'm a beginner as regards coding generally but GUI stuff is really tripping me up.

[Walt Decker]

If you have ever programmed in a language in which you have to write your own callback function(s) and message pump(s), it should not be difficult. The code you create in LB is almost equivalent to a callback function which is really just a message trap. Based on the message trapped in the callback function, your code performs some act.

What you are doing in LB code is telling the LB runtime engine where to go in your code in response to an event. The events generated are dependent on the controls you define in a form window.

These controls, in LB, create events:
'

MENU (actually a bunch of buttons)
BUTTON
radio button
check button (checkbox)
image button (bmpbutton)
LISTBOX
COMBOBOX
GRAPHICBOX (LB propritary control based on a static control or a child form)
TIMER (a control, but not placed in a form)
'

The "WAIT" instruction tells the LB runtime to activate a wait event handler. This, in essence, pauses application execution until an event occurs. It also caches multiple events and executes them until the event cache is empty.

The "SCAN" instruction tells the LB runtime to inspect the event cache. If an event is pending, the event is executed and then returns to the code immediately following the "SCAN" instruction.

Clear as mud.

[alincon]

Do you mean 'cache' instead of 'cash'?

r.m.

[Walt Decker]

Fixed. Thank you. I am almost blind so I often miss things.

[Walt Decker]

Many times the controls that generate events are not immediately queried for their state; their state is queried only in response to a master control event.

The below code presents one way to accomplish this objective.  Bear in mind that there are better ways to accomplish this.

'
DIM Fruit$(3)
DIM Meat$(3)

Fruit$(0) = "apples"
Fruit$(1) = "cantelope"
Fruit$(2) = "pears"
Fruit$(3) = "grapes"

Meat$(0) = " chicken"
Meat$(1) = " halibut"
Meat$(2) = " hamberger"
Meat$(3) = " elephant hoof"

'########################################################################
'  Since the result of an event generated by the following controls is
'  going to be queried after the fact, they all jump to the same code
'  block.
'
'  There are better ways to do this, but this gives you an idea of how
'  to achive this particular objective.
'########################################################################

RADIOBUTTON #DMO.RDOY, "YES", [RDO.BTN], [RDO.BTN], 5, 5, 60, 20
RADIOBUTTON #DMO.RDON, "NO", [RDO.BTN], [RDO.BTN], 5, 30, 60, 20
RADIOBUTTON #DMO.RDOM, "MAYBE", [RDO.BTN], [RDO.BTN], 5, 55, 60, 20

CHECKBOX #DMO.CHKA, "DO YOU LIKE THIS APP?", [RDO.BTN], [RDO.BTN], 5, 85, 160, 20
CHECKBOX #DMO.CHKS, "WOULD YOU LIKE MORE?", [RDO.BTN], [RDO.BTN], 5, 110, 160, 20

LISTBOX #DMO.LST, Fruit$(), [RDO.BTN], 5, 135, 90, 60
COMBOBOX #DMO.CMB, Meat$(), [RDO.BTN], 5, 200, 100, 120

BUTTON #DMO.BTNINFO, "APPLY", [APPLY.BTN], UL, 110, 220, 60, 20

OPEN "CONTROLS" FOR WINDOW AS #DMO
#DMO, "TRAPCLOSE END.DMO"

[BEGIN.WAIT]
WAIT

'--------------------------
'--------------------------

SUB END.DMO DmoHndl$

CLOSE #DmoHndl$
END
END SUB

'--------------------------
'--------------------------

[RDO.BTN]

GOTO [BEGIN.WAIT]

[END.RDO.BTN]

'--------------------------
'--------------------------

[APPLY.BTN]

Choice$ = ""
Item$   = ""

#DMO.RDOY, "VALUE? Choice$"
IF Choice$ = "set" THEN PRINT "YES"
#DMO.RDON, "VALUE? Choice$"
IF Choice$ = "set" then PRINT "NO"
#DMO.RDOM, "VALUE? Choice$"
IF Choice$ = "set" THEN PRINT "MAYBE"

#DMO.CHKA, "VALUE? Choice$"
IF Choice$ = "set" THEN PRINT "YES"
#DMO.CHKS, "VALUE? Choice$"
IF Choice$ = "set" THEN
 PRINT "MORE COMING"
ELSE
 PRINT "UNDECIDED"
END IF

#DMO.LST, "SELECTION? Item$"
PRINT "SELECTION IS "; Item$
#DMO.CMB,  "SELECTION? Item$"
PRINT "SELECTION IS "; Item$

CALL END.DMO "#DMO"

[END.APPLY.BTN]


END
'

[bushrat]

just a quick ongoing comment...
All replies have been very helpful I am learning a lot from all your posts/comments.
It's so much better to be in a position where you actually know what you're doing rather than following a slab of code from a 'similar' program which appears to work - though mysteriously...

Following Rod's suggestion I've dumped radiobuttons in favour of ordinary buttons and the code is much cleaner and understandable.
I'm in the middle of writing the real program I'm attempting to write, it's quite large and is taking some time to complete.
When it's finished I will return to my original idea of gathering together the GUI stuff I got tangled up with.

Anatoly was quite right when he commented that you learn a lot when trying to teach others, so maybe if some beginners have the patience to read through the successive posts they might see where I was failing and how various commentators offered great suggestions for improvements.

Many thanks to Rod, Anatoly, Walt.

[Walt Decker]

If you are confused concerning the Windows(tm) coordinate system, this might help.

The coordinate system is based on the monitor's visible screen size and is considered a virtual surface. Point x = 0, y = 0 is at the upper left corner of the visible screen and point x = max size, y = max size is at the lower right corner of the visible screen. Notice that I said the screen is considered a virtual surface. The reason is point x = -100, point y = 50 is considered valid; it is on the other side of the mountain so you can not see it.

Now, when a form is defined, it is in screen coordinates and takes the form x position, y position, width, heigth. So, what does that mean? If the position is defined as x = 100, y = 100 the upper left corner is placed at that screen coordinate. If the width is defined as w = 250, h = 375 the lower right corner of the form is positioned 250 units to the right and 375 units down from the upper left corner of the form or at screen position x = 350, y = 475.

A form has an area called the client area. This area is that part of the form that is not caption (the part that has the title and kill button), not menu (that part that has button that case a list of options to be displayed), and not border. Like the screen the client area is a virtual surface and emulates the coordinate screen coordinate system, that is, the upper left corner of the clinent area is a point x = 0, y = 0 is at the upper left corner and point x = max units, y = max units is at the lower right corner of the visable client area. Controls are defined exactly the same way as forms so a button with coordinates x = 5, y = 5, width = 60, height = 25 places the upper left corner at client area coordinate 5, 5 and the lower right corner at client area 65, 30.

Assume the form has a resizing border. Further, assume that the right edge of the button is 5 units left of right edge of the client area. Now assume that the form is resized in the horizontal direction. The client area of the form is also resized in proportion to the size of the form. Assume that the button is to be resized. The new size for the button is not the client horizontal size - 5 units. It is the client area x size minus the button x, y position - 5 units, i. e. clientsizeX - buttonposX - 5.

[Carl Gundel]

Jul 3, 2023 10:58:34 GMT -5 Walt Decker said:

The "SCAN" instruction tells the LB runtime to inspect the event cache. If an event is pending, the event is executed and then returns to the code immediately following the "SCAN" instruction.

Clear as mud.

I think the WAIT keyword is pretty clear, but perhaps SCAN is not so obvious.  It 'scans' the event queue without waiting, and if it finds an event then it handles it but if there is no event to handle then execution just continues on.