DDT vs SDK

[Gary Beene]

I think it was Michael who made a comment about not being a "DDT guy". But whoever said it, the comment raised a question that us newer folks might ask.

Nowhere in Help does PowerBASIC Inc. suggest that I not use all of the DDT stuff. Just the opposite is true. They raise it up on a pedestal.

I can see that PowerBASIC allows a programmer to bypass all of the DDT stuff, but other than personal preference or habit, what would be the pros and cons of doing so?

And is it typical of more experienced PowerBASIC programmers to drift away from the DDT tools?

I'm sure the answer depends on who responds, but I'd like to hear the viewpoints.

Convenience seems to be the obvious pro of DDT. And limitations on fine tuning/tweaking seems to be the downside. I just don't yet know whether it's a distinction without a difference.

[Gösta H. Lovgren-2]

Real Men use SDK.

=======================================
"Logic is in the eye of the logician."
Gloria Steinem
=======================================

[Carlo Pagani]

Gary, if you use PB Forms then it will generate DDT code for you. DDT certainly simplifies getting going and for the many business applications I develop, I have used SDK only when needing a property / wizard type dialog. The rest is 100% DDT.

--Carlo

[Chris Holbrook]

Gary,

As you will no doubt have discovered by scanning these forums, there have been some very strong pro- and anti- DDT/SDK opinions out there. Mostly they boil down to "be like ME". I would not like to take sides on this - "horses for courses" is how it looks to me. So, be like ME!

I can see that PowerBASIC allows a programmer to bypass all of the DDT stuff, but other than personal preference or habit, what would be the pros and cons of doing so?

SDK just refers to using the Windows API directly, in all its ghastly detail.

DDT is a collection of BASIC statements which package Windows API functionality, presenting a higher-level interface between the developer and Windows. It does a limited but still wide range of things. The use of higher-level statements allows applications to be developed fast. Having a poorer "instruction set" there is less to learn, less to remember, but some things you can't do. Oh, and it is non-portable, unlike SDK. If you use it, you are in PB World. And in my experience, it is very reliable.

And is it typical of more experienced PowerBASIC programmers to drift away from the DDT tools?

Yes. No surprises there, then!

I just don't yet know whether it's a distinction without a difference.

If you start with DDT and add in more sophisticated techniques, you will discover that DDT has its limits, for example, DDT methods do not always span modules successfully, and some DDT statements don't work properly if used in subclassed Wndprocs.

[Paul Squires]

If you start with DDT and add in more sophisticated techniques, you will discover that DDT has its limits...

Chris, I think you are spot on with your comment. I imagine that most people start off with DDT unless they've come from a language like C/C++. DDT does a lot and can certainly be used for a fair number of applications.

However, I expect that there will eventually come a time in every PB'ers programming life that they will run into a wall with DDT and have to turn to SDK/WinAPI. That's when the light will finally come on about just how much more there is to explore and learn. The SDK approach is not hard. People just like to talk about it as being hard because they simply do not take the time (or have the patience) to learn bits and pieces of it at a time.

After having used both DDT and SDK, there is no way that I would leave SDK. I would be crazy to.

[Patrice Terrier]

DDT is using a proprietary syntax, thus it will never be able to encapsulate the whole API, and as Paul said, sooner or later, you will hit the wall and then no other issue than switching back to the core API.

For programmers, like myself, always switching between different languages, the only common denominator to all of them is the low level SDK FLAT API.

When you studdy plain C and plain PowerBASIC SDK, then you will see almost no difference, making easy to port your code from one language to the other.

When the first PowerBASIC for Windows version was available, people had no other choice than using SDK, and since that time i have never derogated from it, and it helped me to learn new languages including DotNET, because i had a good knowledge of what was going on under the hood.

And the reason why PowerBASIC is still my compiler of choice, is because it gives me easy access to the core API and produces rock solid, fast, lean, small EXE and DLL.

...

[Michael Mattias]

>Real Men use SDK.

Amen, My Brother!

