DefWindowProc - How do I know what it does?

[Gary Beene]

Still on the rant I added to the thread about Window Get ...

If I take the same code (bottom of this post), and add just two lines, I get what I want - the cursor to change to a horizontal shape when the cursor is over the label, then changes back to an arrow when the cursor moves away from the label.

MousePTR 9
Function = 1

With Function = 0, I read in Help that the message gets passed on to the default class window procedure for labels. In that case, the cursor seems to be returned to a standard arrow cursor. I didn't tell it to do that, so somewhere in the default window procedure the change was made.

But with Function = 1, not only does the cursor stay a "9" when over the label, but when the cursor is moved off the label and onto the dialog, the cursor returns to an arrow! Courtesy of the default class window procedure for dialogs?

So now I have to ask myself "What else does the default window procedure do? What things does it do that I want done, and what does it do that I don't want done?". I've not found a place in MSDN that tells me, so here I am again, learning stuff piece-meal!

The learning process works, it's just not very darned efficient! (although, I realize that lessons learned the hard way do stick better).

 #Compile Exe
#Dim All
#Include "Win32api.inc"

Global hDlg As Dword

Function PBMain()
    Dialog New Pixels, 0, "My Dialog",,, 100,100, %WS_OverlappedWindow , To hDlg
    Dialog Set Icon hDlg, "face"
    Control Add TextBox, hDlg, 551, "Button",  10, 10, 50, 50
    Control Add Label, hDlg, 200, "Button",  70, 10, 10, 60, %SS_Notify
    Control Set Color hDlg, 200, %White, %White
    Dialog Show Modal hdlg Call DlgProc()
End Function

' Dialog Callback Function ===============================================================

CallBack Function DlgProc() As Long
    'Console message list
    Static iMsgCount&
    CPrint Str$(iMsgCount&)+ " " + WinMsg(Cb.Msg)
    Incr iMsgCount&

    'Respond to messagess
    Static iCount&
    Dim Style As Long, iReturn As Long, hTemp As Dword, temp$
    Select Case Cb.Msg
        Case %WM_SetCursor
            Incr iCount
            Window Get Id Cb.WParam To iReturn
            'print:   control id + handle of window under mouse + dialog handle
            CPrint "SetCursor: " & Str$(iReturn) & " " & Str$(Cb.WParam) &  " " & Str$(hDlg)
            Select Case iReturn
                Case 200
                    CPrint Str$(iCount) + " H-setcursor"
                    MousePtr  9
                    Function = 1
            End Select
    End Select
End Function

Sub CPrint (SOut As String)    'Semen Matusovski's CPrint code:
    Static hConsole As Long, cWritten As Long
    If hConsole = 0 Then AllocConsole: hConsole = GetStdHandle(-11&)
    WriteConsole hConsole, ByCopy sOut + $CrLf, Len(sOut) + 2, cWritten, ByVal 0&
End Sub

[colin glenn]

And the answer is, you don't, you just need to read what the window message you're acting on requires from you in the way of passing back (or is it forward) a result to windows to further handle the message.

Quoting SDK
WM_SETCURSOR Notification
--------------------------------------------------------------------------------
The WM_SETCURSOR message is sent to a window if the mouse causes the cursor to move within a window and mouse input is not captured.

Syntax

WM_SETCURSOR

WPARAM wParam
LPARAM lParam;

Parameters

wParam

Handle to the window that contains the cursor.

lParam

The low-order word of lParam specifies the hit-test code.

The high-order word of lParam specifies the identifier of the mouse message.

Return Value

If an application processes this message, it should return TRUE to halt further processing or FALSE to continue.

Remarks

The high-order word of lParam is zero when the window enters menu mode.

The DefWindowProc function passes the WM_SETCURSOR message to a parent window before processing. If the parent window returns TRUE, further processing is halted. Passing the message to a window's parent window gives the parent window control over the cursor's setting in a child window. The DefWindowProc function also uses this message to set the cursor to an arrow if it is not in the client area, or to the registered class cursor if it is in the client area. If the low-order word of the lParam parameter is HTERROR and the high-order word of lParam specifies that one of the mouse buttons is pressed, DefWindowProc calls the MessageBeep function.

Or as the PB Manual puts it:

callbacks Callback Return Values

Callback functions always return a long integer result. The primary purpose of this return value is to tell the PowerBASIC DDT engine and the Windows operating system whether your Callback Function has processed this particular message. If you return the value TRUE (any non-zero value), you are asserting that the message was processed and no further handling is needed. If you return the value FALSE (zero), the PowerBASIC DDT engine will manage the message for you, using the default message procedures in Windows. If you do not specify a return value in the function, PowerBASIC chooses the value FALSE (zero) for you.

I have to "follow" that rule myself when handling a SendMessage from a child dialog to the parent dialog for some information the parent needs to pass back to the child, but only when the child is ready for the information. It may be that the data is actually ZERO, in which case, I still need to pass back a non-zero value just in case my user defined value for the SendMessage just happens to cause something within windows to do stuff, so I have to pass back my value +1 and remember to -1 from the results on the child's end. Note, in this case I am dealing with only positive values.

[Chris Boss]

It is important to distinquish between a Dialog procedure and a Window procedure.

A Dialog procedure is a mechanism for the Dialog window class to pass on messages to the application so it can process messages. The return value within a Dialog procedure serves a different purpose than it does in a Window procedure, since it tells the classes window procedure whether to do default processing.

There is no such thing in a window procedure!

In a window procedure, you let windows (the operating system) handle default processing by passing messages to the DefWindowProc API function and not by returning zero in the function. That processing is quite limited. Most window classes, have quite a bit of code processing many messages, rather than simply pass off messages to the operating system for default processing. For example, the default processing won't handle scrolling. The app must process the scrollbar messages and do its own scrolling. The defaults in windows won't send notification messages (ie. WM_NOTIFY).

Dialogs are a unique window class and dialog procedure are a means of fowarding messages to the app and should not be confused with a window procedure. The dialog class has its own window procedure in the operating system DLL's.

Control classes also have their window procedures in the operating system. You can subclass a control, to get access to its window procedure, but you have to pass back messages for default processing(the controls default, not windows in general) by calling the CallWindowProc API function to pass them back. Such subclassing window procedures should also not be confused with a Dialog procedure. You do not pass back zero to get default processing. You must call CallWindowProc to do that.