There is, however, further redirection within both other folders as well as The registry.

For example, the “real” %systemroot%\system32 folder actually stores the x64 system files; the 32-bit files are stored in %systemroot%\syswow64. However, when a 32-bit application access this system32, Windows automatically redirects all requests to the syswow64 folder, so accessing, say, “C:\windows\system32\file.txt” is actually accessing C:\windows\syswow64\file.txt. This includes any file operation at all. creation, editing, etc. there are a few folders exempt from this redirection- that is, they are not redirected. these folders include %windir%\system32\catroot,windir%\system32\catroot2,%windir%\system32\driversstore (this folder is redirected on all pre-windows 7 systems),%windir%\system32\drivers\etc,%windir%\system32\logfiles,%windir%\system32\spool. There are a few other features, for example, running “C:\windows\regedit.exe” from a 32-bit program will in fact run the program from C:\windows\syswow64\regedit.exe.

An additional feature is that a 32-bit program can access the 64-bit folder, Vista adds a “sysnative” alias folder in the windows folder, by accessing C:\windows\sysnative instead of C:\windows\system32, one gains access to the real C:\windows\system32 folder rather then being redirected to C:\windows\syswow64. The caveat of this feature is that most programs have validations before they accept a filename; since sysnative is not an actual folder but rather an alias used by the redirector, many validations (including the standard Open/Save dialog) can fail, meaning that one cannot “force” the access to a specific file. the main purpose is for use by the application for various reasons, not so users can access files within the folder from 32-bit applications.

The registry posesses redirection as well; the HKEY_LOCAL_MACHINE hive on x64 systems contains a key called “Wow6432node”, when a 32-bit program accesses, for example, “HKEY_LOCAL_MACHINE\Software\company\app”, they are in fact accessing “HKEY_LOCAL_MACHINE\Wow6432node\company\app”- basically, it separates 32-bit machine-specific data from 64-bit data. The only caveat is that, unlike the file system redirections, registry accesses are “mirrored” across the two; for example, COM classes are stored in HKEY_LOCAL_MACHINE\software\classes. when either HKEY_LOCAL_MACHINE\software\classes or HKEY_LOCAL_MACHINE\wow6432node\classes are have keys within changed, the change is reflected to the other location.

Additionally, certain 32-bit compiled applications can be given special treatment; if the image file (exe,dll, ocx) has the IMAGE_FILE_LARGE_ADDRESS_AWARE flag set, wow64 (the windows 32 on windows 64 emulation layer) gives it a 4GB user-mode address space, whereas with a 32-bit system it would be given a 2GB user mode address space. the flag is required, rather then being the default behaviour, because such large addresses may not have been expected when the program was written; therefore, by adding the compiler flag, you are telling windows “yes, I understand and am able to deal with the larger address space in my program”. It doesn’t actually do anything to the program itself, just changes how windows deals it memory.

another special-case is with regard to program installers for some older 32-bit programs. Many such programs used a stub 16-bit windows 3.1 program to determine the windows version, and then, launch the 32-bit installer if possible. Since 64-bit windows cannot run 16-bit applications, Microsoft decided to hack about a little fix; the followint 16-bit installer technologies have 64-bit equivalents that will be launched instead:

Microsoft Setup for Windows 1.2

Microsoft Setup for Windows 2.6

Microsoft Setup for Windows 3.0

Microsoft Setup for Windows 3.01

InstallShield 5.x

the list of such redirections can be found in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\NtVdm64, the 64-bit equivalents are found in Syswow64.

For the most part, these changes make using a 64-bit operating system nearly indistiguishable from using it’s 32-bit equivalent; windows itself bears the brunt of the change, and the application developers pick up a little of the tail-end of it.

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