[AccessD] Building a control class

OK, thanks for clearing up my confusion, John.

Charlotte 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John W Colby
Sent: Thursday, March 12, 2009 4:55 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Building a control class

Charlotte,

I was simply saying that there are cases where for example a supervisor
loads a table, and each record in the table is a class.  As an example
my security system has a user table, a group table and a UserGroup
table.  There is a class for each of those three plus a supervisor base
class that loads all of the records in all of these three tables.  None
of the classes function without all of the others.

That does not mean that the child classes are aware of the parents (they
aren't), but they "depend on each other" in that none of them have any
value without all of the others.

John W. Colby
www.ColbyConsulting.com



Charlotte Foust wrote:
>> IMO classes really need to *try* to be independent of each other.  
>> Sometimes it is not possible, sometimes specific sets of classes form

>> a
>>     
> system and need each other to perform the whole task.   
>
> I agree with the first statement, John.  But I can't think of a reason

> it wouldn't be possible.  When two independent objects need to 
> coordinate, they do it through another class.
>
> Charlotte Foust
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John W 
> Colby
> Sent: Thursday, March 12, 2009 2:39 PM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Building a control class
>
> AD,
>
>  >In your view, what could be the best strategy for projecting the 
> events pertaining to form object variable in form class, into the 
> control class ?
>
> In general a control class should not be aware of the form and 
> particularly its events.  If the form needs to have a control do 
> something in response to one of the form's events, you should expose a

> method in the control class to call from the form's event.  Let's take

> an example:
>
> I use a combo control to cause the form to select a record.  The form 
> and the combo should "stay in sync" or it is visually confusing.  IOW,

> if the form moves to a specific record, the record selector combo 
> should "move to" and display that same record.  Obviously if the combo

> selects a record, the form should move to that record.  The form and 
> combo "stay in sync".
>
> I created a "mSyncToForm(lngPKID)" method in the combo class.  In the 
> form's Current event the clsCboRecSel.mSyncToForm is called passing in

> the form's PKID.  The combo class then causes the combo control to 
> display the record with that value in column 0.  Thus the combo
"syncs"
> to the form.
>
> OTOH, if the user selects a record that they want to move to, the form

> should move to that record.  clsCboRecSel defines an Event 
> evAfterUpdate(lngPKID as long).  The clsCboRecSel raises the 
> 'evAfterUpdate event in the combo's AfterUpdate event stub in the
class.
> clsCboRecSel is declared Withevents back in the form.  An event stub 
> is created in clsFrm sinking evAfterUpdate.  When evAfterUpdate fires,

> control passes back to the form's evAfterUpdate event stub and the 
> form has to grab a copy of the RecordsetClone, move to that record, 
> grab the bookmark, then set the form's bookmark to that bookmark, 
> causing the form to move to the right place.
>
> Notice that the clsCboRecSel doesn't need to know anything about the 
> form in either case.  It can sync to the form simply by exposing a 
> method for the form to call, and the form can sync to the record 
> selector simply by sinking an event raised by the record selector
class.
>
> So the answer is to build functionality into the control class, and 
> expose that functionality via methods of the control class.  Raise 
> events in the control class as required to notify the form that the 
> control class did something that the form class might want to know 
> about.
>
> Often times the control class behaviors simply don't matter to the
form.
> For example my combo control wrapper class can be programmed to open a

> specific list form in the dbl-click event so that the list behind the 
> form can be programmed.  The form that carries the combo control 
> doesn't care about that, in fact that is a behavior that might be 
> useful in any combo in any form.  It is the combo control classes' 
> business, not the form class' business.
>
> IMO classes really need to *try* to be independent of each other.  
> Sometimes it is not possible, sometimes specific sets of classes form 
> a system and need each other to perform the whole task.  On the other 
> hand even when they might need to know about each other, you should 
> try to use an interface - an exposed method or raising an event - to 
> allow the partner object to get something done.  Programming an 
> interface helps to disentangle the objects themselves.
>
>  >If a WithEvents variable of form type is declared in control class 
> and is set equal to the form variable belonging to form class, it 
> hampers proper closing.
>
> Yes, it definitely can.  a circular reference is formed where the form

> refers to the form class which refers to the control class and the 
> control class refers to the form.  The answer is being rigorous in 
> your cleanup.  Sometimes just setting the pointer to the control class

> to nothing back in the form class is enough to cause the control class

> to close properly.  The class terminate MUST set pointers to all 
> objects to nothing.  If the terminate event fires then the form 
> pointer is cleaned up as is the pointer to the wrapped control(s).  If

> this cleanup is not performed then things start to break.  
> Occasionally I have had to expose a mTerm() method that I explicitly 
> called back in the parent class before setting the pointer to the 
> child class to nothing.  That mTerm class performs all of the cleanup.

> The Class_Terminate() event then calls mTerm in cases where the 
> pointer in the parent is just set to nothing.
>
> Cleanup is CRITICAL.  If you do cleanup correctly, then it is quite 
> possible to grab pointers to the form, and even sink form events.
> Sinking form events can be risky though in the earlier versions of 
> Access, and can cause page faults in weird situations.
>
>  >On the other hand, if a custom event is raised in form object's 
> event (say current event) in form class, thereby enabling setting up 
> of WithEvents object of form class type (set equal to the form class) 
> in the control class, the said event does come up in the intellisense 
> but does not show any activity.
>
> The event should fire in the control class, as long as the event 
> property is set to [Event Property].  I have done so before and it 
> does work.  It is not clear whether you intend for the clsFrm to raise

> an event and be sunk in the control class, or for the form itself to 
> have an event sunk in the control class.  Either one *should* work.  I

> have never tried to sink an event raised by my clsFrm inside of a 
> control class, nor have I even declared clsFrm Withevents in a control
class.
>
>
> I have to say I am heartened to have you asking so many questions 
> about classes and events.  From your general Access knowledge level I 
> long ago assumed that you were probably way above me in this stuff.  
> From the way you study stuff I assume that you soon will be anyway.  
> ;)
>
>
> John W. Colby
> www.ColbyConsulting.com
>
>
>   
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com