What is the SDK code equivalent to DDT code?

[Gary Beene]

Ok, I'm off to install the SDK from the PowerBASIC CD and will investigate some of the information I've seen discussed today. Are there any particular tips on starting? Will there be an introductory help file with examples? Will I be at MSDN a lot? I guess I'll see shortly. You know I'll post questions if I have them!

One obvious learning exercise is for me to take some of the common control DDT source code examples I've been writing and put them side-by-side with the equivalent SDK code. That should make the differences obvious, exposing how much PowerBASIC does behind the scenes.

.... DDT statements  |    ...SDK statements

Not that I'm too lazy, but has anyone already done such a comparison table? Of all 22 controls discussed in PowerBASIC Help? If not, then I'll do it the old fashioned way - myself!

[Patrice Terrier]

Gary,

If you want to learn about SDK coding in PB, then have a look @ José Roca's forum.

[José Roca]

CONTROL ADD xxxx ---> CreateWindowEx <classname>

[colin glenn]

Will I be at MSDN a lot?

You might be interested in installing the big dog and having a good chunk of the SDK on your hard drive, unless that's what's on the PB Disc, (ain't got mine yet, ...)

Windows® Server 2003 SP1 Platform SDK Full Download

The very relevant section is, according to the index on mine:
User Interface -> Window Controls -> Individual Control Information

The other section to read through is:
User Interface -> Windows User Interface
-> Resources
-> User Interface
-> Windowing

Don't let all the super geek scare you, if at first you don't understand, then perhaps it's time to learn from another section, or ask questions.

You will also be surprised how much search engines will mine good examples for you just using the function name or constant that you're interested in finding out more about.

[Michael Mattias]

There is no magic 'one for one' translation between DDT commands and SDK commands.

Think about it: were that true, why would Mr. Zale have invested all that time and money creating DDT?

One DDT command often equals MANY SDK commands, just as one 'regular' BASIC-language statement often translates into MANY "machine instructions."

"From one, many" is, like, the basic purpose of a high-level language compiler.

MCM

[Jules Marchildon]

For a possible general side by side comparison, you could download our old visual Quick Tab designer called QTAB ...get it from the download section of PB's website. It creates DDT or SDK. Warning, I have not updated it, so depending on your screen resolution and some of the popup dialogs maybe smaller, a few colors off as well.

[Cliff Nichols]

in some ways MCM is correct. (Much like why we write wrappers to make a concept easier for the end programmer that has not the time nor the knowledge to re-Recreate the wheel) sort of thing.....

Jose kind of eluded to what you will be up against. (AKA...within scope of what you are trying to do, the DDT may = API, or DDT may wrap API, or DDT may <> API

In the past, (pre-version9), I tried to work up an example like you are that you could API or DDT, or mix and match (within reason), and still make it readable to someone that "May miss something from the docs, but gets it from the code)" sort of thing, but my initial attempts were either "too ambitious" or did not learn enough at the time.

A simple Concept like here is a Dialog/Form and a Button/Control quickly became tricky unless you knew the differences in each, and allllllll the properties, events, callbacks, IdNumbers, etc....and could comment the differences.

Unfortunately, the background of the user can complicate even more, but I applaud you for wanting to make the "Bridge" that I never could

[José Roca]

You can't compare side-by-side code for a DDT dialog and code for a SDK window because they don't do the same. You will need to compare it with SDK code that uses the Windows Dialog Engine.

DIALOG NEW / DIALOG SHOW MODAL
- Compare it with DialogBox functions

DIALOG NEW / DIALOG SHOW MODELESS
- Compare it with the CreateDialog functions.

DIALOG END
- EndDialog

The Dialog callback
- Compare it with the DialogProc callback.

If we were going to use the Windows Dialog Engine using SDK code, then we could discuss if it is more convenient to use DDT for that purpose or not, but if we are going to use a SDK window, then a side-by-side comparison is not possible.

To me, the discussion should not be SDK vs. DDT, but SDK Windows vs. Windows Dialog Engine. I prefer to use SDK windows instead of dialogs simply because dialogs have more limitations.

[Fred Harris]

I agree completely with Jose on this. I use Sdk style for various reasons many others here have stated, but right up near the top of my list of reasons is that I never cared much for the Windows Dialog Engine. That's probably somewhat unique to me because I started Windows programming in an effort to adapt to Windows many of my low level form input tricks I did with DOS, and the Dialog Engine plumbing was too awkward to work around. So, as it stands now, I occasionally have to do extra work with such things as tab order and so forth that folks that use Dialogs don't have to do, but so be it.

[Patrice Terrier]

Yes, the CreateDialog API is a subset from The CreateWindowEx API, and for this reason it is more limited, especialy if you want to take full control of your window.

What i like with the CreateWindowEx, is that it is the mother of all other interface API, and it would let you create your own CLASS, or SUPERCLASS those already provided by the OS. My favorite one is the BUTTON class that could be customized (superclassed) to all extent.

Also using the CreateWindowEx API you can extend the cbWndExtra parameter to store all kind of useful informations, without having to resort on globals.

    wc.cbSize = SIZEOF(wc)
    IsInitialized = GetClassInfoEx(zsInstance(), zClass, wc)
    IF IsInitialized    = 0 THEN
       wc.cbSize        = SIZEOF(wc)
       wc.style         = %CS_HREDRAW OR %CS_VREDRAW OR %CS_DBLCLKS ' OR %CS_DROPSHADOW
       wc.lpfnWndProc   = CODEPTR(WndProc)
       wc.cbClsExtra    = 0
       wc.cbWndExtra    = %EXTEND_EXTRA * 4
       wc.hInstance     = zsInstance()
       wc.hIcon         = LoadIcon(wc.hInstance, "PROGRAM")
       wc.hCursor       = LoadCursor(%NULL, BYVAL %IDC_ARROW)
       wc.hbrBackground = %NULL
       wc.lpszMenuName  = %NULL
       wc.lpszClassName = VARPTR(zClass)
       wc.hIconSm       = wc.hIcon
       IF RegisterClassEx(wc) THEN IsInitialized = %TRUE
    END IF

But we (the programmers) have very different needs, and if all you want is to create "quickly" a new application then you don't need to master every pieces of the puzzle, and you can use a higher level of encapsulation, the ultimate level being L5G.

[Michael Mattias]

>DIALOG END
>- EndDialog


SDK: True for MODAL dialogs only! (DestroyWindow is used when dialog is CreateDialog/MODELESS)

[Gary Beene]

With deference to some of the old hats here, I think some of the answers here are off on a scientist's trek, whereas I wanted an engineering solution.

If I build an application that does X, using the DDT tools of PowerBASIC, then of course I can also build an application that does X using SDK techniques and compare the two approaches to see what the basic differences are in terms of development effort - the statements, API, lines of code, details not covered by PowerBASIC, etc.

Sure, there might be a half dozen ways to get it done using SDK, but the basis for comparison is using the tools that PowerBASIC Inc. highlighted as the reasons for buying PowerBASIC in the first place (and of course, small EXE and speed). I don't really care, at least as part of the comparison, whether I'm using a Dialog or a Window. I care that my users need an application with certain features. What goes on under the hood is, of course, of interest to me. But the goal is to create software more or less efficiently while getting the results that I think my users want. Whether I use a quill and ink, a pen, or a carver's knife isn't so much the issue as is the development effort required to create applications. Required effort to get specified results - that's really the comparison I think is important.

The fact that all of the old hands here seem to have migrated away from the DDT tools, with exceptions, is very interesting to those of us who just started using PowerBASIC.

Why did you do it, how is it different, and is it worth it for most of the application we may write?

One of my first posts here asked about Dialogs vs Windows. The response I got was that 99.5% (or so) of apps are totally satisfied with Dialogs. Yet in a lot of the threads, all of the experienced folks keep saying "Well, it's good, but I use SDK"! They don't say "I use SDK for 0.5% of my apps".

It's not lost on me that SDK allows me to include features in my apps that DDT can't - although if the 99.5% story is true, then it ought to be in a very minimum of cases - not the complete conversion that I see discussed in these threads

So, the bottom line is that we newer folks start with DDT. If the 99.5% answer is bogus, that's fine. All this talk from the more experienced PowerBASIC programmers makes it obvious that they don't just "dip" into SDK. They seems to go whole hog into it, once they pick up the techniques.

Understanding why makes a difference in what concepts we newer PowerBASIC folks decide to learn vs those we just acknowledge in passing as the tools of the masters - but not the tools of the minions.

[Michael Mattias]

> Sure, there might be a half dozen ways to get it done using SDK,

There are probably also a half-dozen ways to do it using DDT-style, coding, too.

I think it was Mr. Zale who posted not too long ago that DDT techiniques can handle 90 or 95 percent of your application requirements.

The unspoken part of that statement was, what you have to do for that other five or ten percent.

That's why I suggest everyone do at least one application using SDK-Style techniques. Only then will you have an idea of "What DDT Can Do For You" - and you won't be totally lost when your user asks for something which falls in that other five or ten percent.

MCM

[colin glenn]

I think it boils down to what you know you can do with either DDT or SDK design of a program. You may find that you can build your main core program completely with SDK yet provide user interaction dialogs with DDT just as effectively as if you wrote those with SDK. And there's probably at least one person who's coded things the other way as well, DDT for the main program and SDK for the dialogs, ...

[Mike Doty]

I scanned this thread pretty quickly, but many of the PetZold examples were translated and put into the files section.

[Fred Harris]

Sdk style is inevitably longer in lines of code than a DDT style app. Long ago though I realized that the number of lines of code it takes isn't the main criterion I use in deciding whether I like a particular programming paradigm or not. .NET can get a main window with a couple controls on it up and running in fewer lines of code than a comparable Sdk style app using the Windows Api directly. So can DDT. Also true for MFC (Microsoft Foundation Class Library for C++).

But Its not good enough for me to just get things to work. I want to know how they work. That is why I prefer the SDK style.

Also, I really feel that everybody's mind is 'wired' a bit differently. By that I mean if you take two people of comparable intelligence and background and set them to learning some task, the one may find it difficult and the other easy. Given another task and the roles might reverse. For me Sdk style was easier than DDT. I actually made a few feeble attempts to learn DDT and pretty much failed. So I think its pretty neat that within this one language there are basically two ways to do things.

A great many of the folks who do Sdk style programming learned it from Charles Petzold's books. PowerBASIC translations of Petzold's programs can be found both here and over in Jose's Forum. The ones here were done by Keith Waters from the Win 95 book, and Jose did the Win 98 book. Keith's work is what helped me, but that was long before Jose did the newer ones, which really havn't changed much. Also, over in Jose's Forum (as Patrice said) are a lot of examples. I also seem to remember an Sdk style "Hello, World" program in \Samples that presented a vari-colored blue screen. So there's lots of code out there to check it out.

[Dave Biggs]

That's why I suggest everyone do at least one application using SDK-Style techniques. Only then will you have an idea of "What DDT Can Do For You" - and you won't be totally lost when your user asks for something which falls in that other five or ten percent.

Any that are interested in following Michael's advice would do well to start with Fred Harris' Beginning Win32 SDK Style Programming Example Series:

http://www.powerbasic.com/support/pbforums/showthread.php?t=25174

[Patrice Terrier]

For me Sdk style was easier than DDT. I actually made a few feeble attempts to learn DDT and pretty much failed. So I think its pretty neat that within this one language there are basically two ways to do things.

Ed,

i also made a few attempts and come to the same conclusion, and this is because my background was from QB/PDS thus i still like to use the CALL Something() syntax, using parameters surrounded with parenthesis, that i found easier to read.

I also still use the same names for functions and procedures than those i have used for years in my Obj/LIB, before moving to Windows and using my own API encapsulation.

For example, i am still using for I/O exactly the same syntax that i have learned from one of my Master: Ethan Winer.

Conclusion: because we all have a different background, we must pickup the solution that best fit with our formation.

And fortunatly, PowerBASIC, gives us the choice.

[Michael Mattias]

And fortunatly, PowerBASIC, gives us the choice.

But not without nudging us in a certain direction: PB/Win 9.0 ships MINUS the Dialog Editor provided with prior versions of the GUI compilers.

[Paul Dixon]

Michael,

PB/Win 9.0 ships MINUS the Dialog Editor provided with prior versions of the GUI compilers.

Are you sure? It's in the Bin directory my copy of PBWin9.01 but not PBWin9.0. Maybe it was an oversight in 9.0.

Paul