Problems with "Child" DDT Dialogs - (Wizards subject continued) ???

[Fred Oxenby]

Eric, I have only the Help-file and the printed documentation
to base my decisions on when it comes to how the DDT-engine works.
Other people have participated in beta-testing etc and have a deeper
knowledge than I have.
When I encounter a problem I rely on what the help-file tells me.
If I decide that this problem is too severe, (a GPF or a hang),
in respect of the cause, I normally investigate it.
Ask official and unofficial questions.
If I don't get any answers on my official request, I take that ad notam,
creates a workaround and will draw whatever conclusion there is to be drawn...


------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se

[Chris Boss]

I think the solution lies in "how" you use the DDT commands.

When you use a Control ADD command that is class specific (ie. BUTTON) then of course DDT must do some processing of the styles, so using an "unexpected" style could cause a problem.

Technically, when I used the %BS_AUTORADIOBUTTON or %BS_PUSHLIKE styles together, my control was no longer a Button, but became a Radio Button. This could very easily confuse DDT since it may assume the control is a Button and not a Radio.

There are some styles that are NOT suppose to be used together using the API, so it is reasonable to expect DDT to choke when I use styles that could confuse it.

The solution is very simple though.

If you use a "predefined" DDT type control (BUTTON, LISTBOX, etc) use only the styles suggested in the Help file for that control.

If you need to use "other" styles, that are valid, but not listed in the PB docs, then simply use the custom version of CONTROL ADD which requires a Class name between quotes. DDT will simply pass this on to the necessary API calls with no "tweaking".

The number of "permutations" of different styles being mixed together can be quite large and DDT can't be expected to "double" check it all. DDT seems to "expect" the common combinations.

So don't blame DDT, since it is just as easy to "choke" the API functions themselves by using styles that shouldn't go together.

As Eric said, DDT is not just a simple wrapper. It does do some processing before passing data to the API. The important thing is to learn the "correct" way of using DDT.

I experienced problems because I "assumed" DDT worked exactly like the API calls I am used to. This was my "error" not DDT.

While I am more used to SDK style coding, I am "getting" use to DDT and I do find it a bit cleaner than API calls (doesn't use AsciiZ and pointers).

------------------


[This message has been edited by Chris Boss (edited February 29, 2000).]

[Eric Pearson]

Fred, believe me, I understand and appreciate what you're saying.

This is a Peer Support forum and sometimes all we can do is help each other interpret the docs and the observed behavior of the compilers, based on our own personal experience. If it seems like I "argue" a lot, I only do it when I believe that it makes a difference. After all, people write serious code based on what they read and learn here, and attention to detail can make all the difference.

-- Eric

Peer Support = Free, and almost always available from various people of various reliability.

Tech Support Participation in Peer Forums = Free and higly reliable, but not always available.

Tech Support via other channels = Highly reliable, always available, but not always free.




[This message has been edited by Eric Pearson (edited February 29, 2000).]