Terminology - SDK vs DDT

[Gary Beene]

I was writing an explanation of code concerning these two lines.

Control Send hDlg, %ID_RichEdit, ...
SendMessage hRichEdit,  ...

I started to say that the 2nd line was SDK style coding, whereas the first list was DDT-style coding. But, that didn't seem quite right. In general, I think of SDK as using windows generated with CreateWindow rather than with Dialog New - windows vs dialogs.

What would you SDK folks call the difference between the two top lines? SDK vs DDT, or what? "Using Windows API functions vs PowerBASIC functions" would seem more appropriate, since the origin of the windows doesn't affect the way the two lines are written.

Once a window is created, say with SDK, there are still many PowerBASIC DDT commands which can be used, so I assume there can be "pure" SDK as well as hybrid "SDK+DDT" coding styles. And, perhaps there are limits in how the two can be used together - I haven't done a pure SDK yet know what those limits might be.

I just haven't seen any discussion on the terminology of the mixed usage, or of comparisons of two specific lines of code. I've seen that most SDK-DDT comparisons are not simple line-for-line substitutions, so the 1-for-1 comparison above may not be such a good example, but it's the one that got me thinking.

Generic comments would be appreciated. Wax philosophically as you wish.

[Edwin Knoppert]

>I've seen that most SDK-DDT comparisons are not simple line-for-line substitutions
Show me a few to argue about.

The Windows API is a bit odd for naming its functions since the use 'dialog-calls' for custom Window classes as well like:

Control Send hDlg, %ID_RichEdit, ...
SendDlgItemMessage hDlg, %ID_RichEdit, ...

[Michael Mattias]

Once a window is created, say with SDK, there are still many PowerBASIC DDT commands which can be used

None of which are supported in this case.

DIALOG ... and CONTROL... statements are only supported for dialogs/controls created with DIALOG NEW and CONTROL ADD.

It "works?" Neophyte's serendipity.

MCM

[Jeff Blakeney]

Instead of saying "Using Windows API functions vs PowerBASIC functions" you couild instead say it is "SDK vs DDT style" or "Windows SDK vs PowerBASIC DDT style".

These three DDT commands:

DIALOG SEND  hDlg,      msg&, wParam&, lParam& TO lResult
DIALOG POST  hDlg,      msg&, wParam&, lParam& TO lResult
CONTROL SEND hDlg, id&, msg&, wParam&, lParam& TO lResult

Are the equivalent of these three SDK commands:

       lResult = SendMessage(hDlg,      msg&, wParam&, lParam&)
       lResult = PostMessage(hDlg,      msg&, wParam&, lParam&)
lResult = SendDlgItemMessage(hDlg, id&, msg&, wParam&, lParam&)

These may not be the best examples of there being differences between DDT and SDK style programming as they have single line equivalents.

Which style you use is up to you but I personally lean toward SDK style because if others with no PowerBASIC experience can still have a chance to understand my code if they have any SDK experience. Even if they haven't worked with the SDK before, it is easy to find information on the internet about the SDK commands but there is limited help available online for DDT. Also, problems can arise from mixing DDT and SDK code and I can never remember what you shouldn't do so I try to stick with one style and as I can do more with SDK, this also has me favouring SDK style programming.

[Michael Mattias]

It's actually quite simple on the "rules" for mix-and-match:

Windows' API calls may be used on any window handle returned by DIALOG NEW or CONTROL HANDLE.

DDT calls should only be used against windows created with DIALOG NEW or CONTROL ADD.

True, CONTROL SEND/POST is implemented as a call to SendMessage or PostMessage, but since CONTROL SEND and CONTROL POST are proprietary parts of the PowerBASIC language, that's only true in the current compiler release and is subject to change without notice.

Not that I can think of a better way to implement CONTROL SEND, but you have to be aware that the folks in Florida might come up with 'another way' to do a lot things you and I might do differently.

MCM

[Michael Mattias]

Here's an example.... In 4x/8x, GRAPHIC WINDOWs could be subclassed using the handle returned by the GRAPHIC WINDOW NEW statement, and such subclassing affected the actual window on the screen interacting with the user.

In 5x/9x, that handle is a handle to a 'container' window, and when subclassed does not behave as it did in 4x/8x. The folks in Florida obviously found 'another way' to do something, and did it.

Anyone who relied on the assumption that the "hWin" was "the" control had to do some repair work; however, those who used only the intrinsic functions to manage their window had to do exactly nothing.

[Patrice Terrier]

DDT is based on the CreateDialog API that is a subset of the CreateWindowEx API.

SDK coding style could be ported directly from one language to another without extra work, while DDT couldn't.

...

[Michael Mattias]

>DDT is based on the CreateDialog API...

==>DDT is currently based on the CreateDialog API ...

(DialogBox[Indirect][Param] for modal?)

[Patrice Terrier]

Currently "#32770" ...

#32768 the class for a menu.
#32769 the class for the desktop.
#32770 the class for a dialog box.
#32771 the class for the task switch window.
#32772 the class for icon titles.

[Edwin Knoppert]

These are not classnames due to the #
These are numbers but as #+number they are converted to a word.
Afaik these are atom's.

Speaking about 'classname' is the wrong term imo.
It's more like a class ID.

[Michael Mattias]

>Currently "#32770" ...

>These are not classnames due to the #
>These are numbers but as #+number they are converted to a word.
>Afaik these are atom's

