No announcement yet.

The DDT improvements topic

  • Filter
  • Time
  • Show
Clear All
new posts

  • The DDT improvements topic

    This topic should be used to make suggestions regarding DDT, i'll make a few posts but i have much more thoughts on how the PB's formengine should be.
    In time we'll come to that.
    It's pointless to discuss work-arounds, we know them all by now.

    At first i'll show some of the things which imo should be changed, it's possible PB does not change the current DDT due its impact it would have, maybe we can establish a newer form engine named Window... instead of Dialog...

    Here are a few things wich imo should be changed.

    First the callback procedure is provided during the show modal or modeless call.
    This is not common and the callback should be set during form creation at least.
    This would also make a better behaviour since in it's initial state a different windowprocedure is set, once the dialog show calls + callback are executed, a new dialog procedure is set.
    This confuses the programmer + not all messages are now passed.
    The use of a callback may still be optional, it's not related.

    The windowstyle WS_VISIBLE has no meaning for DDT.
    A secundairy call like dialog show... or whatever 'show' API is required to show the dialog.
    The style should work right away.
    Even more.. i can not create hidden forms if i want to make it my main form shown modal.
    Think of a tray application.
    Briefly show the main form is hobby.

    My example below shows a design flaw regarding the WM_INITDIALOG message, this message will never be invoked twice by Windows, but it is executed twice by the DDT engine in this case.
    By following step #1 and #2 this could have been prevented.
    This code shows that this message is called twice, the 2nd could have been stopped.
    Often people tend to create the controls inside this message, while i find this a bad idea.. it happens, code may be executed twice, this is not good.

    Removing the callback from the modal part does not prevent this as well, since it discards the custom callback from the dialog.


    The messagepump should barely be related to the form, it's a secundairy step in the process, as it is right now it makes to much part of the form(-creation).
    Later on i'll discuss the messagepump.

    %ID_FORM1_TEXT1 = 100
    %ID_FORM1_BUTTON1 = 101
    CallBack Function Form1_Proc
        Select Case CbMsg
        Case %WM_INITDIALOG
            MsgBox "WM_INITDIALOG"
        Case %WM_COMMAND
            Select Case CbCtl
            Case %ID_FORM1_BUTTON1
                Select Case CbCtlMsg
                Case %BN_CLICKED
                    MsgBox "CLICK"
                End Select
            End Select
        Case 10000
            Control Set Text CbHndl, %ID_FORM1_TEXT1, Time$        
        End Select
    End Function
    Function Test() As Long
        Local hDlg As Long
        Dialog New Units, 0, "title$", , , 200, 200, %WS_SYSMENU Or %WS_VISIBLE To hDlg
        Control Add "Edit", hDlg, 100, "Text1", 16, 10, 67, 21, %WS_CHILD Or %WS_TABSTOP Or %WS_VISIBLE Or %ES_LEFT Or %ES_AUTOHSCROLL, %WS_EX_CLIENTEDGE
        Control Add "Button", hDlg, 101, "Button1", 16, 34, 67, 21, %WS_CHILD Or %WS_TABSTOP Or %WS_VISIBLE Or %BS_NOTIFY Or %BS_CENTER Or %BS_VCENTER Or %BS_MULTILINE, 0
        Dialog Show Modeless hDlg, Call Form1_Proc
        ' Just something i would like to do..
        SendMessage( hDlg, 10000, 0, 0 )
        Dialog Show Modal hDlg, Call Form1_Proc
    End Function