DDT can i rely on ClassName #32770 (DIALOG)

[Ralph Berger]

Hi there,

just building some common controls for PBDLL.
When i create a dialog i don't want to do it like that :

FUNCTION PBMAIN

LOCAL hDlg AS LONG
DIALOG NEW 0, "demo", , , 120, 80, %WS_CAPTION OR %WS_SYSMENU OR %WS_MAXIMIZEBOX TO hDlg
CONTROL ADD "CustomClass", hDlg, 101, "", 10, 10, 100, 30, %WS_CHILD OR %WS_VISIBLE
DIALOG SHOW MODAL hDlg CALL DlgProc

END FUNCTION

To be GDI friendly i use a font and a brush cache which needs to be
updated before the control is created.

FUNCTION PBMAIN

LOCAL hDlg AS LONG
DIALOG NEW 0, "demo", , , 120, 80, %WS_CAPTION OR %WS_SYSMENU OR %WS_MAXIMIZEBOX TO hDlg
CONTROL_ADD_CustomClass hDlg, 101, "", 10, 10, 100, 30, %WS_CHILD OR %WS_VISIBLE
DIALOG SHOW MODAL hDlg CALL DlgProc

END FUNCTION

Is it ok to select pixel or unit by checking parent's class name ?

Ralph



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

[Eric Pearson]

DDT stands for Dynamic Dialog Tools, and the standard class name for all Windows Dialogs is 32770, so I'd say Yes, you can rely on it.

-- Eric


------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>

[Ralph Berger]

Eric;

thanks for the reply.
I'm a little concerned how PBDLL 7.0 will do it.
Maybe someone from R&D can confirm it ?

Ralph


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

[Ralph Berger]

- Just to be shure -
Try it under W98 & NT 4.
Is the className 32770 on W2K and ME ?

Ralph


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

[Chris Boss]

Ralph;

If I understand DDT correctly, it uses the Windows Dialog engine
(API functions for creating Dialogs, rather than CreateWindowEx).

Note: If I am wrong that DDT uses the Windows Dialog engine, then my
comments below would not apply. (Someone please correct me if I am
wrong about this).

This would mean the Class for DDT Dialogs is not defined by DDT, but is
defined by Windows. The Classname you get is likely one generated by Windows
and not DDT and I think the classname should be consistant among
platforms. The only way this would change in future versions of PB
is if they stopped using the Windows Dialog engine and used CreateWindow
directly. The use of the Windows Dialog engine is likely what makes
DDT lean and mean.


Now to the subject of custom controls:

IMO, it is actually better to write custom controls that can be created
using Control Add (or CreateWindowEx). The reason being it will be more
easily used by a variety of programmers.

Also, you control should use System GDI resources (System colors, system brushes
, system fonts) which are already predefined. If you want the programmer
to be able to change these, then make your controls respond to the
standard windows messages for changing such things.

Custom controls should respond to following messages
(if they are applicable to your control) :

WM_SETFONT
WM_SETICON
WM_SETTEXT

Your control should send one of the WM_CTLCOLORxxx messages
(ie. WM_CTLCOLOREDIT, WM_CTLCOLORSTATIC)
to the Parent Dialog as well to set its colors.

Also, you should emulate as many of the messages you can that are found
in a similiar class. For example if you were writing a custom edit control
that wasn't a superclass of the edit (meaning you don't use the original
edit control as a base class), you should attempt to emulate as many of
the messages the original edit control handles.

You can see this in the RichEdit control, which processes many of the
same messages as the regular edit control does. This consistancy
allows programmers to get up to speed quicker with your controls,
since they likely are already familiar with the standard controls.

While there is not hard fast rule that you must do things this way,
by following these your controls will be accepted by a larger number
or programmers. Even C programmers could use your controls !



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

[Semen Matusovski]

I don't understand, why it's necessary to have ClassName (GetClassLong uses hWnd), but anyway all information is available after Dialog New (because dialog is already exist).

  #Compile Exe
  #Dim All
  #Register None
  #Include "win32Api.inc"
  
  Function PbMain
     Local hDlg As Long
     Dialog New 0, "demo", , , 120, 80, %WS_CAPTION Or %WS_SYSMENU Or %WS_MAXIMIZEBOX To hDlg
     Dim lpClassName As Asciiz * %MAX_PATH
     GetClassName hDlg, lpClassName, SizeOf(lpClassName)
     MsgBox lpClassName
 End Function

------------------
E-MAIL: [email protected]

[Ralph Berger]

Got some mails how to get a classname.

FUNCTION isParentDDT( BYVAL hdlg AS LONG ) AS LONG
    LOCAL szClass   AS ASCIIZ * 80
    IF ISFALSE GetClassName( hdlg, szClass, SIZEOF( szClass ) ) THEN EXIT FUNCTION
    FUNCTION = ( INSTR( szClass, "32770" ) <> 0 )
END FUNCTION

Ralph


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

[Ralph Berger]

Semen;

getting parent's class Name is only a extra service in
CONTROL_ADD_CustomClass.
The user need not convert UNIT measures to pixel measures.
The control may do it if it's part of a DDT dialog.

Ralph

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

[Semen Matusovski]

Ralph --
Easiest way to recognize a dialog is using MapDialogRect (for non-dialog returns 0)



------------------
E-MAIL: [email protected]

[Ralph Berger]

Chris,

i'm working on a set of databound controls.
Main goal is to let the controls handle all drawing
and validating their own. The only thing they should do
is update the rowset buffer.

My CONTROL_ADD_CustomClass function has to this jobs:

fill unused properties with defaults
update font and brush cache if necessary
call createwindowex
check mem alloc done in controls %WM_Create event
if anything goes wrong return an error
set rowset.field properties
return


The only problem for c programers is that they can't
embed the controls in a RC file. Played a while
with my caches. Handling them only works when memory
allocation is done by the main program and not within
the DLL. But that's the way DLL's should do it.
Isn't it ?

Ralph

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