GFA BASIC 32‎ > ‎How To‎ > ‎

00 HELLO, WORLD!

posted Jun 28, 2015, 6:58 AM by Troy Cheek   [ updated Jun 29, 2015, 8:59 AM ]
In computer terms, a "Hello, World!" program is the equivalent of clocking in at work and turning the lights on.  All you've really proven is that you've shown up.  Whether you can do any actual work or not is still to be seen.  In computer land, this is an important first step.  It shows that both you and the computer are working properly.  If you can't get "Hello, World!" or some equivalent to show up on the screen of your computer (or some other display on some other device), then how can you do anything that's actually productive?  What are we paying you for, anyway?

I am not exaggerating in saying that a piece of hardware I once put together failed this test.  I forget the exact results, but it was something along the lines of "HELLA WARLD."  It turned out the keyboard was set up wrong.

In GFA BASIC 32, which is what this page is talking about, a "Hello, World" program is pretty darn simple.  I'm going to assume that you've tracked down and installed GFA BASIC 32 as explained on the main page.  Open it up (GfaWin32.exe) and type the following line:

print "Hello, World!"

That's all there is to it.  To test your program, click on the "Run" icon or hit F5.  GFA BASIC 32 should open up a window, display "Hello, World!" and return control to the editor.  You might also want to try to compile the program and try it outside of the editor.  Along the top line of the editor, pull down "Project" and select "Compile" or just hit CTRL-E.   You can then run the resulting EXE file by double clicking it.

Now, if you played with the window that opened up, you may have noticed something.  As soon as you minimized, maximized, or just resized the window, your beautiful "Hello, World!" disappeared.  If you tried running and compiling the program, you probably noticed that the window opened and closed so quickly that you couldn't tell if "Hello, World!" appeared or not.  What's the big deal?

Well, it turns out that while putting something on the screen is pretty easy, actually doing anything with it takes a little setup.  That's why my version of "Hello, World" for GFA BASIC 32 looks something like this:

Rem HELLO, WORLD!

Mode StrSpace 0 : Mode Date "/"
Auto

OpenW # 1
Win_1.AutoRedraw = True
Win_1.Caption = "GFA-BASIC 32 - HELLO, WORLD! - Troy H. Cheek"
Win_1.SetFont SYSTEM_FIXED_FONT
Win_1.PrintScroll = True
Win_1.Sizeable = False
Win_1.MaxButton = False
SizeW # 1, 1280, 720
SizeW # 1, 1280 + (1280 - _X), 720 + (720 - _Y)
Win_1.Center Screen.hWnd
ClearW # 1

Print "HELLO, WORLD!"

Do : Sleep : Until Win_1 Is Nothing
CloseW # 1

That's a lot of code just to say "hello."  That's because it's not "just" hello, but also makes sure the hello message sticks around.  I also use code like this as a basic starting point for any new project.  It's complicated, but don't worry.  I'll go through it with you line by line.

The REM at the top is a simple remark.  In BASIC, remarks are ignored.  I always start a program with a remark reminding whoever is looking at the code of what the program is called, what it does, who wrote it, etc.  Also the GFA BASIC 32 editor will show the first line of code in the status bar at the bottom, reminding you of what program you're working on.  By the way, I will sometimes write BASIC keywords in ALL CAPS, at least when I first use them.  That's a habit I got into a lot time ago working with a BASIC that only accepted ALL CAP keywords.

The MODE statements set some behaviors the way I want them.  By defaut, GFA BASIC 32 acts a bit like Visual Basic and certain C dialects in some respects.  This is for compatibility, so that code written for one language can be more easily converted to the other.  Which is fine and all, but some of the behaviors are contrary to what I expect after working with older versions of GFA BASIC and other languages.  STRSPACE sets the behavior when converting numbers into letters.  To a computer, the number 12345 is different than the text "12345" written on the screen.  The default is to pad the new text with spaces at the beginning and end, so it comes out something like "_12345_" where those underscores are actually blank space.  I don't like that, so I turn it off by setting this option to 0.  We don't do any numeric conversions in this program, but it turns up where you least expect it.  If we were printing a number to the screen instead of "Hello, World" we might have unexpected spaces.  DATE sets how dates are displayed.  As an American, I'm used to seeing dates in the form of MM/DD/YYYY.  In Germany, where GFA BASIC originates, they apparently like DD.MM.YYYY.  I don't, so I change it.

AUTO is a command that automatically declares variables for you.  I'm used to older BASICs where you didn't have to explicitly declare that variable A was an integer, variable B was a byte, variable C was a string, and so on.  I just have to remember to use the right type modifier for the variables, A% being an integer, B& being a byte, C$ being a string.  As long as I cast it right the first time I use it, GFA BASIC 32 will keep track of it for me and add it to the Auto line.  I like to check the Auto line after I add a new block of code.  If I suddenly see misspelling of a BASIC keyword among my list of variables, I can be pretty sure that I typed something wrong and that my program won't run.