[Michael Mattias]

Actually I have nothing against 'DDT'.

DDT is a tool, to be used... or not.

Using DDT you gain ease of programming at the cost of loss of some low-level control and some restrictions; i.e., it's like using "Brand-M" Visual Basic.

There is also a "time-bias" factor. Some of us (e.g. moi) learned to create Windows applications with the PB compilers before there was such as thing as "DDT." So, we are more comfortable with SDK-style coding than those who "jump in cold."

(And DDT is hard, because DDT uses 1-based items for multiple-item controls such as the listbox, combobox and listview... whereas Windows uses zero-based item numbers. When I create demos using DDT, this zero-based v one-based thing seems to "gotcha" me more than any other difference).

(My NFS for "#OPTION BASE DDT 0|1" is still languishing somewhere).

[Fred Buffington]

Gary, it amounts to this. You can do a LOT with DDT but not everything.
the DDT 'wrapper' prevents you from capturing some windows messages i think. Also although it's possible i guess, it seems it would be difficult to make
a non-rectangular 'window' with ddt. That said, version by version ddt seems to get more statements adding to the simplicity of making dialogs.

The learning curve for SDK is a bit steeper than DDT but well worth it in the long run. The main reason for learning SDK is a better understanding of how
windows handles things and more control over your application. Still, most applications can be done quite adequately with ddt and it's a good jumpstart
for those coming from pbdos/qb, etc. to get into windows dialogs quickly.

[Dave Biggs]

It depends of course what kind of applications you want to build but for my purposes, small utility type applications are reasonably quickly put together using DDT. (Ok my main project is around 11.5k lines but that beast has been 'evolving' for a few years now!)

So far, when I've been limited by DDT's built-in features, I've found that I've been able to suppliment them by calling upon API functions from within the DDT code so I figure I have the best of both worlds!

[Bob Zale]

It all boils down to this: DDT provides a set of functions which encapsulate the WinAPI, making it much quicker and easier to create an application with a graphical user interface. It probably doesn't make the app better, it makes it quicker and easier to create.

DDT will never provide 100% of the functionality of the API. That would be a huge waste of resources. But it probably offers you everything you need for 90-95% of the PowerBASIC programs in existence. By using the API with DDT, you add to that percentage even further. So, if you want to create code with less effort, it's usually a good choice.

For the rest of the programs, it may well be that you must use the WinAPI directly. If you prefer direct API coding, that's ok, too. For those reasons, PowerBASIC supports both methods, and will continue to do so. Personally, I wouldn't dream of using only API code, unless it was necessary. Why expend extra effort just to deal with more cryptic names and functionality?

I always recommend the use of DDT to newcomers. It's quicker, easier, and you can always add API code at your own pace. If you skip DDT just because someone claims it's not "macho" enough, you may find you cheated yourself out of a tool which could really make your life easier. You owe it to yourself to try it and compare personally.

As to portability? Hogwash. {smile} Nothing is truly portable these days. If you find the need to translate API code, you can just as easily translate code written at a slightly higher level. Would you stop using dynamic strings just because some code doesn't support them? I think not. Arrays of bytes just aren't the same, I think.

My real suggestion? Try it and make a personal, informed decision.

Best regards,

Bob Zale
PowerBASIC Inc.

[Chris Boss]

DDT is based on the Windows Dialog API's.

The Windows API has a set of API's which are specifically designed for creating Dialogs. They can be created using templates in resources, from memory, etc.

A Dialog is a mechanism to make displaying simple user input windows more easily. Actually the Dialog engine makes a number of things easier for you.

Some of these Dialog API's can also be used with custom window classes (aka. SDK style code) to make them easier to work with.

Every window must be a defined class where it has its functionality defined in a window procedure for the class. Dialogs are a predefined class, while SDK created windows are user defined classes.

Of course you can do more with a user defined class, since you are creating its functionality, but why "reinvent the wheel".

