| Subject | RE: [IBO] Master/Detail - AfterOpen |
|---|---|
| Author | Helen Borrie |
| Post date | 2003-01-12T13:19:48Z |
At 11:23 PM 12/01/2003 +1100, you wrote:
If your code calls Open, Close or Refresh on the dataset, you have access
to the event handlers for these methods. When a dataset's buffers are
being controlled by a masterlinking, you don't have access to those
handlers because they are internal calls - you are not calling Open and
Close yourself. The reasoning I understand for this is that the
masterlinking requires the events to proceed in a particular sequence,
without interference from handlers it doesn't control.
Hence, knowing that the master's scroll activity is going to close the
dataset (if it is open) and finally reopen it to bring new contents into
the buffer, you simply call your handler code from the master's scroll events.
Although I don't think I've ever needed to do it, other than where I'm
switching mastersources, I don't know of any reason why you couldn't close
and reopen a detail set yourself if you had some need to do it. Have you
tried to do it?
A propos your earlier comment, that the master's scroll events wouldn't be
available when you open master for the first time: I'm fairly sure that
the first scroll event happens when the buffer pointer moves from BOF to
row 0. I haven't tested it in battle, though. But, if it turned out that
it didn't, it still wouldn't be a problem for me. My handler code routines
live outside the event blocks. I just call them from whatever event(s)
need to call it.
Why not set up a little test app for yourself, if it's an issue for you, to
find out precisely what events occur when a master/detail structure opens
for the first time? If you do, don't forget to report back, because an FAQ
on the subject might turn out to be useful.
cheers,
Helen
>Helen,This is the way it has appeared to me:
>"The Refresh of the detail set buffer during the master's scroll event
>involves a protected Close followed by a protected Open."
>
>thinking about this... and to avoid confusion...
>even if IBO uses a protected method for its afteropen and beforeclose
>magic... after IBO has done this magic.... surely the user is entitled to
>plug something into these events too?
If your code calls Open, Close or Refresh on the dataset, you have access
to the event handlers for these methods. When a dataset's buffers are
being controlled by a masterlinking, you don't have access to those
handlers because they are internal calls - you are not calling Open and
Close yourself. The reasoning I understand for this is that the
masterlinking requires the events to proceed in a particular sequence,
without interference from handlers it doesn't control.
Hence, knowing that the master's scroll activity is going to close the
dataset (if it is open) and finally reopen it to bring new contents into
the buffer, you simply call your handler code from the master's scroll events.
Although I don't think I've ever needed to do it, other than where I'm
switching mastersources, I don't know of any reason why you couldn't close
and reopen a detail set yourself if you had some need to do it. Have you
tried to do it?
A propos your earlier comment, that the master's scroll events wouldn't be
available when you open master for the first time: I'm fairly sure that
the first scroll event happens when the buffer pointer moves from BOF to
row 0. I haven't tested it in battle, though. But, if it turned out that
it didn't, it still wouldn't be a problem for me. My handler code routines
live outside the event blocks. I just call them from whatever event(s)
need to call it.
Why not set up a little test app for yourself, if it's an issue for you, to
find out precisely what events occur when a master/detail structure opens
for the first time? If you do, don't forget to report back, because an FAQ
on the subject might turn out to be useful.
cheers,
Helen