For the seasoned Computer user, the keyboard is, IMO, far more powerful then the keyboard as far as strength of association and muscle memory is concerned. buying a new mouse that has a different shape can feel “Strange” for a while, but for me it takes maybe a few days, or a week. Buying a new keyboard with a different layout for the various “periphery” keys can take me upwards of a month.

As a user learned about the computer, eventually so too does their understanding of how various commands are done with the keyboard. When a person first learns to use a word processor, for example, they may use the Copy and Paste options on the menu, or in the toolbar. However, as they use these features more and more, they eventually discover, are told, or otherwise learn about the keyboard shortcuts for performing these tasks. In the same fashion, they will start out by selecting text, moving throughout their document, and so forth solely with the mouse. Eventually, they discover arrow keys, and later, the control block keys.

Arrow keys

The arrow keys were originally only present in the number pad area of the original IBM PC and XT keyboards. With the AT keyboard, the arrow keys were introduced and have traditionally been present beneath the control block keys, to the right of the main alphabetic keyboard block.

Today, the Arrow keys serve a myriad of functions. within any Windows edit box when it has the focus, the arrow keys can be used to move about a document. in combination with the Shift key, such movement is accompanied by the selection of the text. combined with the Control key, the selection moves a word at a time. A seasoned keyboarder will always beat out a mouser at the same text operation. The reason is mostly because, for typing, ones hands are both busy, well, typing. in order to click a button, toolbar, or menu, one needs to move their main hand (depending on their left or right handed ness) and move the mouse, and click it’s button. in contrast, one can perform the same task of most toolbar buttons using a number of keyboard shortcuts.

Control Block keys

For what I do with my computer, which involves a lot of editing of programming code, blog entries, web page files, and forum posts, the control block keys have become invaluable. The control block keys are the often ignored block of keys consisting of the Insert, Home, Page Up, Page Down, End, and Delete keys. When used properly, and in conjunction with modifier keys such as Control and Shift, one can perform a myriad of functions that take 5 or 10 seconds using the mouse. Use of these keys for selecting, copying, pasting, and moving text around has become almost second nature for me. However, this streamlined use completely disappears when I am forced to use a new keyboard whose layout differs. my current keyboard (MS Wired 500) has the control block keys in a vertically biased rectangle consisting of Home and End, Insert and Page Up, and Delete and Page down.

when I first bought the keyboard, such a layout was clunky and took a lot of work to get used to. it ruined many a programming and debugging session as my mind was taken from the task and hand and instead had to focus on retraining my muscle memory. It took nearly, if not over a month before I became as proficient as I was. Oddly enough, my laptop used a even stranger layout, whereby the control block keys were aligned down the right side of the keyboard in a single column- Home,Page up, Page down, End. Delete is positioned in a horizontal block of keys above those, containing what is often the rightmost set of function keys on the top of the keyboard, Print Screen, Pause, Insert, and Delete. due to this layout the Delete key is actually right above the home/end… etc block of keys. The laptop I use now, a Toshiba Satellite L300, has a keyboard layout very similar to it’s “ancient” predecessor whose layout I was used to, my Satellite Pro 440CDX. the 440CDX had a few “quirks” in the keyboard department, for example, the windows and application keys were moved from their normal position on the bottom row to the left and right of the spacebar, respectively, to pinky stretching positions at the upper right, where my newer model satellite has the insert and delete keys, who, on the 440 CDX, took up positions to the immediate left of the Tilde key, which was also moved to the bottom row of keys with the space bar. So the bottom row went Ctrl, Fn, Alt, Spacebar, Tilde/backtick, Insert,Delete left, down, right. this made any attempt to use the right alt key (which, admittedly, is usually rather neglected on the average keyboard anyway) actually press the tilde/grave key. However, and perhaps more important, attempts to press tilde (which, having to type the short file name for long file names comes up more often then some people might expect) will type escape. Which could do any number of things.

Anyway, my point is, it was completely different from the normal keyboard I was using for my desktop. And yet I was equally fluent with it, as it became my main development machine for quite some time (I’m referring to the 440CDX). Therefore the main cause for such familiarity isn’t really a set number of “memorized” layouts, but rather frequency of use. To test, I started up my old laptop. I noticed several interesting changes keyboard wise. for some reason, I had difficulty typing keys in the upper left. my fingers would try to strike a key that they/I thought was there, only to meet the spot between two keys or pressing hte wrong key altogether. Additionally, and not strictly related to the keyboard, I found myself having the exact opposite problem I did when I first went to adjust to the newer laptop; mouse movement.

The older laptop used the TrackPoint II, or licensed clone, which is a small stick sticking out between the g and h keys on the keyboard. it’s nearly stationary and detects angular movement on the stick and converts it to mouse movement on-screen. the newer technology that has become the norm for laptops is the touchpad. I cursed loudly when trying to use this at first, often trying to use the trackpoint instinctively to move to mouse, only to meet with nothing, then remembering the touchpad, cursing again, etc.. basically, it took some getting used to.

