SDK Snippets In Work

[Gary Beene]

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.

[Cliff Nichols]

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

[Gary Beene]

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

[Michael Mattias]

> 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

[Gary Beene]

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.

[Gary Beene]

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!

[Michael Mattias]

<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

[Michael Mattias]

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

......

[Patrice Terrier]

DIALOG NEW is not the same than CreateWindowEx

and what about TWIPS and PIXELS that are not compatible!

...

[Gary Beene]

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.

[Michael Mattias]

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

 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