Thursday, October 09, 2008
This article was originally on devblog.coobird.net.
I started out programming back in elementary school on a fairly well-known language called QBasic. It was a programming language and development environment developed by Microsoft which came bundled with MS-DOS. Back then, when I first started writing programs, making the computer print things on the screen and accepting user input was so exciting, that I would come home from school and be coding for hours on end. (Albeit, programs were a mess of GOTOs; a wonderful example of spaghetti code.)
As I went on to middle school, I continued to write programs in BASIC, including Visual Basic 3.0 which could produce programs for Windows 3.1, and QuickBASIC 4.5 which could compile executable programs for DOS. Back then, the school I went to had IBM PCs with 386s. Yes, it was the mid 90s, and systems with Pentium processors were out, but back then, most computers weren’t exactly cheap, as most systems started around $2,000. How times have changed.
Getting back on track, one of the types of programs that I always enjoyed making were menu programs. In fact, I had so much fun making menu programs, that the version number of the last menu program I wrote was the version 8. The program was appropriately called Menu 8.
Menu 8 may have been one of the rare programs which I actually wrote to the point that it was usable and (relatively) stable. Oh, and I got permission to install it as the dedicated DOS menu program on the one standalone “multimedia” computer (i.e. not connected to the network) at the computer lab. That was exciting indeed.
Fast forward 10 years. After going in and out of programming several times, I’ve dabbled in multiple programming languages. Having spent the past few years programming in C-style languages such as Java and C, I thought it might be fun to go back to QuickBASIC to write a perennial favorite: a menu program.
Since Menu 8, I have attempted to make another menu program, but I never got around to it. Most of them turned into demonstration programs for moving windows around or tinkering with graphics. This week, I decided to take another shot at building a menu program. This time, it will be called Menu 10.
The decision was made to design a menu program that would be done in text mode and navigated only by the keyboard. After all, I figured I’ll try to differentiate myself from others by limiting myself to a certain subset of functionality that are available. (For those who are curious, performing a Google search for QBASIC and GUI results in many graphical user interfaces, many of which have support for mouse input and output graphics in SVGA.)
My goal for the windowing interface was to build a generalized system.
I don’t intend to use the windowing interface for anything other than Menu 10, but keeping it generalized will be a departure from the times when I was programming in QuickBASIC; back then, I would have interfaces which were tied specifically to the menu and nothing else.
Also another common staple was the copious use of
The generalized windowing interface was designed with the following goals: allow on-the-fly addition and removal of the windows, and also allow the user to resize, reposition and switch between windows. Within a couple of hours, I was able to write a simple version of the windowing system.
Displaying windows on the screen is nice and all, but it isn’t very interesting nor useful without the windowing being able to display information for the user. This was achieved by providing hooks within the window drawing routines so external code could be called to display the contents of the windows.
As the over-arching theme to this menu program is to develop a generalized windowing system that doesn’t couple too much menu-specific code into the windowing system, a window content display mechanism called a display handler was implemented. A display handlers is a piece of code which is activated on drawing of the window onto the screen. The appropriate handler for an window is decided by the ID number of window.
After implementing several window handlers, the menu program began to look more and more like a usable menu.
It took about three days to get to this point. The next few days involved tweaking the windowing, reassigning keyboard shortcuts to activate the events, and refactoring the code to separate the windowing system from the handlers.
By day six, the menu system became more usable with the addition of a menu component which allows the display of menu items which could be selected and executed by the user. At this point, the menu only allows invoking specific window system tasks such as saving and loading the states of windows on the screen and exiting the menu program.
Perhaps what this revisiting of QuickBASIC showed was that there were many features of the language that I wasn’t taking full advantage of.
For example, I didn’t know the exact difference between a
FUNCTION until recently.
I had always assumed that a SUB was simply a void function, but it turns out that a
SUB allows the “returning of multiple variables” and can’t be used in expressions where a FUNCTION returns a single value which can be used in expressions.
Arguments passed to
FUNCTION in QuickBASIC are pass-by-reference, therefore, the value in the arguments can be directly altered within subroutines and functions.
Also to note is that QuickBASIC allows separating code into multiple source files called modules.
This is not a feature that is supported in QBASIC (if I recall correctly), but is a feature in QuickBASIC which allows for more heavy-duty development over its brother which came bundled with MS-DOS.
Using modules came handy when using a module like a header file to include definitions for user-defined types in multiple source files.
Overall, it was a good exercise in learning a language that I haven’t used heavily in years, and it was fun to revisit an environment that I first started programming with.