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