No announcement yet.

SDK Snippets In Work

  • Filter
  • Time
  • Show
Clear All
new posts

  • SDK Snippets In Work

    In the most recent gbSnippets release I started a section on SDK snippets. I included some basic reference information there and a few short examples on creating a window - mostly based on the PowerBASIC Inc samples.

    My plan is to basically take the other ~400 snippets currently in gbSnippets and provide equivalent SDK code and additional reference material.

    First, of course, I have to decide which snippets are DDT or SDK. A snippet need not be one or the other. Several recent posts will give some good defining information as well.

    So, I'm soliciting suggestions. Other than just brute forcing my way through the list, is there a better way to document the source code for the two approaches.

    I'll concentrate first on windows and controls - GUI stuff.

    Suggestions/comments (#1-#26, for example?) are welcome.

  • #2
    Gary, I think you are trying what I tried to example in the past (and found it futile at the time cause I did not understand both sides)

    Sure its not a 1 to 1 relationship, but the general idea could be

    DDT way: <Heres how DDT usually does it>
    API way: <Heres how M$ usually does it>
    and my own personal preference of a warning to not mix-match because the 2 may NOT be completely translate-able depending on how you use it
    Engineer's Motto: If it aint broke take it apart and fix it

    "If at 1st you don't succeed... call it version 1.0"

    "Half of Programming is coding"....."The other 90% is DEBUGGING"

    "Document my code????" .... "WHYYY??? do you think they call it CODE? "


    • #3

      Thanks for the comments. I'll keep them in mind.

      One point where I differ from some of the recent posts is that I WANT the option to mix and match. I want the best of both worlds.

      It may be true today that mix/match is a mine field, but I'd like to see a clearer commitment by PowerBASIC Inc that DDT and SDK will work together - are interchangeable in any mix/match combination a programmer chooses. If they are not, then as a minimum, the incompatibilities need to be well documented.

      PowerBASIC Inc has made it clear that DDT support is here to stay, and that it will grow, but plans for SDK-DDT compatibility don't seem as clear.

      In the mean time, I'll want to document for myself what will / will not work together. Recent posts have given some good guidance but it's spread out all over the forum. I'm definitely be adding a reference snippet summarizing/detailing what I find to be the limitations.

      As far as understanding both sides of the DDT/SDK coding, I'm clearly in a learning mode on the SDK side, but creating 200+ SDK snippets will shore up my experience in that area pretty quickly!

      Last edited by Gary Beene; 23 Sep 2009, 08:57 PM.


      • #4
        > but plans for SDK-DDT compatibility don't seem as clear.

        "SDK-DDT compatibility" discussions really only apply to the creation and managment of screens.

        Outside of screen creation and management, much of the PB compiler is about making wrappers for various WinAPI functions. You can make those calls yourself if you want, but it would seem kinda silly to me to NOT use the high-level language features.... after all, that's why you licensed a high-level language compiler in the first place, no?

        It's really only in 'screen management' that there is a true fork in the road: if you decide to create a screen with DIALOG NEW, you are on the DDT road and should use DDT commands to manage that screen.

        If you decide to create that screen with CreateWindowEx, DialogBox[Indirect][Param] or CreateDialog[Indirect][Param] you've chosen the SDK fork and DDT commands are not supported when called against those handles.

        So BEFORE you start writing code, ask yourself if you can do what you want to do using DDT screen creation and commands, SDK screen creation and commands, or either? "Can" here meaning, both supported by the command set AND you have the skills to do it using that command set. Your fork in the road has been chosen.

        (Sorry, yes: this does mean you have to THINK before you start writing code. I know that can be a real bummer, but them's the facts).

        Michael Mattias
        Tal Systems (retired)
        Port Washington WI USA
        [email protected]


        • #5

          Yes, I've been thinking ... about what constitutes a DDT command. There are some ~750 support PowerBASIC commands. After taking out the common-first-word variations such as these:

          Array (6), Clipboard (9), Combobox (16), Comm (9), Control (51)
          Dialog (26), Display (5), Font (2), GlobalMem (5), Graphic (53)
          ImageList (11), ListBox (16), ListView (33), Menu (11), Object (5)
          ProgressBar (6), Scrollbar (7), TAB (8), TCP (8), Thread (9)
          Toolbar (7), TreeView (23), UDP (5), XPrint (57)

          **number in () is how many variations on the statements there are in Help

          there are still another ~350 PowerBASIC statements.

          So your comment is dead on about thinking before leaping.

          To create an all-SDK library of snippets I have to decide which of these fit in each category - for that matter, what defines the categories.

          I'm definitely a fan of using the highest level, easiest to use available tool.

          In general, my goal for an SDK snippet library wasn't to find the optimum solution, but to understand how the two approaches differ. Clarifying the compatibility issue between SDK/DDT is in there also. As you noted, should I avoid PowerBASIC-API-wrappers in SDK snippets, or should I only avoid those PowerBASIC statements which are related to windows, or those which represent compatibility issues?

          I have absolutely no plans for a 3rd library of some undefined-combination-of-the-best-of-the-two. My guess is I'll work a few examples and decide on rules-of-content as I go.

          I don't have a final answer. It's easy to say SDK vs DDT, but the devil is in the details.

          I'll think more on it.


          • #6
            Thinking ...

            In the worst case (worst case for my time), one could make a table of PowerBASIC statements and indicate what the equivalent statement(s) would be to perform a similar function using API.

            Some, like these, would be easy. Others might take many lines to get a comparison.

            [B]PowerBASIC                API[/B]
            Beep                      Winbeep
            Control Send              SendMessage
            And some would be less obvious, not knowing how the compiler was coded. For example, I can guess, but I don't really know how ABS or SIN are done - custom code or an API out there somewhere? With DIR$, I assume there are API that do it, and even though I'd generally be happy using DIR$, I'd think the API version should go in the SDK library.

            Ouch! This thinking thing is turning the task into more effort than perhaps I wanted to volunteer for!


            • #7
              <but to understand how the two approaches differ

              If you ask me, they don't differ at all.

              "I need to do <something>."

              "What statement/function/combination of same can help me do that? "

              "Are there any restrictions on using that statement or function?, For example, in context: is that statement/function (eg 'CONTROL SET TEXT') supported when my screen was NOT created using 'DDT' methods?"

              Michael Mattias
              Tal Systems (retired)
              Port Washington WI USA
              [email protected]


              • #8
                Some, like these, would be easy. Others might take many lines to get a comparison.
                PowerBASIC                API
                Beep                      Winbeep
                Control Send              SendMessage
                You are missing the most important column of all:

                [B][COLOR="Red"]WHAT[/COLOR] [/B]                              PowerBASIC                API
                --------------------          --------------          ----------------------
                Sound speaker                   Beep                         Winbeep
                Send message to control     Control Send              SendMessage
                Prepare disk file for I-O       OPEN                        CreateFile
                Make Screen                     DIALOG NEW              CreateWindowEx 
                Message Loop                   DIALOG DOEVENTS      GetMessage
                                                                        + IsDialogMessage
                                                                        + Translateaccelerator 
                                                                        +  TranslateMessage
                                                                        + DispatchMessage
                Last edited by Michael Mattias; 24 Sep 2009, 10:24 AM.
                Michael Mattias
                Tal Systems (retired)
                Port Washington WI USA
                [email protected]


                • #9
                  DIALOG NEW is not the same than CreateWindowEx

                  and what about TWIPS and PIXELS that are not compatible!

                  Last edited by Patrice Terrier; 24 Sep 2009, 10:59 AM.
                  Patrice Terrier
                  Addons: GDImage.DLL 32/64-bit (Graphic library), WinLIFT.DLL 32/64-bit (Skin Engine).


                  • #10
                    I didn't miss it, you just didn't like where I put it.

                    ... to perform a similar function using API.
                    All of my snippets are titled by the task they perform (well, maybe not every single one, but that's the general rule).

                    Still, the point you highlight is appropriate. The goal of coding is to perform tasks and the approach is usually secondary.

                    In the case of DDT, however, the SDK-compatibility issue is a snag, forcing the programmer to make choices based not only on results. Along those lines, other posts also show that senior programmers sometimes take the SDK route for other reasons - such as portability into other languages or distancing themselves from DDT version differences.

                    In my case of creating a SDK snippet library, the goal is to show a way to write apps without using the DDT tools PowerBASIC provides - to be able to make informed coding choices every time I write an app.

                    I expect that regardless of what I learn about SDK, I"ll use DDT whenever I can and fall back on SDK when it's needed. But with an SDK library (and the learning experience of creating it) in hand, at least I'll know what to fall back on.


                    • #11
                      >DIALOG NEW is not the same [as] CreateWindowEx

                      Who said they were the same? I said either creates a screen!

                      I also left out all the "ORs" eg DialogBox[Indirect][Param] or CreateDialog[indirect][Param] to create a screen, or a slightly more complex way to do a message loop:
                           WHILE PeekMessage( msg, %NULL, %NULL, %NULL, %PM_REMOVE) 
                                 if msg.message = %WM_QUIT   THEN               
                                    EXIT, EXIT
                                    IF ISFALSE IsDialogMessage (ghCurrentTabDlg, msg) THEN
                                           IF ISFALSE IsDialogMessage (hDlg, msg) THEN
                                                 TranslateMessage msg               'nope, so dispatch it
                                                 DispatchMessage  msg
                                           END IF
                                    END IF
                                 END IF
                           Result = MsgWaitForMultipleObjects (2&, BYVAL VARPTR(hEvent(0)), %FALSE, %INFINITE, %QS_ALLINPUT)
                           IF  Result = %WAIT_OBJECT_0 + SubPayerEvent then
                                   PostMessage hDlg, msgPayerChange, 0, 0
                           ELSEIF  Result = %WAIT_OBJECT_0 + SubProviderEvent then
                              PostMessage hDlg, msgProviderChange, 0, 0
                           ELSEIF Result = %WAIT_FAILED  THEN
                              MSGBOX "MsgWaitForMultipleObjects Failed", %MB_ERRSTYLE, $MB_ERRTITLE
                           'ELSEIF result = %WAIT_OBJECT_0 +2  THEN   
                           ' just allow fallthru will get picked up above
                              MSGBOX "Returned from MsgWaitForMultipleObjects with unexpected result index=" & STR$(Result - %WAIT_OBJECT_0),%MB_ERRSTYLE, $MB_ERRTITLE
                           END IF
                      The bottom line is, I think programmers are better when they think about "what" before thinking about "how."

                      Michael Mattias
                      Tal Systems (retired)
                      Port Washington WI USA
                      [email protected]