DDT vs SDK

[Patrice Terrier]

Real Men,
are still pushing holes on cards, and using Slicks or Retail Impact and a 64K IBM 360.

[John Petty]

Sensible men use the best tool for the job.

Can't agree more, still even use VB sometimes as I can do a quicky interpreted program with good built in date functions and then discard it, if the results are useable in something serious then I use PB and the API

[John Petty]

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.

Wow Chris that brings back memories, been a long time since I had to load start up sequences in binary using front panel switches to get the next stage of an OS load by paper tape.
I don't understand your comments about documentation as PB allows the same level as any other code. Hutch hasn't posted for quite a while but all his example were well documented.
PS some years back posted some examples of self modifying code which required the abilty to read and modify machine code, not really that hard.

[Gary Beene]

Engineers (that would be my career) are practical folks. They use whatever gets the job done.

What would MacGyver use?

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

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

[Steve Rossell]

bits

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

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

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

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

[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

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

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

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

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

[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).

[Michael Mattias]

>Real Men use SDK.

Amen, My Brother!

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

...

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