Getting Started: Windows Programming

---

Basic Concepts of Event Driven Programming for Windows

---

PowerBASIC for Windows lets you write true Windows programs with all the Graphical User Interface (GUI) features (such as dialogs, menus, buttons, etc.) your users expect, using the BASIC programming language.

BASIC is BASIC, but the difference between operating systems such as DOS vs. Windows must be factored in. The part of your code concerned with variable assignment and calculations is pretty much the same between the two operating systems. The part of your code handling user and device interaction is not, because of the differences between operating systems. The most basic understanding you'll need is that the program is in charge of flow under dedicated operating systems and the user is in control under Windows. With Windows, your programming needs to account for and allow this.

If your programming experience with BASIC has been with dedicated operating systems such as DOS, you have been writing procedural code. Simply put, procedural code runs in a sequential fashion. The program begins processing, stops and waits for input when called for, and exits when the task is complete. The program is "in charge". The user must respond to the program in a strictly prescribed (by the programmer) manner.

A Windows program is structured differently. Rather than being procedural, it is event driven. Processing is done in response to events, and the events may happen in any order.

An event is best thought of as "something interesting just happened". Consider a Windows program that looks like this.

The user is in charge. They may fill in the fields (such as Name and Address) in any order. They may delete and re-type the content of a field. The Windows operating system handles the user interaction. Your program is waiting for something interesting to happen - an event - so that it can process accordingly. When the user clicks a button, "OK" or "Cancel", an event is passed to your program for it to handle.

To summarize, the parts of your programs that concern user or device interaction will need to be structured differently. You'll use the BASIC programming language to write event driven code, which operates differently than code written in a procedural manner.

DOS

Let's begin by looking at a program written to run on a DOS based system:

PRINT "Hello world!"

Now, DOS can only do one thing at a time. When your program runs, it is the only thing running on your system. You cannot access the command line while your program is running.

Windows, on the other hand, is a multi-tasking system. Multiple programs can run at the same time - in different windows. A traffic cop is needed to allow programs to start and end without disrupting other programs that may be running at the same time. That traffic cop is the Windows operating system! Any program you write to run under Windows must allow the Windows operating system to "be in charge".

If you are coming from the world of DOS programming it's best to think of Windows as the "main program" and your program as a subroutine to that main program. More accurately, your program is a function that Windows will perform.

The main program, Windows, runs constantly (in a loop) looking for things to do (events). The program you write (even if it is the greatest thing since sliced bread) is simply one of the tasks that Windows will perform.

FUNCTION PBMAIN

     MSGBOX "Hello world!"

END FUNCTION

We'll talk about MSGBOX vs. PRINT later. For now note that the program begins with a FUNCTION PBMAIN statement and ends with an END FUNCTION statement. This lets the Windows operating system "call" your program, execute it, and then let go of it. The FUNCTION PBMAIN statement is called your program's "entry point" and the END FUNCTION statement is your program's "exit point".

Events

Understanding how Windows "calls" your program is useful for understanding the approach you need to take to write programs for Windows. Starting with a simple diagram:

DO  WINDOWS MAIN LOOP:

    LOOK FOR THINGS THAT NEED TO BE DONE (EVENTS)

LOOP

We've explained how your program fits into Window's loop, so let's put that into the diagram:

DO  WINDOWS MAIN LOOP:

    LOOK FOR THINGS THAT NEED TO BE DONE (EVENTS)

    FUNCTION PBMAIN    HEY, LOOK - THERE'S A FUNCTION (PBMAIN) WAITING TO BE EXECUTED

    BEGIN THE EXECTION OF PBMAIN  (but don't stop - Windows has other things to do!)

LOOP

Perhaps the next time through the loop it looks like this:

DO  WINDOWS MAIN LOOP:

    LOOK FOR THINGS THAT NEED TO BE DONE (EVENTS)

    MSGBOX "Hello world!"    THAT PBMAIN FUNCTION NEEDS TO DISPLAY SOMETHING IN A MSGBOX

    SO GO AHEAD AND DO THAT  (but don't stop - Windows has other things to do!)

LOOP

Eventually the loop looks like this:

DO  WINDOWS MAIN LOOP:

    LOOK FOR THINGS THAT NEED TO BE DONE (EVENTS)

    END FUNCTION    THAT PBMAIN FUNCTION HAS REACHED ITS END - SO CLOSE IT OUT
                    (but don't stop - Windows has other things to do!)

LOOP

You needn't concern yourself with the when and how Windows goes about its tasks and picks up your program. You do need to understand that this is how Windows is working.

Summary: Windows is a multi-tasking system. It monitors and schedules all events. Programs you write need entry and exit points so that Windows can call them into its event loop in a way that allows your program to exist simultaneaously with other things Windows is doing.

PRINT vs. MSGBOX

We've seen how your Windows program is one of the "events" Windows examines and handles. Really, everything that happens under Windows is an event.

Our Windows Hello World example used a MSGBOX statement instead of a PRINT statement. Let's look at why. With a DOS system your program, being the only thing running, has control of the entire computer. This means you have control of the entire screen. A PRINT statement works because there is nothing else to get in its way.

This is never the case with Windows. You never have access to the screen. The Windows operating system controls the screen. Remember, your program is not the only thing that might want to display information on your monitor. Windows allows you to open a window on the screen for your display. That way it can manage multiple displays coming from multiple programs. Your program will control a window - or multiple windows, but never the screen itself.

Windows, the API and the PowerBASIC DDT

PowerBASIC provides built-in statements and functions that allow you to easily build dialogs, controls and complete Windows programs. These built-ins are called Dynamic Dialog Tools (DDT). This means you can build a complete Windows application using a minimum of code and without having to learn and use complicated Win API calls. Your completed Windows program may be built using only DDT, only Win API, or a combination of the two.