"Roll Your Own GFA BASIC Program 1" by Troy H. Cheek on Apr 13, 2009
If you want a VB/QB compatible BASIC IDE and compiler for Windows 95/98/Me/ NT/2000/XP/Vista, check out GFA-BASIC 32 for Windows. I've talked (well, typed) about this before. GFA BASIC is (or at least should be) a dead language, but Sjouke Hamstra keeps dissassembling, coding, researching, etc. All of this is good for me and other old fossils, because we'd rather have a dead language that still works than learn a new one. We're funny that way.
While there are websites just chock full of VB, QB, and even GFA programming goodness, most of them seem to assume a level of knowledge that your average enthusiast (or even an above average one such as myself) just doesn't have yet. It's all well and good to fill a GFA-BASIC 32 Stuff blog full of articles about "ANSI API functions and RichEdit" and "GetFirstVisible method not implemented", but I'll be the first to admit that I'm not sure what any of that stuff means. Heck, much of "Pointer and Gfa_Var object" was over my head.
I guess what I'm asking is this: Where are the websites for down and dirty little GFA BASIC programs? You know, the type that the average man on the street (well, geek in the lab) is actually going to write?
Well, here's one.
I had a particular need. I had a whole bunch of recorded TV shows on a couple of harddrives that needed some video processing. Some were just too big and needed to be compressed, converted from MPEG-2 to something more modern like h.264 or xvid. Some were letterboxed with annoying black bars on the top and bottom so they'd correctly display on plain old 4:3 standard televisions and monitors, meaning that my widescreen 16:9 television and 16:10 monitor were showing more framing that picture. Furthermore, I was recording more all the time.
There are a lot of great encoding tools out there (ffmpeg, mencoder, handbrake, etc.) but none of them are really focused on the specific needs of this particular user. There exists a thing called Utility: MediaShrink - An HTPC focused encoder which is a CLI front end that automatically mixes and matches the best encoding tools to use depending on the type of content you're trying to encode. I gave this program a try and found that while it was great at what it did, what it did wasn't quite what I needed.
But it did give me an idea. I realized that MediaShrink didn't do a whole lot in and of itself. It basically ran a few other utilities to figure out the format of the video file and what needed to be done to it, then ran a few other utilities to actually do that stuff. The internal guts of the program, at least based on how that particular black box looked from the outside, didn't seem so complicated. It almost seemed like something I could do myself. I fired up the GFA BASIC 32 editor and started typing...
Rem Automatic Media Recoder/Shrinker/Thinger v0.1 03/30/09 by Troy H. Cheek
Every GFA BASIC program needs to be littered with remarks. One of my first programming instructors used to tell me that if your source listing didn't have more remarks than actual code, you couldn't really call the code maintainable. I never go quite that far. In fact, about the only thing I do remember to document is an opening remark to remind me exactly which program this is and when I started working on it. Yes, this is necessary. A few years down the line, you will completely forget you ever wrote a particular program, and that cute and obvious filename you gave it at the time will tell you nothing about it at all.
Auto a$, a%, Acf%, AcfFilename$, buf$, c$, Dom$, dur%
Auto EZMFilename$, Finis%, GLog$, Interlaced%, LogFilename$
Auto MaxX%, MaxY%, MinX%, MinY%, NewFilename$
Auto OriginalFilename$, TmpFilename$, TmpPath$, Xres%
Auto Yres%
The Auto statement is almost like cheating. You see, since GFA BASIC is pretending to be a halfway structured language, it wants you to declare your variables and their types before you first use them. Auto scans your program, makes guesses as to the variable types, and declares them for you. The above mess started out as a single Auto statement with no parameters. As I wrote the program, it added the variable names for me.
It got the variable types mostly right because I use a coding style left over from a previous version of GFA BASIC where variable type was determined by suffix. a% means that a is an 32-bit(?) integer numeric variable. a$ means that a is a string variable. There are several more variable types, but I find that often all I need is are integers and strings. Note that I can use the same variable name for unrelated variables as long as I declare the types. This is probably a bad programming practice in this or any other programming language. I also tend to pick a few generic global variables and use them over and over. This is another bad programming practice.
Ideally, after I've created the bulk of the program, I should change the Auto to Dim and manually add any new variables. At that point, I'd be more likely to misspell an existing variable name than to try to create a new one.
We'll discuss what these variables are actually for at a later date.
OpenW # 1, , , 640, 480
Win_1.AutoRedraw = 1
Win_1.Sizeable = 0
Win_1.MaxButton = False
Win_1.Caption = "EZMedia Recoder"
Win_1.PrintScroll = 1
SetFont SYSTEM_FIXED_FONT
Cls
This is my generic window setup for just about any GFA program I write. You see, I don't create fancy graphical user interfaces with buttons and sliders and whatnot. Usually, I just want a plain window to show a little output while my program does the important stuff. A polished user interface comes later, if at all.
OpenW opens up a window and calls it object Win_1. GFA BASIC will open a window all by itself the first time your program tries to output something to the screen, but the default is something like 75% of the screen. I prefer a smaller size. I also like to know what my window's object handle is. This command has about a zillion options, but I prefer a plain old window.
AutoRedraw tells GFA to tell Windows to redraw the window if parts of it get obscured somehow. This option took me a while to find. I couldn't figure out why my content disappeared every time I opened another window on top of mine or minimized the window.
Sizeable sets whether the window can be dragged to a new size. It doesn't prevent resizing altogether, but it helps. I figure if I've just went out of my way to set the window at a certain size and have spent most of my time tailoring my output to that size, I want it to stay that way. I should probably be using some kind of form or dialog box, but I haven't figured those out just yet.
MaxButton enables or disables the full size widget on the window's title bar. Again, this is to make it more difficult to change the window size.
Caption sets the actual title in the window title bar. It's good practice to set one, and I'm told that programs which don't have a title set can cause Windows problems. Besides, if you have multiple GFA BASIC programs running at once, you'll need to keep them straight.
PrintScroll describes what happens when you print enough to fill up all the lines in the window you just opened. This default is that the next thing you print just disappears, printed down below the bottom edge of the window. Setting this option to TRUE means that all the existing lines will scroll up and your new output will appear at the bottom.
I use 1, 0, TRUE, and FALSE pretty interchangeably, which again is bad programming practice. In GFA BASIC, for the most part 0 is interpreted as false and any non-zero number is interpreted as true. I believe the GFA constant FALSE is defined as 0 and TRUE is defined as -1.
Notice that I'm using the windows handle (Win_1) combined with various options (AutoRedraw) to set options for that window. This is about the only part of object oriented programming that I understand. I'm told that GFA can handle lots of OOP, but I don't know anything about it.
SetFont sets the font. For some reason, I started using this system's fixed font for output and never went back. Everything else just looks wrong for a GFA BASIC program now.
Cls clears the screen and sets the cursor to the upper left corner. I don't think this is actually necessary, but I got into the habit a long time ago and never got out of it.
So far, we've set some variables and opened a window. Next time, we'll actually start doing something with them. See ya!
