asked on

Window proc vs. Dialog proc?

What is the difference between a window procedure and a dialog procedure?

I tried subclassing a dialog and it didn't work when I used DWL_DLGPROC but worked OK when I used GWL_WNDPROC. Why?

MSVC help is confusing. It says:
"Dialog boxes usually belong to a predefined, exclusive window class. Windows uses this window class and its corresponding window procedure for both modal and modeless dialog boxes. When the function is called, it creates the window for the dialog box, as well as the windows for the controls in the dialog box, then sends selected messages to the dialog box procedure. While the dialog box is visible, the predefined window procedure manages all messages, processing some messages and passing others to the dialog box procedure so that the procedure can carry out tasks. Applications do not have direct access to the predefined window class or window procedure, but they can use the dialog box template and dialog box procedure to modify the style and behavior of a dialog box."

Can you explain that one?

vinniew

The wndProc equivalent for a dialog box is done internally to speed it up and use less resources. It's not that difficult to switch to using a wndProc, and you'll get the same result.

what are you subclassing, anyway? Edit control?

Hasta,
v

alexo

ASKER

I'm in my dense mode today. Care to explain your answer? I didn't get it.

I'm subclassing a dialog consisting of several controls.
I need to do it cause it belongs to another application.

vinniew

Oh, so you're hooking a DlgProc, or trying to, anyway. What are you trying to do to the dialog?

Hasta,

V

vinniew

I meant, specifically, what are you trying to do to the dialog?

V

alexo

ASKER

I added a button to it + some functionality.

however, let's get back to the question.

Subclassing via SetWindowLong(DWL_DLGPROC) failed but subclassing via SetWindowLong(GWL_WNDPROC) works. Why? Common sence says it should be the other way around.

vinniew

If you notice, anything created by MFC, dialog box or not, compiles down to using wndProc. I would bet that the dialog box you're trying to screw with was created with MFC and not by straight C.

You can test this idea by using the listdlls.exe off www.ntinternals.com; if it's using MFCxxx.dll, it was created using MFC.

What do you think?

Hasta,
V

alexo

ASKER

I'm not using MFC. It's straight C and Win32 API.

vinniew

OK, you're not using MFC, but what about the dialog box?
I think that it was probably compiled with MFC if it isn't responding to dlgproc-specific hooks.

V

alexo

ASKER

It was compiled with OWL.

alexo

ASKER

Anybody?

alexo

ASKER

Come on, 100 points are waiting...

ASKER CERTIFIED SOLUTION

Tiutin

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

alexo

ASKER

Suppose I am :-)

This begins to make sence but I'd like some more details if possible.

Tiutin

SDK Documentation says further:

"...When Windows starts, it registers a set of system global classes. The following table describes the system global classes:

Class            Description

Button            The class for a button.
ComboBox      The class for a combo box.
ComboLBox      The class for the list box contained in a combo box.
Edit            The class for an edit control.
ListBox            The class for a list box.
MDIClient      The class for an MDI client window.
Message            The class for a message-only window (Windows NT 5.0 and later).
ScrollBar      The class for a scroll bar.
Static            The class for a static control.
#32768            The class for a menu.
#32769            The class for the desktop window.
#32770            The class for a dialog box.
#32771            The class for the task switch window.
#32772            The class for icon titles (Windows NT only).

An application can subclass any window in the system;
however, when subclassing a window it does not own,
the application must ensure that the subclass procedure
does not destroy the original behavior of the window.
Because the application does not control the window,
it must not depend on information about the window
that the owner might change in the future.

An application should not use the extra window bytes or
the class bytes for a window without knowing exactly
what the bytes mean and how the original window procedure
uses them. Even so, the application should not use them
unless it owns the window.
If the application uses the extra window bytes of a window
that another application owns and the owner changes some
aspect of the extra bytes, the subclass procedure may fail.
For this reason, an application should not subclass a window
that belongs to a system global control class.
Windows owns the system global classes, and aspects of the
controls might change from one version of Windows to the next.
If the application must subclass a window that belongs to a
system global class, the developer may need to update the
application when a new version of Windows is released...".

I guess this is a reason why dialog box subclassing may fail.
Regards.