We help IT Professionals succeed at work.

Window proc vs. Dialog proc?

alexo asked
Last Modified: 2013-12-03

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?
Watch Question

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?



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.

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



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



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.

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?



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

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.



It was compiled with OWL.




Come on, 100 points are waiting...
This one is on us!
(Get your first solution completely free - no credit card required)


Suppose I am :-)

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

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.
Unlock the solution to this question.
Join our community and discover your potential

Experts Exchange is the only place where you can interact directly with leading experts in the technology field. Become a member today and access the collective knowledge of thousands of technology experts.

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.