If the detail dataset is not performing an AfterScroll event when new detail
records are brought in as a result of a master record being changed I will
consider this a bug and see what I can do about it.

Will you test this and provide the feedback on this for me?

Thanks,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

-- We may not have it all together --
-- But together we have it all --

----- Original Message -----
From: "Alan McDonald" <alan@...>
To: <IBObjects@yahoogroups.com>
Sent: Saturday, January 11, 2003 5:47 PM
Subject: RE: [IBO] Master/Detail - AfterOpen


> No - I think you get my point exactly. I now know that there IS an open
and
> close event - knowing that they are protected makes sense to my not
getting
> access to them too. And your rationale is not off-beam either. One point
> however, is that the scrollevent does not fire on first opening, so you
need
> to call the same code from the master scroll AND from the open event of
> either the detail or the master (I'll test which one works - not sure).
> Normally one place was enough (from the open event) since this fired
> everytime. It seems slightly more cumbersome to maintain an extra link to
> the call(s) than I was previously used to but I can live with it in the
> interest of overall "hyper-performance" :-)
> 1. Do I understand?
> 2. Is it not acceptable - does it not make sense, to call the derived
> AfterOpen, BeforeClose events so that users can add additional code here?
>
> Alan
>
> -----Original Message-----
> From: Helen Borrie [mailto:helebor@...]
> Sent: Sunday, 12 January 2003 11:00 AM
> To: IBObjects@yahoogroups.com
> Subject: RE: [IBO] Master/Detail - AfterOpen
>
>
> At 09:16 AM 12/01/2003 +1100, you wrote:
>
> >There is no doubt that things are fast under this model and I don't often
> do
> >things afteropen or before close but they should be called if that is
> indeed
> >what is happening.
>
> Alan,
> Forgive me if I'm missing your point...but, the Before and After Scroll
> events of the controlling dataset are surely the place where you need to
> perform actions that are contingent on the detail set in the m/d
> relationship context.
>
> The Refresh of the detail set buffer during the master's scroll event
> involves a protected Close followed by a protected Open. Each detail set
> exists exclusively in the context of the current master row, so it runs
> against the integrity of the master/detail linking to treat the detail set
> as if it were independent of the master row and expose its Open and Close
> events during master scrolling.
>
> When I want things to happen to the detail set before it opens or closes -
> such as some kind of validation or transformation - I write datamodule
> procedures for them, which I call from the master's scroll events. These
> procs typically accept the detail's linking key and, often, some property
> of the detail set, as arguments - pretty much the same way as Jason does
it
> in the components' methods.
>
> But, as I commented earlier, I could be missing your point entirely...
>
> regards,
> Helen