[AccessD] An interesting quandary

I could do that, in fact it seems that may be preferable since it already
knows how to toggle the check boxes.

John W. Colby
www.colbyconsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Michael R
Mattys
Sent: Wednesday, October 15, 2003 12:39 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] An interesting quandary


Hi John,

Instead of having the checkbox class unload, can you
use it's checked status through the combobox class?
It might be as if the combo were bound to the checkboxes
and show properly in the continuous form.

Then you'd only need to hide the checkboxes
and handle the termination of both the checkbox
and combobox classes on form close.

Michael R. Mattys
www.mattysconsulting.com



----- Original Message -----
From: "John Colby" <jcolby at colbyconsulting.com>
To: "AccessD" <AccessD at databaseadvisors.com>
Sent: Tuesday, October 14, 2003 11:15 PM
Subject: [AccessD] An interesting quandary


> 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
>
>
> _______________________________________________
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com

_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com