[AccessD] Building a control class

John,

    Your detailed clarifications on various points are most helpful. In actual implementation, I intend to give very high weightage to your recommendations. The intention of these postings is to look at various angles (somewhat akin to devils advocate), so as to derive the benefit of your experience and knowledge.

    Interestingly, it is observed that code blocks with raised events sandwiched in-between, do get executed in the intended sequence. For example:, in the following case, control class objects of text box type respond to (B) after execution of code (A). Thereafter code (C) executes, followed by control class objects of combo box type responding to (D). Thereafter, code (E) executes.

'====================================
Private Sub mFrm_Current()

    '<< Do Something >>        ' (A)

    RaiseEvent FormCurrentForCombo(<< Arguments suiting Combo >>)    ' (B)
    
    '<< Do Something >>        ' (C)
    
    RaiseEvent FormCurrentForTxtBox(<< Arguments suiting TxtBox >>)    ' (D)

    '<< Do Something >>        ' (E)

End sub
'====================================

    However, as mentioned by you, once the controls of a given type start responding to a raised event trapped in their respective class (say (B) or (D) above), the sequence within the control group gets governed by the order in which the controls were instantiated. If the situation demands a special order to be observed in code execution, even within similar type controls, and if the overall number of different types of controls is large, tailor-made ancillary mini-collections could perhaps be considered for faster iteration while handling everything within form class itself, without projecting the form class events to control class.

Best wishes,
A.D. Tejpal
------------

  ----- Original Message ----- 
  From: John W Colby 
  To: Access Developers discussion and problem solving 
  Sent: Monday, March 16, 2009 20:05
  Subject: Re: [AccessD] Building a control class


  AD,

  The frmClass is in fact a wrapper to the form object, so of course in 
  that case declaring the form objects WithEvents and sinking any and all 
  events is expected.

  As for sinking form events in control objects in the "one to many" 
  relationship, I understand what you are saying.  It does indeed make 
  programming easier in the sense that the control class obtains control 
  of the form's event directly and the form does not have to iterate a 
  collection and call a method of a slew of different control classes.  
  However it also gives you much less control in dictating when control is 
  passed to the control class.  For example suppose that in your form 
  class you had a situation like this:

  sub mFrm_Current()

      do something
      do something else that has to be done before the control classes get 
  control
      >>>call the controls to do something
      do something that needs the controls initialized
      do something else
  end sub

  As you can see, if the control classes get control automatically they 
  will get control AFTER mfrm_Current finishes processing and exits the 
  sub.  The order of code execution is a simple "which object was 
  instantiated first".  The form object was instantiated first, and in 
  fact the scanner in the control class instantiates all of the control 
  classes, so all of its processing will totally complete before the 
  control classes are allowed to gain control.

  Now you as a programmer may not care, but just keep that in mind.

  The important point in this discussion is not that "it has to be done 
  this way" but rather that you understand the concepts involved, that you 
  understand the details involved, and that you as a programmer can make 
  an educated decision how to do this based on your own desires and needs.

  I attempt to teach "best practices", and one of the precepts of classes 
  and best practices for classes is that you design an interface and then 
  program to that interface.  The methods and properties of the control 
  class are its interface.  Raising events are an interface.  By using 
  these two interfaces you "decouple" the control classes from the form 
  class. 

  As an example I can and do very occasionally use the control classes 
  DIRECTLY in the form's code behind form.  If the control's class is 
  expecting to be passed either the form class or the form itself, and to 
  perform processing specific to a particular problem, then using the 
  class directly in the form's code behind form becomes problematic.  The 
  control class is no longer decoupled from the form or clsFrm, it 
  explicitly depends on that object.

  I do in fact pass in a pointer to parent, but there are many places 
  where I just set that to null when calling the mInit.  Thus if no valid 
  parent exists, no problem.

  Again, I am not discouraging you from actually declaring the form 
  WithEvents in the control class, I am simply pointing out that every 
  shortcut caries with it a potential problem.  OOP has evolved over the 
  last decades and lots of people contributed tons of ideas, and some of 
  these distilled down into the "interface" concepts.  I think it is 
  perfectly OK to buck "the thinking" as long as you know why the thinking 
  exists, have specific reasons to go against the thinking, and know what 
  the ramifications are.

  You are one of the people I would be most comfortable watching go your 
  own way simply because you obviously have a very firm grasp of how and 
  why things work, and can get yourself out of any problems you might 
  encounter.

  John W. Colby
  www.ColbyConsulting.com