However, now, whenever I fire up the old 440CDX to make sure it hasn’t died, I find myself trying to move the mouse cursor with a non-existent touchpoint. The exact opposite issue I had when first adopting it.

That being said, the first conclusion one might reach is that learning the touchpad “pushed” the trackpoint II out of my mind. However, I believe this is purely a case of how much I use it; if I used them both equally, I’d probably always know exactly which one to use based on some other number of unknown mental stimuli that tell me which one it is, much as I know automatically wether to use the Desktop control keys or the laptop control keys based when I’m using one or the other. It’s rather a case of how often I haven’t used the trackpoint that has caused it to become a “second attempt” sort of interface.

Function keys

Another important and often described as “advanced” group of keys are the Function keys present on the top row of most keyboards. It was these keys that made my wireless keyboard completely unusable to me. Each block of keys is traditionally separated into groups of four. For some reason, the designers of my wireless keyboard decided to do so in groups of three. This completely screws up every single thing I do with any key other then F1,F2, and F3. For example, Pressing Control-F9 “naturally” (via “muscle memory” on that keyboard makes me press F7- the first key on the third set of keys. I would need to literally retrain my brain to use that keyboard as well, and I’d rather not go through the angst I did previously, especially not for a very specific layout which probably will not become standard even among MS keyboards.

However. Visual Basic six is over 10 years old. Mainstream support ended a few years ago, and after Vista Microsoft makes no promises that programs designed with Visual Basic 6 will work. Even creating programs that support the various UI features of XP could be a chore. With Vista, Not only does one need to include the proper manifest resource or file  to force their VB6 applications to link with the newer version of comctl32, but it is almost always necessary to include an additional set of directives in the manifest to make the program request administrator permissions. I have yet to determine why some of my less trivial programs crash before they even start when run with the same security as the user, but I imagine it’s directly related to COM components, their usage, and the permissions surrounding them.

Another area of concern is with the use of proper icons; Visual Basic complains when you try to use a icon with a alpha channel. However, through a few API techniques and some resource editor trickery, it’s possible to have your application use 32-bit icons both as the program file icon as well as the icon for your forms. Rather then repeat the material here, I will point you in the right direction if this type of this piques your interest. www.vbaccelerator.com- I cannot praise that site and it’s creator enough. While many of the projects and controls he has on-line I have personally attempted before finding the site (I had a somewhat working toolbar control and a control I called “menuctl” that allowed moving the main menu around as a toolbar), the sheer number of completed, documented, and well written controls on his site is simply mind-blowing. There is also a .NET section to his site as well, which brings me to my next point.

There are only a few reasons why a programmer would choose to use Visual Basic 6 for a new project today. The main reason is simply because we are stubborn, for the most part. The fact that .NET is better in many ways then VB6 does not sway us to use it. The fact is, we all feel “betrayed” in a way, but the shift to .NET. Millions of lines of code that were dutifully compatible through all 6 versions of Visual Basic 6 now break when loaded in VB.NET. But I believe, that the majority of VB6 programmers have simply been blinded to the number of problems Microsoft would have faced to continue using the same COM oriented framework that VB4 and higher have used.

COM,or, Component Object Model,(sometimes referred to as “Common Object Model” which is dead-wrong) is a Binary compatible method of providing interoperability between applications. COM was essentially designed to prevent what was known as “DLL hell”, since at that point in time DLLs provided their functionality through exposed functions, some versions not compatible with previous versions, meaning it might be necessary to, for example, have 5 different versions of MFC41.dll on ones PC. The idea was, each version of a COM component would be Binary compatible with the previous version, which means, for example, that a program designed for version 1 of “foocomponent” could still run and use version 4, but without the new features of version 4. This functionality was implemented by the creation of Interfaces. Each version of a component would add a new interface- for example, IFooComponent, IFooComponent2,IFooComponent3, etc, and client applications who want to use FooComponent would use the interface appropriate to the version they wish to use.

There was, however, one problem. Most of the maintenance between versions was left to the programmer of the component- they had to create the new interface, make sure previous interfaces worked, that old clients could still instantiate their objects, etc. Basically, it made the critical mistake of putting the user of the technology (in this case, the programmer) in a critical position and with a number of responsibilities to get things to work properly.

Microsoft, of all companies, should know that putting the programmer in a position of such responsibility is prone to failure; hell, many of them can’t even be bothered to follow standard API documentation; for example, actually reading the documentation; this resulted in hundreds of man-hours of programmer time being consumed by the creation of “compatibility shims” to let these programs work. (otherwise, installing a new windows OS would break these programs; they worked before, so as far as the user sees the new Operating System is to blame). Anyway- this failed miserably. Programmers would sometimes simply change their interfaces rather then implement new and old ones, meaning, like with the DLLs of before, new DLL versions were incompatible with the old ones.

It was clear that COM, or, at least, COM as it was presently designed, was far to dependent on the programmer to “do the right thing” then was reasonable. So, Microsoft, at some point, decided they needed a new object framework architecture.

VB6, as a COM-based language, would have required extensive changes to support this new architecture. the prospect of such a huge revision probably made them take a second glance at the language itself, and the cruft it still has from previous iterations of the basic language. aside from retaining such archaic constructs as the “GoSub…Return”, VB6 also “failed” in a sense on a number of other areas. Error-Handling, for example, was still done using “On Error” statements, which redirected flow to another segment of code. It was up to that block of code to evaluated the error, using the “Err” object (In VB1-3 there was only Err which was the error number and Error$, which was the description), and then either resuming that same statement that caused the error (Resume) skipping that line, and continuing with the next, (Resume Next) or even raising the error again, causing the error to cascade up through the call stack.

This Error architecture had a critical flaw- by using this form of error handling, flow could change to the error block for any reason, at any time. This meant that if the procedure dealt with resources, such as file handles or memory blocks, it would have to keep track of what needs to be undone so that the error code could also double as partial cleanup code. Another critical flaw was simply that it was ugly; it looked and functioned nothing like the Try…Catch statements in many other languages. Also, it could become impossible to trace exactly where an error occured when errors cascaded; and error handler might be forced to handle an error from three levels down in the call-stack, so even if it understood the error in the context of the procedure, the context that the original error occured in and exactly what it means was lost.

My main language is Visual Basic 6, but I am not so blind as to reject VB.NET, or .NET as a whole, merely because it essentially replaced VB6. The truth is- we, as VB programmers, have made a large number of requests to the VB developers. VB .NET answered and fixed a huge number of those requests, and yet it is still shunned; it is clear to me that it is not merely the loss of backwards compatibility that causes such antagonism with VB6 programmers, but also the human element of resistance to change.

With previous versions of Visual Basic, one could migrate all their code to the new version with little or no difficulty.

This, however, had a price- since the new version made few, if any, requirements for conversion, old antique code would often be upgraded and imported into the new environment. Since backwards compatibility was the rule, old elements such as line numbers gotos, and gosubs remained in the language. Antiquated concepts such as type declaration characters remained in the language. Such visages of a forgotten era had no place in a modern language.

All the above being said, VB6 is still a language capable of creating modern applications; however it is important for the programmers who still use it to realize that they aren’t using it because it is superior or because .NET or any other language “sucks” by comparison, but rather as a result of their own stubborness and unwillingness to learn new programming concepts.

A anecdote, if I may, can be found in my introduction to the use of “class modules” within Visual Basic. at first, I had no idea what they were- I simply shied away from them, and stuck to Forms and code modules. I used all sorts of excuses- Class modules are slower, they bloat the code, etc. All of which were, almost universally fabricated or found on the web written by grade 8 students who barely understood the meaning of the word “class” in the context of programming or objects.

After, however, creating ActiveX Controls using the “userControl” Object, I realized the similarities, and the possibilities that could arise. My first conversion attempt was on my Current “flagship” program, the game I called “Poing”. At that time, the entire game was designed using User defined types as functions that operated on them. I understood the concept of encapsulation and managed to convert the entire architecture to a Class based object heirarchy- and it worked. My concepts still contained flaws, such as including critical game logic in down-level objects, but for the most part my udnerstanding was sound.

As my understanding of the concepts involved improved, so too did my antagonism disappear. It was clear to me that the fact that I didn’t understand classes at the time lent itself to a distaste for them- basically, the old adage that one is “afraid” of what one doesn’t understand was at least partly true. This, I feel, is at the very core of the antagonism against .NET. the main detractors of the framework are often people that neither understand the concepts involved nor do they realize how said concepts add increased possiblities and easier maintenance.

Even so- .NET has, in my opinion, one critical flaw. the IDE is slow. even on my quad core machine I see huge delays as intellisense is populated or any number of other operations. Perhaps it is a result of a mere 7200RPM hard drive? I don’t know. perhaps I need more then my current 8GB of RAM? who knows. I think, that using a 10 year old program and expecting and recieving quick responses from it have perhaps jaded me in terms of what the extra features of the new IDE actually cost in terms of performance; the delays feel like minutes, but in general it is only a few seconds. On the other hand- a few seconds is a lot longer then necessary to make one lose their train of thought. At the same time, this same argument was used against the initial usage of Intellisense; and there is no denying that although the initial display of a number of said intellisense lists can take some time, subsequent usage is nearly instantaneous, and the lists provide far more in terms of function information then the VB6 OR C++ 6 IDE could provide; this, in addition to the ease of use of assemblies between multiple .NET languages is not something that should be passed up because of an ego-centric desire to prevent change. The IT industry changes constantly. The fact that VB6 is now a “past item” should not dissuade us from moving forward because of a snobbish desire or fictitious affection for the corridor of our programming efforts for many years; the complaints about VB6 when it was introduced were very vocal. This is, no different with VB.NET, however the very complaints made about VB6 that have been remedied with .NET are now being passed off as inconsequential (since in many cases programmers have devised ways of working around limitations or even forcing behaviour that VB6 was not designed for, such as, for example the creation of Command-line programs.

The mistake Microsoft made was not the creation of .NET, but rather the belief that any sane person would move to a new platform if it was superior. They forgot the take account of the psychological factors involved.