John's Visual Basic Fun
I did not have a proper home PC until I bought a Packard Bell for Lesley so she could use it for school tasks.
Since I had the computer around, I decided to learn to program it using the "Qbasic" interpreter that comes with Dos/Windows.
I bought a "Qbasic for Dummies" book to get me started. My first (and only) Qbasic project was "Net Worth History" described below, and this made me hungry for having more fun with PC programming.
About the time that I was ready to do more, Windows 95 was released and on its heals was Visual Basic 4.0.
I had read about Visual Basic for a long time, but now it seemed like it was really becoming popular as a powerful PC program development tool.
I bought the beginners version of Visual Basic 4.0 and started having fun.
Notes
Visual basic is like an programmer's erector set. The are lots of pieces that are put together to form the final product. The individual pieces are called "controls", named so because the program "controls" their behavior. For example, one piece or "control" is a "directory list box" which displays directory names with the little folder icon next to them. A program "controls" the "control" by telling it which parent directory to display. The control does the rest. If the user clicks on one of the directory names, the "control" tells the program that the user did so and the program can react by changing directories.
There are thousands of controls, produced by hundreds of companies that can be added to the programming environment to do a wild variety of things.
I developed particular interest in a set of controls that gives me access to the Internet from within my programs.
Another fascinating control allowed me to write a demo program that would answer phone calls and give out lab test results over the phone.
Since I maintain SEP/IRA accounts, I thought it would be fun to have a program that would graphically display the progress that I was making in accumulating net worth.
Each month when I review my statements, I make a single line entry into a file using "NotePad". The entry includes the year, month, net worth, and my goal for that month.
The Net Worth History program reads the NotePad file and draws a graph of my progress over time.
The fun that I had with this project starts with the fact that I made the program draw all of the chart features "by hand". The program draws all of the elements that you see on a graph; the chart borders, hash marks and lines, hash values, progress lines and values. The fun continued with making the program draw the progress lines slow enough so that I can see the chart progressing. Also, since I have a lot of data points, the program pauses when it fills the screen, then starts over, moving ahead a year. It continues starting over until it displays all data points. It also adjusts the scale of the chart from year to year so that in early years, the progress lines aren't squished down at the bottom of the chart.
In my job as a COBOL programmer, I constantly need to inspect my programs to find references to specific data elements. (In the past few years, those specific data elements were dates that needed to be enlarged for the year 2000!)
I have programs and tools that can do this on the mini-computer which houses the COBOL programs, but they are slow and not easily customizable.
The Code Browser can inspect all of my COBOL code in a fraction of the time that it takes on the mini-computer, and I have complete control over how the Code Browser does its job.
I start by copying all of my COBOL programs to my PC over the network. Using a "file list box" the Code Browser obtains a list of the files I want to inspect. The program has two "search for" fields with an "and/or" option. It also has an "exception list" text box so I can specify certain things that I don't want to see (like programmer comments).
A "search" button causes the program to read each file in turn looking for the text that I specified. As it finds code of interest, it inserts the code (and an optional number of lines surrounding the line of interest) into a print "list box" which the program will print if you hit the "print" button.
Although this program was fun to write, I made it fun to use by making the search process very "visual". As each file is examined, the file list box is adjusted so that the file being examined is highlighted. This makes the file list box automatically scroll as the files are processed.
Because I experiment with lots of different programs from a variety of sources, my home computer gets crowded with lots of junk. I wanted a program to display in a concise way where the junk was.
I wanted to be able to see how much space was being consumed directory by directory, no matter what level I was looking at. I could then zero in on really large directories and then drill down through them to find out what was taking up the space.
When this program starts up, it reads the entire disk using a "drive list box" with which the user specifies a drive , an invisible "directory list box" that the program uses to determine which directories to examine, and an invisible "file list box" which the program uses to enumerate the files in each directory.
The program then creates a "tree" which contains the level by level directory names and their aggregate size. If you want to "explore" a directory, you can right-click on it and cause the Windows Explorer to start in the specified directory.
The challenges in writing this program were learning to use the "tree control" and adding the file size to each directory in the tree back to the drive level; the fun was operating the tree control.
At work, we have several tape backup programs that run at a scheduled time each night. When they are done, they create log files that specify how long the backup took and how many files were backed up.
The problem is that they do not print the log file.
The Server Backup Log Checker programs use a "file list box" to enumerate the log files, read each log file to determine which ones should be printed, and then screen out unwanted lines in the log files as they are printed.
This makes the network administrator's job easier since the appropriate log file is printed automatically as a confirmation that the overnight backups were done correctly.
It is fun to do something that makes the job easier.
We are all seeing more and more computer applications that capture our signatures into a computer. I wondered how a Visual Basic program might do this.
After seeing the new hand held computers that have "touch screens" instead of mice, it occurred to me that since Visual Basic has direct access to information about mouse actions (button pushing and movement), a VB program might be able to record a signature based upon mouse movements. Translating this into the context of a hand held computer, the program could detect the actions of the "stylus" which is sometimes used as a pointing device to capture signatures.
This program has a "picture box" into which the signature is drawn by the program based upon the pointing device (mouse) movements. When the left mouse button goes down, the program goes into "draw" mode to record the signature. As the mouse is moved, the program draws lines from one mouse movement point to another. When the left button is released, the program exits the draw mode. The program also records the signature into a ".bmp" file for later reference.
The program is incredibly simple because VB has all of the capabilities to do this built right in.
I had fun trying to draw my signature with a mouse.
At work, I use a white paper pad to jot notes on. I wind up with notes all over my desk either laid out so I can see them or stacked up to get them out of the way.
I wondered if I could write a program that would emulate how I use the white pad.
I wanted to be able to create notes at will, arrange them various ways, make some invisible, make them all invisible or visible, and delete old ones.
I wanted each note to be an independent entity on the computer desktop and to be able to have as many notes as necessary.
To do this, I had to learn about creating "control arrays" and even more about "form" creation and destruction. A "form" is the container for the visual elements of a program. A "form" is itself a "control", and a program can create more "forms" on the fly. An "array" of "forms" is just a lot of "forms" that the program has created and has to keep track of.
For a devoted white pad person, this was fun to do. I can arrange the notes from top to bottom of the screen or diagonally down the screen. I can make all of the notes appear or disappear using an icon that the program places in the tray portion of the taskbar.
Nevertheless, I still use the paper white pad! That's no fun.
I would not normally consider database programming fun, but I did some things to make this project fun.
Because of some other projects I wanted to do, I needed to create a database in the PC environment which contained laboratory test results normally maintained on the mini-computer at work.
I wrote a program to extract the needed data from the files on the mini-computer and then transferred the export file to a PC.
This program creates the PC database (a Jet/Access one) and then loads the PC database with information read in from the mini-computer export file.
The fun thing that I did was add the multimedia "control" that comes with Visual Basic so that I could play a sound file while the program was loading the 100,000 records into the database.
When the music stops, the job is done.
I also experimented with three different methods of creating a form for updating and examining records in the database. One method used the form created by Visual Basic's form designer. Another involved a "generic" form that transforms itself based upon a specified file/table definition. The last method was a roll-your-own form which I created from scratch.
More fun comes later when I use this database in other projects.
After I purchased the Visual Basic for Beginners, I started receiving catalogs which offered all of the various "controls" for sale. One set of controls that was of particular interest to me was the "IpWorks" TCP/IP controls from "devSoft Inc.". I was interested in them because TCP/IP (Transmission Control Protocol/Internet Protocol) is the language of the Internet and we were using TCP/IP in our internal network at work.
I wanted to learn how the Internet worked, and having access to it in a programmable environment seemed like a powerful capability that might be useful.
I also wanted to have fun doing it.
Back to Internet Project index
TCP describes how data is transferred across a network. Programs have to pick up the data after it is transferred and do something with it (like display it on your screen as a web page).
In order to learn how to use the TCP/IP controls, I started with a pair of programs (one of each of two computers) that did nothing but send data back and forth. One program is the "server" that listens for an incoming connection requested by the other "client" computer. When connection is established, the client program sends some data to the server computer which "echoes" the data back to the client.
The client program computes the throughput rate and displays it on screen so you can see how fast data is being transferred back and forth. How fun!
This is done using "raw" TCP connections. The programs could define a content and a conversation protocol and then communicate meaningfully across the network.
Back to Internet Project index
One of the trivial things that is done on TCP networks is the serving up of the correct time. Computers can be set up to respond to a request for the correct time. Since a lot of different things can be going on within a TCP network, the computers have to keep track of the sender and recipient of each transmission. At the heart of this tracking is the TCP port number which defines more or less which program will be interested in the data coming in from network. Web traffic (HTTP) uses port 80, FTP uses port 21, TELNET is 23, and the time server uses port 7.
So the Time Server Client requests a connection to port 7, waits for the reply, and then displays it on the screen.
I told you it was trivial, but it was fun.
Back to Internet Project index
Now that I had a PC program that could converse crudely across the network, I wondered if I could strike up a conversation with the mini-computer we use at work. If I could do this, it meant that the mini-computer data was interactively accessible to a PC program; a powerful capability.
The mini-computer contains a "terminal server" network board that allows terminals to connect to it across a network. The termserver board has its own network address and makes raw TCP connections on ports in the 64xx range.
I wrote a time server program to run on the mini-computer which listens on one of the termserver ports. On the PC side, I modified the Time Server Client program to request connection to the port in the 64xx range.
I had established raw TCP connection to the mini-computer and I was still having fun.
Back to Internet Project index
The mini-computer at work has a usable FTP (File Transfer Protocol) server that lets a client program transfer files to or from the mini-computer, but commercially available FTP client programs were cumbersome to use because they do not recognize the format of the mini-computer's directory lists.
Since I had the FTP client "control" in my erector set, I wondered if could I write a better FTP client.
I was able to create a customized FTP client program that minimizes the usually bewildering array of options and parameters so that the user need only specify the host, user name and password to get connected. The type of host connected to is automatically determined by the program when it examines the format and content of the logon message.
The program has local and remote file list boxes so that the user can point to and click the files to be transferred.
It was fun writing a program that was more user-friendly that a commercial one.
Back to Internet Project index
Terminal Server ARP Cache Clearer
Part of the mini-computer system at work includes a terminal controller and several remote terminal servers that are separated over a wide geographic area and are connected by private, leased lines supplied by the phone company.
Occasionally the terminal controller gets confused and forgets how to communicate with the remote terminal servers. Even though this is obviously a program bug in the terminal controller, the mini-computer vendor suggested that a workaround fix is to issue the ZEROARP command to the terminal server from one of the termservers. Because all of the termservers were remote, this presented a challenge.
Luckily, the termservers would accept a remote-control Telnet session that would allow us to issue the needed commands to clear up the problem.
The problem then was that we never knew when we would have to issue the needed commands.
The remote users who may work around the clock might call at any hour to tell us that the communications were dead.
It then occurred to me that I may be able to write a program that would automatically and periodically start a Telnet session with a remote termserver and issue the needed commands.
Using the IpWorks Telnet "control", and after learning a bit about the Telnet protocol, I cobbled together a program that did the trick.
As it turns out, it is harmless to issue the needed commands in anticipation of a problem. If there is a problem, it is fixed. No problem? No problem.
So now the program sleeps for 5 minutes, then wakes up and issues the ZEROARP command to the termcontroller. The termcontroller then re-learns (correctly) how to communicate across the wide-area network.
Although this program was created out of necessity, rather than just for fun, I can now have more uninterrupted fun since I now hardly ever get a trouble call related to this problem.
Back to Internet Project index
One of the "controls" in the "IpWorks" package is the HTTP (HyperText Transport Protocol) control which is used to retrieve web pages from web servers.
I knew what it could do, but I did not have an application for it until we started having trouble with our Internet connection to our ISP (Internet Service Provider) at work. We have an ISDN phone line that is always connected to the ISP so that our access to the Internet is immediate and fairly fast.
Occasionally, the throughput would get slow or non-existent, so I wanted a way to monitor it automatically.
I designed a program that would automatically and periodically download several web pages and determine the throughput rate. If the throughput rate falls below a certain rate, the program sends an E-mail message to the network administrator as an alert message.
The program was constructed using the HTTP and the SMTP (Simple Mail Transport Protocol) controls. The SMTP control handles the sending of the E-mail message.
Since this was my first program using the HTTP and the SMTP controls, it was fun to do, but it was not fun to use initially because it was always sending us E-mail due to the line outages.
We finally found out that our phone line was shorting out. The phone company fixed it and now our Internet connection is fine.
Back to Internet Project index
At work, we operate our own E-mail server that is connected to the Internet, so we want to know that it is up and running.
The only way I know of to tell if an E-mail server is working is to see if it will send and receive mail. Duh.
I designed a program that would automatically and periodically send a message through our E-mail server to another E-mail server that would automatically return our message so that it would be received by the network administrator. The vendor of our E-mail server software operates an E-mail server with an "auto-responder" which automatically answers mail addressed to certain mailboxes. They do this so that their customers can test their E-mail servers after installation.
I asked them if I could use the auto-responder on a daily basis as a means to make sure that our E-mail server was working. They said OK.
The E-mail Server Checker program sleeps until 6:00 am when it wakes up to send a message using the SMTP control through our E-mail server to the auto-responder of the vendor. The return address is the E-mail address of the network administrator. When he arrives at work in the morning, he expects to see an E-mail message from the auto-responder that the vendor operates. If he sees the message, he knows our E-mail server is working correctly. If he does not see, the message, he punches in and goes to work.
This program was fun because it was the first program that I wrote that used the SMTP control.
Back to Internet Project index
Now this program was really fun!
I was inspired by a coworker who was interested in a particular stock and periodically looked up the stock price on the Internet during the day.
I designed a program that would periodically and automatically look up a number of stock prices and display them on the screen along with the graphic of the DJIA chart for the day.
Many different search sites offer free stock quotes and most of these sites have a variety of graphics that display the current market conditions.
Using the HTTP control, this program issues the requests to the servers that have this information, receives the reply and then strips out the useful information from the reply.
The list of stock symbols that the program looks up is maintained in a simple (.txt) file using NotePad.
The goal of this program was to display a minimum amount of information so that the desktop remains uncluttered.
The little graphic pulled off the web shows a chart of the DJIA through the day.
With this program running on the desktop, it is fun to watch the stock market go by.
Back to Internet Project index
This program was constructed one Sunday when I was at work baby sitting a file conversion program during bad weather.
There are lots of graphics on the web which display the current weather conditions using information gathered from a variety of sources like RADAR, satellite, and Doppler.
I found one image that I liked and wished I could just put it on my screen and have it update every few minutes.
The new browsers are capable of doing this type of thing, but that is not fun, so I wrote this program which does the trick.
Using the HTTP control, the program pulls my favorite weather graphic off of the web and displays it on the screen. It reloads the image every 5 minutes.
So, as the day wears on, I can watch the weather come and go.
That's fun too, isn't it?
Back to Internet Project index
If you are still with me, we are about to shift gears.
Automation, remote automation, COM (Component Object Model), DCOM (Distributed COM) and OLE (Object Linking and Embedding) are all terms used to define or describe the world of "objects". There are even more terms (like ActiveX) that Microsoft now uses to confuse us.
The "controls" I have talked about are also referred to "objects", and with Visual Basic it is possible to create "controls" or "objects".
Why would you want to create an "object"? Well, because Bill Gates said so.
Software is put together by plugging individual "components" or "objects" into each other. If a piece of software is not an object, it cannot be re-used or plugged-in to by other programs in the proper Bill Gates way.
Objects typically do one or a few things well and make it efficient for other programs to take advantage of it.
An example might be an object that authorizes a credit card purchase using a dial-up connection to the card issuer. Programs that accept a credit card number and need to authorize the purchase, plug-in an object and have the job done with only a handful of lines of code. The object may have hundreds of lines of code.
The following projects are experiments with objects, also called OLE servers.
Test Results Web Server Object
With the Internet becoming so popular and useful, I wondered how hard it would be to make laboratory test results available on the WWW (World Wide Web).
I needed a web server, a way to program the web server, and a way to retrieve the lab results into the web server program.
Microsoft gives away its Personal Web Server which runs on a Windows 95 computer, so this part was easy.
The first and one of the most basic ways to program a web server uses a technique called CGI (Common Gateway Interface). A web page references a CGI program instead of a static web page. When the user clicks on the reference, the client (browser) requests that the program be run, and the web server runs the program expecting to get back a customized web page from the program which it returns to the browser/client. Simple.
But what the heck is CGI? It just defines the format that the web server and CGI program use to exchange data.
But how do you write a CGI program. You need a programming language that knows about CGI. Enter "Perl".
Perl (Practical Extraction and Reporting Tool) originated in the UNIX world and is now available for Windows environments, so I bought a "Perl for People Without a Life" book and went to work.
With Perl and CGI, you construct a web page on the fly by "printing" the code needed to make the web page. When a Perl program is invoked by a web server, the "printed" web page is captured by the web server when Perl program ends.
To get information into the Perl program, the web page that references the Perl program accepts information (e.g. an ID number) from the user, and this information is passed to the web server which in turn passes it, using the CGI format, to the Perl program.
The Perl program now has an ID number, but no test results. Since Perl can use "objects" we need an object which will return the lab test results of a specified ID.
With Visual Basic, I created a program and specified that it was going to be an OLE server (object) which would accept an ID number and return the lab test results. The program accesses the Jet database to get the results.
The Perl program can now create or "instance" the object , plug in the ID number and obtain the test results.
Amazingly, it all actually works.
Test Results Remote Automation
I had an object that would return the lab test results, but it resided on the web server PC. What if another program on a computer somewhere else on the network wanted to use that object? Say hello to "remote" automation or DCOM.
It is possible to tell the web server PC that remote users are going to use the test results object, then tell a remote client's PC that the test results object is on the other computer, so that when a program on the remote client's PC needs a test result, it creates the object instance and retrieves the test result just as if the test result object were local. The Windows operating system handles all of the network communications between computers to make this work.
I wrote a client program that simply accepted an ID number and looked up the test results using the remote test results object.
It was fun to discover how all of this fits together.
We all know that computers can talk, but how do you program them to do useful talking?
I wanted to see if I could make a PC give out laboratory test results over the phone.
I found out that there are commercially available "controls" that make this easy.
Back to Telephony Project index
Test Results Telephone Responder
At lease one of the vendors that sells Telephony/Voice controls, allows developers to download a trial version so that they can see how easy they are to use.
I did this.
Using a design tool that places process steps on a Visual Basic form, I constructed a program which answers the phone, plays a recorded message that instructs the caller to enter a lab ID number, retrieves a lab test result from the Jet database, then speaks the result.
I did this one Saturday afternoon when I was having fun.
The "demo" controls that I downloaded did not actually answer the phone, but rather simulated it and showed the action on screen. The voice responses were played through the PC sound system and the entry of the lab ID number was done on a special simulated phone.
The "live" controls require that the PC have a special card in them that handles one or more phone lines and does the voice processing.
Back to Telephony Project index