At 04:01 AM 15/08/2004 +0000, you wrote:

>Dear Helen,
>
>I did not change anything in either of the examples you sent me.
>
>My OS is XP Home.
>
>The abbreviated Nav bar with the '+' is visible.
>
>The file with the screen shots you downloaded was not present in the
>files section.

Yup, I'm on a slow dialup connection here so I concocted the URL by
cut-and-paste. You can always go to the Files area at
http://www.yahoogroups.com/groups/ibobject and get the files for yourself...

>In the meantime I've completely uninstalled IBObjects and deleted
>all files from my computer.

A pity, probably unnecessary, since you don't seem to have any of the
reported problems with the Win32 controls.

>I've downloaded IBObjects with the DCU files for D7 and reinstalled
>IBOjects again.
>
>As yet I've not rerun any of the projects or demos
>
>I'll try looking for your screen shots again later.
>
>There must be something wrong with my installation of IBO; since no-
>one else has reported a similar problem.

It's not necessarily the case. Most people wouldn't try to use TIBOTables
for master-detail, so you might be just the first to bump into a problem
that's been around for a while, maybe even forever....

For interest's sake, I stripped down the two demos to eliminate the
possibility of the timing bug that might have caused those FK violations
you reported. In the process I put monitors on both versions. In the
"plain Jane" version of the TIBOTable one, master-detail does *not* behave
like it does with TIBOQuery. This would figure, since TIBOQuery uses more
of the native TIB_ wrapper functionality than does TIBOTable.

From watching the monitors, it's clear that, when the TIBOTable master is
first inserted, it does not do the "PostRetaining" thing at all. The
TIBOQuery does. The unmodified behaviour of the TIBOTable is to put the
detail TIBOTable into Insert mode and write the Masterlinks key to the
detail. Then, when the other (required) field is filled and you click the
Master's Post button, the master table object silently performs a
CancelEdit on the detail and is then itself posted to the database for the
*first* time. Once the master row exists, it becomes possible to add
detail rows by putting the master into edit.

This is wrong, I think. I think it ought to behave like the IBOQuery.

I have one little doubt about the IBOQuery m/d processing, that showed up
during the monitoring. All goes well: you insert a master and a Post is
prepared. Once there is a master key there, the dataset will do the
PostRetaining immediately before putting the detail query into Insert. You
can insert as many details as you want and, as expected, the details are
posted "as you go". All except for the last one (or, if there is only one,
no details are posted). You click the Post button for the Master, which
posts the current image of the Master but not the last (or only)
detail. After you move *off* the new master (i.e., scroll to another
master record) then the last detail is posted.

I don't think this is normally a problem, since the unposted detail row
will get posted eventually. I think there's only a risk that it will get
lost if the user doesn't shut down the application cleanly, for some reason.

Hopefully Jason will look at this in a couple of days. I'll give him the
two stripped-down demos as a testcase and we'll see where it goes.

Helen