Window or Dialog?

[Aldo Cavini]

Is it possible to know whether a handler corresponds to a Dialog or to a Window?

GetWindowLong can be used to retrieve the %DWL_DLGPROC value, which is only valid for dialogs (I tried it, on normal windows I get an error 1413).

Is this method reliable? Does it exist a better method?

Thanks

------------------

[Chris Boss]

Use GetClassName to find out the Class name for the Window/Dialog.

The Windows Dialog engine uses a classname which is a number. I think
it is something like "65535". I can't remember the number off hand, but
it is above 65000.

Other windows will use a different class name.

The %DWL_ constants (for getWindowLong) should only be used for actual
Dialogs and not Windows which have their own class. These values expect
a certain number of extra bytes used by Dialogs , which may not
exist for a another defined window class.



------------------

[Sven Blumenstein]

Dialog Classname: "32770"

------------------
E-Mail (home): mailto:[email protected][email protected]</A>
E-Mail (work): mailto:[email protected][email protected]</A>

[Chris Boss]

Thanks Sven;

Somehow 65535 stuck in my mind. 32770 is not quite above 65000.

I remember seeing a list awhile back with a number of classnames for
internal stuff in Windows, they all being numbers, but I couldn't
quite remember what the numbers were.

Aldo;

Now that you have the right classname for the Dialog class, you can
check for the class to see if it is a custom window class or the
default dialog class.



------------------

[Aldo Cavini]

Sven,

I noticed it is possible to use GetClassName on a DDT handler. The result is "#32770" (with the "#" char). Am I wrong?

Also I found it is possible to register a custom dialog class - in such a case, the name is no more significant.

Chris,

Now that you have the right classname for the Dialog class, you can check for the class to see if it is a custom window class or the default dialog class

My problem is, how to check for the class to see if it is the default dialog class?

Thanks


------------------

[Aldo Cavini]

The following is from http://msdn.microsoft.com/library/de...class_1kfn.asp

The following table describes the system classes that are available only for use by the system.

Class      Description 
----------------------------------------------------------------------
ComboLBox  The class for the list box contained in a combo box. 
DDEMLEvent Windows NT/2000 or later: The class for DDEML events. 
Message    Windows 2000 or later: The class for a message-only window. 
#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     Windows NT/2000 or later: The class for icon titles.

I thought about the method using GetWindowLong. If it is used on a window which has more than 12 extra byte of data, it can't work! Hence the only method I know at the moment is to get the window/dialog class name; if it is #32770, then it is a dialog. But I don't know how to do it if the dialog belongs to a custom registered dialog class.

------------------

[Chris Boss]

Aldo;

There may not be a 100% guaranteed way to know whether a Windows is
an actual Dialog.

If it is, it must use the Dialog classname.

If the class isn't right then the only way to see if it is a
custom Dialog class, is to use : GetClassLong

and compare the values for each member. For example the
value returned for the %GCL_CBWNDEXTRA flag, is the extra bytes and
this value must be 30 (there is an API constant for this) or greater
for the class to be able to work with DefDialogProc.

If the value is 30 or more, then you could assume it is a custom
Dialog, but there is no guarantee.




------------------

[Aldo Cavini]

Chris,

Thanks for the answer. There are many occasions I don't understand the APIs underlying philosophy... In some occasions it is important to know if a handle is a window or a dialog. For instance the DefDlgProc must not be called reentrantly...

Thanks again.

------------------

[Lance Edmonds]

Hang on, Aldo... what about when a SendMessage or CONTROL/DIALOG SEND occurs that goes to the same window procedure? That is definitely an (implicit) reentrant call...

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Aldo Cavini]

Lance,

I agree with you. OTH, this is from the Win32Api help file:

The DefDlgProc function must not be called by a dialog box procedure; doing so results in recursive execution.

As I stated before, "...I don't understand the APIs underlying philosophy..."

------------------

[Chris Boss]

Aldo;

The reason that DefDialogProc must not be called by a Dialog
procedure is quite simple !

All Windows have a Window procedure. While most of these Window
procedures are in the OS itself, they do use a Window procedure.

If you call DefDialogProc, you are calling the Dialog classes window procedure.
This function is usually used in a Window procedure for a custom
window class, which wants to emulate the Dialog class in functionality.

If this function is called, the window class must have the
necessary extra window bytes allocated (should be 30). One of the
Long values in the extra window bytes contains the address to a
Dialog procedure.

A Dialog procedure is not the same as a window procedure. A Dialog
procedure is a procedure which is called by a Window procedure and
the messages are passed to it. If they aren't processed by the
Dialog procedure, the window procedure will process them.

The code in DefDlgProc (the window procedure for the Dialog class)
passes the message to a Dialog procedure. If the Dialog procedure
then makes a call to DefDlgProc, then the code in DefDlgProc will again
pass the message to the Dialog procedure, which in turns again calls
DefDlgProc, and so on. You create an infinite loop (not good).

DefDlgproc should only be used in a custom window class, window
procedure. It should never be called by a Dialog procedure.

To Illustrate :

FUNCTION DefDlgProc (...)
' processes messages for Dialog class
' this is a Window procedure found in the OS itself
RV&=MyDialogProc(...)   ' passes messages to your Dialog procedure
IF RV&=0 THEN
    ' Dialog class either processes message or passes it to DefWindowProc
    FUNCTION=DefWindowProc(...)   ' If Dialog Procedure returns 0, then process
END IF
END FUNCTION
' 
'
FUNCTION MyDialogProc(...)
' if you pass a message to DefDlgProc here
RV&=DefDlgProc  
' then the function DefDlgProc will call this Dialog procedure again
' which in turn will pass the message back to DefDlgProc again,
' which in turn will do it again and again.
' you now have an Infinite Loop
END FUNCTION

------------------

[Aldo Cavini]

Chris,

thanks very much for the explanation. Now the topic is clear. Only one remark to do: "The reason ... is quite simple" - well, not so simple!

Aldo

------------------

[Lance Edmonds]

In "simpler" terms:

In (almost) all cases, do not explicitly call DefDialogProc() from within a Dialog Procedure (callback) as this API function is implicitly called by the dialog engine itself.


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>