Announcement

Collapse
No announcement yet.

SDK Snippets In Work

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

  • Michael Mattias
    replied
    >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:
    Code:
     DO
         
         WHILE PeekMessage( msg, %NULL, %NULL, %NULL, %PM_REMOVE) 
               if msg.message = %WM_QUIT   THEN               
                  EXIT, EXIT
               ELSE                  
                  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
         WEND
         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
         ELSE
            MSGBOX "Returned from MsgWaitForMultipleObjects with unexpected result index=" & STR$(Result - %WAIT_OBJECT_0),%MB_ERRSTYLE, $MB_ERRTITLE
         END IF
     LOOP
    The bottom line is, I think programmers are better when they think about "what" before thinking about "how."

    MCM

    Leave a comment:


  • Gary Beene
    replied
    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.

    Leave a comment:


  • Patrice Terrier
    replied
    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.

    Leave a comment:


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

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

    Leave a comment:


  • Michael Mattias
    replied
    <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?"

    MCM

    Leave a comment:


  • Gary Beene
    replied
    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.

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

    Leave a comment:


  • Gary Beene
    replied
    MCM,

    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.

    Leave a comment:


  • Michael Mattias
    replied
    > 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).


    MCM

    Leave a comment:


  • Gary Beene
    replied
    Cliff,

    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!

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

    Leave a comment:


  • Cliff Nichols
    replied
    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

    Leave a comment:


  • Gary Beene
    started a topic SDK Snippets In Work

    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.
Working...
X