General Discussion
In reply to the discussion: This message was self-deleted by its author [View all]MineralMan
(150,451 posts)Also for PC World, for many years, as a contributing editor.
I used Visual Basic for all of my Windows apps. Prior to Windows, I programmed in QuickBasic, a compiled Basic program.
I loved Basic. It was a language that I understood as well as English, really. Visual Basic made it easy to design user interfaces, and Windows was based on an interface user action concept. So, you could draw up an interface and then use Basic to program what the application should do when the user did something on the interface. It was an easy system to understand and Basic is easy to code in, or was for me.
It was like the interface was a big program loop, just waiting for the user to do something. Click here and a coded routine would do something connected with that interface object.
There were lots of tricky ways you could leverage those interface objects. For example, you could sort a list in a VB List box instantly and invisibly. You'd just make the List box invisible, do the sort, which was just a flag on the List box, and magically make it visible again, all sorted. In fact, you could duplicate the list box virtually, do the sort and then switch visible and invisible boxes without the user even being aware. There was no need do code a sorting routine.
Another cool thing you could do was create matrix string variables linked to those list boxes. One of my applications had a simple database in it. All fields in the database were stored in memory as matrix variables, so operations on the database were all done in invisible text boxes, out of sight and with minimal coding requirements. So, sorting the entire database could be coded by sorting the matrices for the list boxes and then making them visible after the sort, rather than dealing with a lot of code.
Unorthodox, but highly functional and fast.
I used short-cut trickery to do a lot of things in my applications, including graphical animations and positioning and printing graphics, which had no actual method to do that internal to the Visual Basic program. As I figured those tricks out, I used to share source code on Visual Basic forums to show others how to do things you weren't supposed to be able to do in Visual Basic.
The graphics animation subroutine, for example, required code that ran during initial program loading that measured the speed of the processor, since the Visual Basic timing tools weren't finely-grained enough. The speed routine provided a number matched to .01 seconds of the processor timing that could be used in an empty loop to provide a precise delay. Then, all you had to do was to load all of the animation images into a stack of invisible graphics boxes, and then cycle through the animation by making the appropriate image box visible in sequence, using an empty loop based on a multiple of that timing number to delay the animation loop process. A kludge? Absolutely, but it worked perfectly, and only required a few lines of code. Why did I do that? Because the opening splash screen in all of my apps had a winking teddy bear image that was the OsoSoft company logo. "Oso" is Spanish for "bear." Hilarious stuff.