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




___________________________________________________________________________
IB Objects - direct, complete, custom connectivity to Firebird or InterBase
without the need for BDE, ODBC or any other layer.
___________________________________________________________________________
http://www.ibobjects.com - your IBO community resource for Tech Info papers,
keyword-searchable FAQ, community code contributions and more !

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/