The revisions are pretty easy; in my case, I created a structure to hold what I previous had in a few module-level variables, to keep track of various data about each consecutive “click set” if that is a proper word to use here. Things such as the first click position, the last click position (these will obviously be the same for the “first” consecutive click (which is just a single-click, really) but could be used in later clicks to compare the distance values used, retrieved via GetSystemMetrics() using the SM_DRAGX and SM_DRAGY constants,(or was it SM_XDRAG and SM_YDRAG…) and comparing these values with the difference between each successive click. The ideal solution would be to compare each click position with the first click position, so that the clicking cannot move across the object very far from where the first click took place. The logic is pretty simple, and should be easy to follow. The project can be downloaded from here.This is a tad different then the previous one, and is instead implemented as a sort of  “game”.

There are a few design and User interface considerations when using Multiple clicks in your UI; the most prevalent is probably that unless you tell your users that they can triple-click or quadruple click, they likely will not try it- that is, it isn’t really that intuitive. Additionally, when you do implement this behaviour, remember that, for example, with a triple click, a double click was already fired and handled before that; so don’t make successive clicks do vastly different things. the ideal scenario is to use successive clicks to do the same thing, but change the scope; for example, Word allowed you to click,double-click, and triple click text. the first click sets the position of the cursor, the second click selects the word that the cursor is in, and a triple click selects a paragraph. (In the outlook editor it actually selects the sentence I think, but let’s not split hairs…). In fact, it would make sense to conclude that as an unsaid rule you should only use triple clicks to build on behaviour that the single and double-clicks before them have already done, just as word does. if you make triple-clicks do something esoteric, such as, for example, triple clicking a drawing to save, consider instead opting for a toolbar button or menu item to perform this task, or perhaps a key combination (or both).

The triple-click is a awkward sort of mouse input; but it’s quite simple to detect. It’s three clicks in a row. However, this is not what the program will see. For the most part, the program will see Mousedown,Mouseup,mousedown,doubleclick,mouseup; that is, windows will replace the mouse-down with the double-click message.

Visual Basic, and of course a number of other programming environments, translate windows messages into events of some sort. Specifically, Visual Basic has Click, Double-Click, mouseup, and mousedown. the behaviour and ordering mentioned above can be seen if one is  to log the events as they occur.

Detecting triple clicks is pretty easy, however; the idea is that a “triple click” is when you click three times and each click is within the double-click time from the previous click. this is easily facilitated by recording the DoubleClick time and testing the difference between the next click time and the previous click, and, if it is less then the doubleclicktime() (retrieved by the GetDoubleClickTime() API function) then register it as a TripleClick.

But such a mess! why not make a reusable class that can be used whenever triple-click functionality is desired? This is how I handle this type of problem- a missing event; I usually create a new class that raises that event, and only requires to be initialized and told what object it’s checking.Thus is born the CTripleClick class.

But exactly how, from the class’s perspective, does it achieve it’s functionality? There are actually a few options, of different complexity- the easiest, and maybe the safest, would be to use the Visual Basic “withevents” keyword on the object in question. However, this is problematic in that the CTripleClick Class is intended for use in various scenario’s- it might be used to detect triple-clicks on commandbuttons, pictureboxes, forms, usercontrols, and any number of other objects. Withevents, however, requires a specific classname. the “VBControlExtender” object can be used for controls, but we’d still need to hook a Form, Usercontrol, and all the intrinsic controls in different withevents variables. So that method is out of the question. There is one alternative, however.

Subclassing

Subclassing can provide a short and sweet solution to this problem. The way I used to subclass- the “unsafe” way, was to leverage Visual Basic’s “addressof” keyword and use SetWindowLong to redirect the window Procedure to my routine. This is unsafe because pressing the end button or even usually going into break mode, will cause Visual Basic to crash completely. This is the main reason many VB6 programmers avoid subclassing like the plague.

However, I have come across several implementations of safer subclassing methods that also do away with the Module dependency- thus making it possible to subclass as well as have no modules in a project, if that is desired for some reason. The implementation I have been using is from Planet-Source-code; namely, this entry, which I believe to be a excellent implementation. Other implementations can be found at such places as VBAccelerator, but this is the one I was used to, so I used it .

Subclassing is a fairly simple concept; you “take over” the messages being sent to a window. You can then decide if you want to pass the message along to the “true” recipient, or keep them in the dark about it. The reason this particular trait  is important is that it is necessary for the objective of this class. My intent is to emulate what the double-click event does; that is, Windows sends Mousedown, mouseup,double-click,mouseup. When somebody triple-clicks, the intended messages that would be sent should be Mousedown,Mouseup,doubleclick,mouseup,tripleclick,mouseup. This will require us to hide the mousedown message that triggers the tripleclick event we fire.

My first attempt at this had some side-issues. I was hiding mouse-down perfectly fine, by setting the “lhandled” byref argument passed into my iSuperclass implementation to true. However, this also caused a few odd issues both with VB events and the way the windows reacted, mostly related to mouse capture. The solution was to call “DefWindowProc” which performs the default operations for a window. In this case, it handles the focus and mouse capture of the window.

For further study, consult the source I made for this, in a test project called, rightly enough, TripleClick. I have uploaded it here:

here

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.