SpiderBasic BindEvent Command

by Paul F. Watson

Brilliant Programmers: I have met some brilliant programmers in my life -- men like Austin McConnell in Fort Worth and Fred Laborateur at Fantaisie Software. I regret that I am not one of these and struggle to understand what is so obvious to them.

I recently downloaded a free trial of SpiderBasic and ran into the “BindEvent” command - the likes of which I have never before seen. And from my 1980’s perspective, it is rather peculiar so I thought a brief article discussing "what and why" might be helpful for others like me. I emphasize that my understanding is tentative and primitive.

My Programming Background: I’m not a trained programmer, but a Mechanical Engineer who has found programming necessary throughout my life. As a result of the roads I have trod, I have programmed in FORTRAN, Basic, C, PHP, MatLab, Python and a bit of Java Script. So I try to understand new programming paradigms in terms of those experiences.

Event Driven Programming vs. GUI Driven Programming: A traditional event driven program has a block of code, followed by some data input requests. The cycle is repeated until all the data inputs are received and the program grinds out an answer. The structure looks like this:

Event Driven Program Structure

When a GUI based program is written (for example in Python using the PysimpleGUI library) the program needs a continuously running loop that checks all the GUI buttons for operator input at any time. Inside that loop, most programs will include a 2nd level GUI loop that checks for further user inputs, based on the 1st selection. The program structure follows:

Event Driven Program Structure

The program works like this: A very large “LOOP A” spans the entire program and continuously loops at it watches for user input from top level GUI controls. When the user “clicks a GUI command”, either LOOP B1 or LOOP B2 is executed depending on what was selected from the initial GUI loop. LOOP B1 checks for choices from a 2nd level menu.

Secondary loop B1 (or B2 depending on the selection) likewise loops continuously watching for user inputs to the 2nd level GUI controls. When the User clicks a choice, the B1 If statement executes a subroutine (procedure or function) which actually performs some desired computation, creates a graphic image or whatever. LOOP B1 usually has several different actions that can be selected, so “B1 If ...” will typically have several execution procedures chosen by If, ElseIF, ElseIF program logic.

For the traditional event driven program: Clean program blocks wait for needed user input and execute the intended actions. A very simple code structure results.

For the GUI program implementation, A very large LOOP A spans the entire program watching for top level menu GUI inputs.

The GUI structure thus results in a huge program loop that spans the entire program, with several nested sub-loops. Useful program computations “tumble out” of the secondary loops depending on choices made at the 2nd tier GUI controls

For C, loops are defined by {fancy braces} and it becomes very difficult to visually match up a {brace at the top of the program, with the bottom of the loop brace} 7 pages below. Multiple second tier loops make a further “mess” of the situation by scattering {braces} throughout the code. Even for the secondary loops, it becomes difficult to visually spot the bottom brace for a particular loop. While the code is perfectly logical, it becomes very difficult to understand. For simpler languages like Python, the loops are a little bit easier to see, but the fundamental problem remains.

We may conclude by saying that GUI program implementation inherently requires many nested loops which become very difficult to work with.

The BindEvent Alternative: Based on my “primitive” understanding of programming, I offer my concept of what the BindEvent command in SiderBasic does. The BindEvent command used in SpiderBasic provides an alternative to the massive and complex loop structures that seem inherent to GUI programming.

In effect, a single line of code [e.g. BindEvent(Event,@ProcedureName)] creates a massive loop that runs in the background, watching for various GUI events. This command includes a bit of program logic, because it is clever enough to watch for a specific GUI Event (such as click of a particular GUI button), and when such event occurs, the identified ProcedureName is executed.

If effect, the massive program control loops discussed previously are replaced by a single command line that continuously runs a GUI check in the background and executes a specific Procedure in response. It is a bit difficult to visualize what the program loops are doing when several BindEvents commands are overlapping, but the system does work, and it solves the confusion caused by massive and nested program loops.

Is the BindEvent Command Good? The BindEvent command obscures program logic; however, the “explicit loop alternative” discussed above is really difficult to work with. Yes it is logically clear, yet I still cannot understand what the program is doing. By contrast, the BindEvent command is a single code line who’s approximate effect is easy to understand. Faced with the alternative, I like it!

Does SpiderBasic Require Use of BindEvent? SpiderBasic includes a number of very nice commands that create GUIs, pull down menus, diplay graphics and sprites and load images. My limited experience with SpiderBasic indicates many of these commands are difficult to implement without the use of BindEvent commands. In conclusion, if you are programming in SpiderBasic, then you are married to “BindEvent” commands. The first time you try it, it can be frustrating but it is not that complicated. In the future, I will post a simple example of using “BindEvent” on the Computer Learners Page of www.dionysus.biz.

Dionysus.biz Home Page
Naval Research Page

Contact the author: paul-watson@sbcglobal.net by e-mail.

Copyright 2021 by Paul F. Watson, All Rights Reserved