>Hey Ed,
> Would you be so kind as to explain, if you know, what in the context of a process or a thread, the concept of a handle represents, as opposed to a token or an id?
>
Easy enough. A Process ID or a Thread ID is a unique DWORD identifying a process or thread on a global basis to the Windows subsystem; it serves as a unique, cross system identifier, which carries no descriptor or privilege information. A Process handle or Thread handle is an assigned reference to a process or thread object which is valid in the context that creates or inherits the handle; in addition to identifying the process or thread, it also details what access permissions apply when the object is referenced by the handle. Handles have scope, ids do not. Several processes may have the same handle in use at the same time for different objects, as long as they are not sharing handles by inheritance.
BTW, there are a whole lot more types of handles than processes and threads - files, Windows, mutexes, semaphores, events, pipes, ad nauseum. FWIW, the definition in the MSDN is
handle
1. A pointer to a pointer; that is, a variable that contains the address of another variable, which in turn contains the address of the desired object. In certain operating systems, the handle points to a pointer stored in a fixed location in memory, whereas that pointer points to a movable block. If applications start from the handle whenever they access the block, the operating system can perform memory management tasks such as garbage collection without affecting the applications. 2. Any token that an application can use to identify and access an object such as a device, a file, a window, or a dialog box. 3. One of several small squares displayed around a graphical object in a drawing application. The user can move or reshape the object by clicking on a handle and dragging.
Another good ref from the Office VBA docs
Understanding Handles
Another important concept that you need to understand before calling functions in DLLs is that of the handle. A handle is simply a 32-bit positive integer that Windows uses to identify a window or another object, such as a font or bitmap.
In Windows, a window can be many different things. In fact, almost anything that you can see on the screen is in a window, and most things that you can't see are also in windows. A window can be a bounded rectangular area of the screen, like the application windows that you're accustomed to. A control on a form, such as a list box or scroll bar, may also be a window, although not all types of controls are windows. The icons that appear on your desktop, and the desktop itself, are windows.
Because all of these types of objects are windows, Windows can treat them similarly. Windows gives every window a unique handle, and uses the handle to work with that window. Many API functions return handles or take them as arguments.
Windows assigns a handle to a window when it is created and frees the handle when the window is destroyed. Although the handle remains the same for the lifetime of the window, there is no guarantee that a window will have the same handle if it is destroyed and recreated. Therefore, if you store a handle in a variable, keep in mind that the handle will no longer be valid if the window is destroyed.
The GetActiveWindow function is an example of a function that returns a handle to a window — in this case, the application window that's currently active. The GetWindowText function takes a handle to a window and returns that window's caption if it has one. The following procedure uses GetActiveWindow to return a handle to the active window, and GetWindowText to return its caption:
Declare Function GetActiveWindow Lib "user32" () As Long
Declare Function GetWindowText Lib "user32" Alias "GetWindowTextA" _
(ByVal Hwnd As Long, ByVal lpString As String, ByVal cch As Long) As Long
Function ActiveWindowCaption() As String
Dim strCaption As String
Dim lngLen As Long
' Create string filled with null characters.
strCaption = String$(255, vbNullChar)
' Return length of string.
lngLen = Len(strCaption)
' Call GetActiveWindow to return handle to active window,
' and pass handle to GetWindowText, along with string and its length.
If (GetWindowText(GetActiveWindow, strCaption, lngLen) > 0) Then
' Return value that Windows has written to string.
ActiveWindowCaption = strCaption
End If
End FunctionThe GetWindowText function takes three arguments: the handle to a window, a null-terminated string into which the window's caption will be returned, and the length of that string. For more information about passing strings to DLL functions, see "Returning Strings from DLL Functions" later in this chapter.
The ActiveWindowCaption procedure shown in the previous example is available in the modActiveWindowCaption module in MiscAPIFunctions.xls in the ODETools\V9\Samples\OPG\Samples\CH10 subfolder on the Office 2000 Developer CD-ROM.
> I've been stumbling over this very issue so often for several years now. I'm awfully ashamed...
>
>TIA, Steven-
>
>
>>>>
>>>
>>>No, it is property of person, not of VFP. I believe that VFP developers have good
chanse to
become superior. When someone is permanently stupid, VFP never could make him more wise.
>>><
>>>
>>>If that is the case, the tool is independent. I then come back to my question f why you think VFP'ers are intellecutually superior to others...
>>
>>They have to be to escape the brain-damaging crutches imposed by the language. A simple test - what percentage of VFP developers know what in the context of a process or a thread, the concept of a handle represents, as opposed to a token or an id? I'd venture to guess that the percentage is vanishingly small, especially when compared to people developing in C++ or Java. The typical VFP programmer isn't aware of what the differences are, and won't lift a finger to learn it unless jabbed repeatedly with a powerful cattleprod. The lack of initiative on the part of the VFP developer community creates the need for 'backwards compatibility'. How much hue and cry came from the BASIC developers when BASIC transiteds to VB, and gave up a whole lot of 'backwards compatibility' in the process.