Maybe it's just better to call it "a DDT-created dialog?"

MCM

[Patrice Terrier]

>>Speaking about 'classname' is the wrong term imo.

That is the term being used by Microsoft himself on MSDN, imo

[Edwin Knoppert]

[Gary Beene]

Thanks for all the inputs.

To my original question, a comparison of just those two statements would seem to be "DDT vs direct use of API", rather than some use of the phrase SDK-style programming.

From this discussion, and other I've read on the forum, the term SDK seems to be consistently defined as creating windows using the CreateWindowEx API.

From that point on, a programmer has a choice (per MCM, however, a bad choice if you want to minimize issues with future revisions of PowerBASIC, or per Patrice if you want to maximize portage options) of using DDT statements to act on the SDK-style windows, or to use API directly on those windows.

So the phrase "DDT vs direct use of API" would again seems to apply - once the window is created. However, the discussions in the forums seem to lump SDK-created windows and direct use of API into one big category.

While I understand MCM's/Patrice's caution, eliminating every DDT command pretty well wipes out a huge part of the PowerBASIC Inc. advertised new features over the last several revisions. MCM gave one example, but are there lots more, or just one more? I don't know the extent to which the problem has been seen, nor to which it will be seen in the future. It's hard to imagine that PowerBASIC Inc. would make many such application-busting decisions in future version of the compiler.

For now I'm prone to be lax on mix-and-match coding, but I can appreciate that as I get more comfortable with SDK/direct-API, I would gravitate towards minimizing DDT commands. But the old saying that "there's no virtue in suffering" has a lot going for it, meaning that the use of DDT commands to simply a coder's task is very attractive and that there need to be very clear benefits (not just philosophical differences or unrealized potential issues) to justify rejecting DDT.

Did I mention that I use a plain text editor to write my web site HTML? Once I knew all the HTML codes by heart, I found it was much faster to write HTML at the "API" level rather than use WYSIWYG editors. I can see that my HTML experience suggests where I'll be a year from now with PowerBASIC.

[Michael Mattias]

eliminating every DDT command pretty well wipes out a huge part of the PowerBASIC Inc. advertised new features over the last several revisions.

No it doesn't; DDT is a perfectly viable and useful tool. It does what it does, and it does it pretty well. It is, however, OPTIONAL.

You want to use DDT? You accept the convenience in exchange for the loss of a few abilities (very few, actually).

You want to use SDK-Style window creation? Fine, you accept the more the complex syntax in exchange for more options at the point of call.

And BTW, using the Microsoft Common Controls (treeview, listview, status bar, toolbar, etc) WITHOUT some of the simplified syntax made available in the recent PB compiler upgrades? Trust me, it ain't for the faint-of-heart nor the beginner.

Different Strokes for Different Folks.

MCM

[Edwin Knoppert]

>No it doesn't; DDT is a perfectly viable and useful tool. It does what it does, and it does it pretty well. It is, however, OPTIONAL.

I disagree but to some extend.
Also.., in the past having critic in public is not always appreciated unfortunately.
This makes it hard to put cons and pros in perspective.
"if you have a problem or suggestion, send us a mail", that is very good and polite but it also seems to withhold us from a good discussion where a company like PowerBASIC could learn from.

As for DDT.. let me put it this way:
Imo DDT as it is should never been implemented as it is right now.
So far i have never found the reason to choose the limited dialogbox system over an SDK version which imo could do *exactly* the same as DDT but more (think of MDI for example but the behaviour of DDT is also awkward at some points).
I mean *equally* easy and (nearly?) the same commands to accomplish the things DDT provides.

So.. i am not here to burn DDT but if it where SDK it could be made 100% compatible with ordinary SDK behaviour.
Questions like if Control Handle.. is compatible is really a non-discussion.
Don't keep us in the dark and approve these obvious calls for SDK usage.

I have users for PwrDev who need to rewrite their DDT project (made in PwrDev) to SDK due a lack of some kind of support in DDT.
All the dialog this and control that functions may not be safe and they simply like to keep using them.
I have nothing against these calls but they are limited to DDT, what's the point of that?

[Michael Mattias]

Pros and Cons, SDK v DDT are EASY...

DDT
====
Pros: Easy to learn, easy to use.
Cons: Some limitations.

SDK
==========
Pros: Every possible option available.
Cons: Not easy to learn or use.

No, I don't think that is OVER-simplification, not at all.

MCM

[Edwin Knoppert]

Then we disagree, i really meant it that using a custom windowclass could be as easy as DDT.
been there, d....

[Gösta H. Lovgren-2]

Pros and Cons, SDK v DDT are EASY...

DDT
====
Pros: Easy to learn, easy to use.
Cons: Some limitations.

SDK
==========
Pros: Every possible option available.
Cons: Not easy to learn or use.

No, I don't think that is OVER-simplification, not at all.

Have to agree with MCM here.

DDT is a BASIC language (as in Power Basic).

SDK is anything but BASIC.

========================
"The difference between
pornography and erotica
is lighting."
Gloria Leonard
========================

[Edwin Knoppert]

Then you missed the point.
The syntax could be the same as it is right now but the window class is a custom one and not a dialogbox.
In my tool there is no postquitmessage and defwindowproc required as well.
Using a few easy handlings the compiler can implement these for you under water.
All the windowproc things are the same or similar to what you do already.