DDT does a good job of simplifying the Dialog API's into something easier to work with. I would estimate that about 90% of what most Windows need to do can be done with DDT (Dialogs). For the average PB programmer, DDT not only suffices, but it does everything they need as far as basic GUI stuff.

Now of course one may want to push the limits of their apps so they can do more advanced things. At that point, working with the Windows API directly may be necessary. Now you would be surprised how much you can do with Dialogs (DDT) by integrating the API with it using some tricks like subclassing the dialog class. Also PB 9.0 added some significant improvements to DDT which overcome some of its weaknesses (ie. processing WM_NOTIFY messages in callbacks).

One has to weigh their needs and balance them between "ease of use" and "full control and power".

DDT can be learned much quicker than pure API coding (SDK) and its current feature set is quite rich.

Despite what some may warn, I do not think that starting with DDT will somehow hurt you when you may later decide to change to SDK style coding. They key is to learn "why" DDT works the way it does and to progressively learn the API one step at a time.

Also despite what some may claim, the API is not the easiest thing to work with and it is quite extensive and complex.

I also think that the idea that "DDT is proprietary" and because of this is somehow dangerous to depend upon (aka. saying one is much safer depending directly on the API) is only an opinion and personally I don't think it holds any weight. Every compiler has some degree of proprietary stuff built in and especially are compilers that use OOP guilty of that (ie. Visual Basic) to a much larger degree.

They key is to find out what works for you, what makes you productive.

You will also get better support for DDT coding than pure API coding from PowerBasic and these forums, since DDT is most likely the most popular coding style and of course the one built into the compiler itself.

It is good though to learn about the other styles of coding, since each has its advantages.

[Patrice Terrier]

As said already PowerBASIC is my compiler of choice, and we don't have all the same need, nor the same opinion as you can see there.

Thus no need to start a flame, we all love PB for one reason or another

[Jeff Radue]

I started using DDT because it was easier to program some of the API controls. I still use DDT code for some of my tab dialogs. I have since moved away from using DDT for dialog creations because I learned how to use resource dialogs effectively. This is very efficient, especially with dialogs with alot of controls. I also do not use DDT for graphic or printer operations. This is my personal preference, partly because I took the time to learn the SDK approach and have written good functional SDK code to perform those tasks.

[Ian Cairns]

Don't care - Love it!

"Real Men" know how and when to control their tongues.
Although I don't use DDT (other than for demos), I love the way people make great looking applications/demos with it.
What I really like though, is Bob's inclusive approach to programming - something for beginners, hackers, professionals, 'assembly language gurus' and even those 'object-oriented' loving guys. I love the string handling in the BASIC language. I love the lack of the 'foundation classes', because its all there! There are a couple of things you can't do (yet) like drivers, but that still leaves a lot more than any one of us will ever get to!

Fair Winds and Following Seas,
Ian.

[John Petty]

Actually I thought real men used assembler I think it depends on the type of programs you write. I use PB Forms with DDT and the only time I have had to revert to the API is for Rich Text work. Some of my displays have animated graphics and real time graphs, all done in DDT and have over many hundreds controls using control arrays. My only complaint would be the delay in matching PB Forms to PB WIN.
My programs are normally heavily biased to computation and large data bases so I use the API and still even assembler for speed when needed but not for the GUI.

[Chris Holbrook]

Actually I thought real men used assembler

No, machine code. Assembler is for poseurs, SDK for wimps and DDT for Hairdressers. Actually Real Men can code in any of these mediums, providing that documentation is not attempted.

[Steve Rossell]

bits

[Gary Beene]

Now, see this is exactly what I asked for - a variety of opinions.

bits ... machine code, assembler, SDK, DDT, all of the above.

That would be a variety of answers.

Anyways, thanks for all of the responses. I (and all the other new-to-PB folks) appreciate it!

Responses like these help take the "new-to" out of the equation.

[Paul Dixon]

Real men make their own dedicated processors to do the job by carving the transistors out of a block of silicon with a needle.

Sensible men use the best tool for the job.