Announcement

Collapse
No announcement yet.

DDT can i rely on ClassName #32770 (DIALOG)

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Ralph Berger
    replied
    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

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

    Leave a comment:


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



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

    Leave a comment:


  • Ralph Berger
    replied
    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

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

    Leave a comment:


  • Ralph Berger
    replied
    Got some mails how to get a classname.

    Code:
    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


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

    Leave a comment:


  • Semen Matusovski
    replied
    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).

    Code:
      #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]

    Leave a comment:


  • Chris Boss
    replied
    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 !



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

    Leave a comment:


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

    Ralph


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

    Leave a comment:


  • Ralph Berger
    replied
    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


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

    Leave a comment:


  • Eric Pearson
    replied
    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>

    Leave a comment:


  • Ralph Berger
    started a topic DDT can i rely on ClassName #32770 (DIALOG)

    DDT can i rely on ClassName #32770 (DIALOG)

    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



    ------------------
Working...
X