Subject Re: Cancel - Scroll Events called before AfterCancel
Author Eric Handbury
--- In IBObjects@y..., Geoff Worboys <geoff@t...> wrote:
> AfterScroll is correct.

I mean that it's correct but in the wrong spot.

> Whether the event should occur before or after the state change
> away from dssInsert is open to debate. It could be argued that

I think that its cleaner to have it called after the AfterCancel
for 2 reasons:
1) The Detail Cancel is done that way, so the Master should be
2) I feel that all changes/resets/etc. related to the cancel should
be done before the dataset is scrolled.

> It may help if you tell us what you are trying to achieve. Perhaps
> we can offer alternatives (for example, I tie various state checking
> to the transaction rather than a master dataset - but it will depend
> on what you are wanting to achieve).

I would love to tell you, but I'm confused myself <g>.
I am trying to create Frames at run-time since my main Customer
form is extremely bulky. So I am ripping-out statically allocated
tabsheets with dynamically allocated Frames to lower the User/GDI
system resources and RAM the form uses. Many of the TabSheets would
be displayed very infrequently so why have them around hogging RAM
when I just dynamically allocate them when needed.
In addition, I am trying to be intelligent about when I open/close
datasets. So I am using Scroll events to determine when the user
changes Customers/Orders/etc. and then closing/opening only the
datasets required to display data for that Customer/Order/etc. For
example, different Orders require different detail queries and
different Frames to be displayed, so I only open the queries
necessary for that Order and then keep all the Orders queries open
until the user goes to another Customer, whereby I close all previous
Order queries (via the Customer.BeforeScroll). The
allocation/deallocation of Frames is also governed by the Scroll
events, so it is important to me that the events get fired in the
correct sequence.
I would love to hear how other developers handle opening/closing
queries on complicated forms.

> PS. Its good to see someone doing a detailed analysis of an issue
> before posting. It makes it so much easier to understand what you
> are seeing and to try and help

Well, I want to exhaust the possibilities that its somewhere in my
own code (which it usually is), or that I figure-out some work-around.