[AccessD] An interesting quandary

John Colby jcolby at colbyconsulting.com
Tue Oct 14 22:15:33 CDT 2003


As most list old-timers know, I use an Active/Trash system to flag records
that the user tries to delete (which have a child record) as Trash.

Basically I hold that cascade delete is a very powerful tool used mostly for
ripping the guts out of your database by users who shouldn't be doing so.
In order to prevent such shenanigans I rarely if ever turn on cascade
delete.  Since it isn't turned on, when a record delete is attempted (with
child recs), jet generates an error and my form class intercepts the error,
calling my active/trash class to handle the error.

If I don't turn cascade delete on, then I am responsible for making it
appear that the user can delete a record (with child records).  I use two
Boolean flags, Active / Trash to deal with the results.  A record is Active
by default, can be set inactive, or can be set trash either by dbl-clicking
on the trash check box or by the delete error.

I designed this system AGES ago and it has worked flawlessly ever since,
however I decided a few years ago I'd really rather have a single byte /
integer field with different numbers representing the record state.  0 =
Inactive, 1 = Trash, 2 = Active and 3 = Archive (Archive is not included in
my current system).

In order to add in the ability to use a combo I have about decided to add a
new Withevents class to deal with this combo rather than add in the code to
my existing Active/Trash checkbox class.  I decided to do this in order to
make the use of a combo BY ITSELF (bound to an integer field) clean.
However I MAY also want this combo to be able to handle a "retrofit" where
the two flags (active/trash) already exist and I currently use the checkbox
paradigm without the integer field.  In essence the combo would directly
manipulate the underlying checkboxes to "emulate" the use of a single
integer field but in actual fact use a pair of flags.  Unfortunately this
implementation doesn't handle continuous forms well since the combo is not
directly bound, and would display incorrectly in instances where the check
box values differ from rec to rec.

OK, now to the quandary.  I have a Withevents class which handles the two
check boxes, sinking their events and setting / resetting the two values
depending on what is happening.  Again, works fine, lasts a long time, with
proper maintenance (an old Navy saying).  I will have a new class handling
the combo.  I have a control scanner that finds all controls on a form and
loads the appropriate class for each control.  It already works for the
active / trash check boxes, loading that class.  I now have to add in a new
check in the scanner to find and load the class for this new active/trash
combo.

However if the combo exists I want to hide the active / trash checkboxes
(visible false) and then preferably unload their class.  The quandary is
that it is not possible to determine which class will load first, i.e. which
control (combo or check boxes) will the scanner encounter first in its scan
for controls in the form's control collection.  Thus the checkbox class
could load first then the combo class or vice versa.

Each has to check for the existence of the other class in the form class'
control class collection.  If the combo finds the checkbox class in the
collection, it needs to tell the checkbox class to hide it's controls and
then unload itself.  If the checkbox finds the combo class already loaded,
it needs to hide it's controls and then unload itself from the collection.

It seems like this should work, i.e. the only reason the class continues to
exist is that a pointer to the class exists in the form's control class
collection.  Any class should be able to unload itself by finding and
deleting it's pointer in that class collection (which it can get at by the
way since it has a pointer to the form's class).

I am assuming that if a class deletes the last remaining pointer to itself,
then when the code (in its own class) exits, the class would terminate.  I
also assume that the Terminate would run AFTER the currently running code
exists, not at the instruction following deletion of the last pointer?

Does this sound correct?  Anyone care to comment on possible problems,
implementation issues?

John W. Colby
www.colbyconsulting.com




More information about the AccessD mailing list