>> 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
> consistent.
> 2) I feel that all changes/resets/etc. related to the cancel
> should be done before the dataset is scrolled.

But that is not entirely logical/consistent (or at least from my
perspective). That is...

AfterCancel should occur after when a cancel is finished. A cancel
is not finished until the changes have been removed. On an insert
the changes are only removed when the "new" record is gone from the
buffer - and when a record is gone from the buffer the dataset is
forced to scroll to the next valid record, and this means the scroll
occurs before the cancel process is finished.

> 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.

I do similar processsing one of my applications, but I do it with
tab pages and not frames. (And a few things that are a bit like
frames - but not quite, my own creations once again.)

I have a specialised panel component that has a "DynamicResources"
property. When turned on windows handles are removed when the
panel is not visible, and recreated when the panel is show.

I then created my own versions of the tabsheet/pages components
with a datasource property, and based on my custom panel. When
the tabsheet becomes visible it ensures all handles are created
and makes sure the datasource is activated (appropriately to the
state of any master datasource). When the tabsheet becomes
invisible it releases all the window handles.

The result is that the memory overheads of the tabsheet are
reasonably small and it consumes no windows resources when not
visible.

As you can imagine this is all fairly complex, not something
I can post a simple example of to this list.

> 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.

I base most of my automated open/close stuff on the user
interface states. That is; If the tab page showing that
information is not visible then that dataset is not opened.

I also have special derivations of TIB_Query and TIB_Cursor
that cascade various details to their child and lookup
datasets - which will follow that change depending on various
rules and properties (again linked to the user interface).

It took a long time to set up, but it does mean that complex
forms open much more quickly and perform much better in day
to day use.


--
Geoff Worboys
Telesis Computing