| Subject | Re: Cancel - Scroll Events called before AfterCancel |
|---|---|
| Author | Eric Handbury |
| Post date | 2002-10-10T05:14:34Z |
--- In IBObjects@y..., Geoff Worboys <geoff@t...> wrote:
for 2 reasons:
1) The Detail Cancel is done that way, so the Master should be
consistent.
2) I feel that all changes/resets/etc. related to the cancel should
be done before the dataset is scrolled.
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.
own code (which it usually is), or that I figure-out some work-around.
Eric.
>I mean that it's correct but in the wrong spot.
> AfterScroll is correct.
> Whether the event should occur before or after the state changeI think that its cleaner to have it called after the AfterCancel
> away from dssInsert is open to debate. It could be argued that
for 2 reasons:
1) The Detail Cancel is done that way, so the Master should be
consistent.
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. PerhapsI would love to tell you, but I'm confused myself <g>.
> 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 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 issueWell, I want to exhaust the possibilities that its somewhere in my
> before posting. It makes it so much easier to understand what you
> are seeing and to try and help
own code (which it usually is), or that I figure-out some work-around.
Eric.