OPENW, strangely enough, opens a window with the specified number.  I don't know if Windows (the operating system) can actually support this many windows (the thing on your screen), but GFA BASIC 32 lets you use numbers 0-511.  I'm tempted to write a program to try to open 512 windows just to see that happens.  (EDIT:  It bogs down your computer and it takes forever to close them all, but you can open at least 512 windows in Windows.)  This window is where all our text and graphic output will go unless we open another window and tell the program to output it there.

We set AUTOREDRAW for window 1 to true so that if we minimize or maximize or make other changes to the window, the program will know about it.  The default window behavior will take care of most of it, but sometimes the program will have to redraw the window.  That usually takes more work than I'm willing to do, so I take steps to avoid it.  More on that in a second.

CAPTION lets us define what will be displayed in the title bar at the top of the window we just opened.  We could also set that with TITLEW.  In fact, when it comes to windows and dialog boxes and forms, there are often multiple ways of doing things.  I like to set the caption to something descriptive in case I have multiple GFA BASIC 32 windows open and don't want to have to flip through them to find what I'm looking for.

https://sites.google.com/site/stessential/development/gfa-basic
I like to SETFONT to a fixed width because it reminds me of my early programming days.  For some reason, proportional fonts just don't look like "code" to me.

PRINTSCROLL sets the behavior when you print something at the bottom of the window.  Does it print at the bottom and make the rest of the test scroll up, or does it get printed somewhere below the bottom of the window and disappear forever?

SIZEABLE controls if you can grab an edge or corner of the window and use that handhold to change the size or shape of the window.  This is one of the cases where autoredraw can't help us, so I like to disable it so the program doesn't have to manually redraw the screen.

MAXBUTTON controls if the maximize button is active.  This counts as a change in the size and shape of the window, so I disable it.

SIZEW changes the size of the window, and I often like a size of 1280x720.  It's still HD (suck it, haters!) but is small enough on my 1920x1080 screen that I can see around it or move it aside if I need to see something else.  My video camera works best at 720p and I do all my video editing at that resolution, so it makes sense to use that for projects that I might be taking screenshots or video of.

Notice that we have two SIZEW commands.  The first attempts to set the window size to 1280x720.  This succeeds, but it turns out that those dimensions mean the window as a whole including the title bar at the top and borders all around.  That makes the area useable for text and graphics slightly smaller.  Exactly how much smaller depends on what gadgets and doo dads your particular version of Windows and your individual settings put there.  GFA BASIC 32 does have a way to determine how much space those gadgets and doo dads will take up on a window, but I always have to look it up.  It's actually easier for me to attempt to size the window, see how close I get, and do a little math to fix things.  _X and _Y are shut cuts that tell you how many pixels wide and high your usable window space is.  So, if we try to open a window 720 pixels tall but actually get one only 700 pixels tall, we know that on our next attempt we can open one 740 pixels tall to get the desired results.

CENTERW centers the window within the specified object.  In this case, we call the handler (h) for Windows itself (Wnd), so we basically tell it to center the window on the Windows screen.  We can still move it around if we want to or minimize it if it's in the way; we just can't resize or reshape it because we'd have to manually redraw the screen and we haven't covered that yet.

CLEARW clears the window.  This probably isn't necessary because we haven't put anything in the window yet, but with all the resizing and moving and option setting, it's possible some garbage got in there, so it's best to clean it before we use it.

PRINT.  We used it.  Finally.  "Hello, World!"

The DO LOOP UNTIL is there so that the window hangs around long enough for us to check it out.  Without it, the program would just end.  In this case, the program will SLEEP until the window becomes "nothing" or goes away, probably because the user clicked on that little red X in the upper right corner.

The program ends with CLOSEW.  This probably isn't strictly necessary because we just waited around until the only window we opened was closed by the use.  However, having this here reminds me that I need to clean up before exiting the program.  The days when you could just end a program with the END statement are over.  The programmer has to remember to close open windows, flush and close open files, release memory blocks and other resources that have been reserved, cancel sounds that are playing, reset custom color palettes, and generally behave like a well-meaning guest and put the house back the way he found it.

And that concludes discussion of the "Hello, World!" program.  That was a lot of lines of code for something so simple, and we didn't even use most of it, but it will act as a starting point for future projects.  I hope you enjoyed this article.  Please tune in next week for more about GFA BASIC 32.
ċ
HelloWorld.G32
(1k)
Troy Cheek,
Jun 29, 2015, 6:44 AM
Comments