[AccessD] Option Group's Control Collection - Weird Behavior

J.C.,  Drew,

    In this particular case, it appears to be primarily a matter of one particular built-in sub-collection failing to comply with the required consistency.

    In a form having different types of controls, including option groups, the controls collection pertaining to the form performs normally. Cycling through form's controls via For Each loop gives consistent results, despite programmatic manipulation of their top property. 

    All the subcontrols (toggle buttons / option buttons / check boxes) belonging to an option group, apart from belonging to option group's controls collection, do feature in form's control collection as well. There is no problem if top property of a horizontal row of such subcontrols is manipulated via form's control collection, using For Each loop. However, similar exercise using controls collection belonging to the option group itself, reveals erratic behavior, with skipping of some controls, while some other controls get acted upon more than once.

    Let us examine a parallel case i.e. subcontrols located on a tab control. Each of such subcontrols happens to be a member of two built-in collections i.e. (a) Controls collection belonging to the given page of tab control. and (b) Controls collection of the form itself. It is observed that there is no inconsistency if an exercise similar to that in previous para is carried out by looping through either of these collections. 

    Note: 
    (a) Tab control itself does not have any controls collection directly. Instead it has Pages collection, each page in turn having controls collection.
    (b) Even though a subcontrol can feature in more than one collection, its parent property always points to its immediate container (i.e. option group or pertinent page in case of tab control)

    It would thus appear that built-in control collections in access do perform properly, with the exception of that belonging to an option group. Apparently a bug in need of remedial action by Microsoft.

    Interim solution:
    ===========
    Two alternatives are found effective:
    (a) Even for subcontrols pertaining to an option group, loop through form's control collection and manipulate individual items after testing for parent property.
    (b) Create a temporary collection. Populate it with the subcontrols belonging to the option group in question and loop through this collection for conducting the desired manipulation. This alternative might be found more convenient in certain situations (e.g. where the option group in question has been accessed while looping through the form's controls collection).

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

  ----- Original Message ----- 
  From: Drew Wutka 
  To: Access Developers discussion and problem solving 
  Sent: Thursday, August 26, 2010 20:58
  Subject: Re: [AccessD] Option Group's Control Collection - Weird Behavior


  Yep, back in the day, I was creating a VB program that would 'remote' an
  Access session.  At the time, we had an Access database that was
  basically a big reporting engine for our production database.  The
  reports run, would prompt with dialog boxes (Access generated).  So the
  'remote' program I wrote, would run the report in one thread, and in a
  separate thread, it would watch for dialog boxes.  When one appeared, it
  used Window API calls to capture the dimensions and characteristics of
  the dialog box, and then it recreated them in an HTML format.  Worked
  pretty good.  Our remote users could run all the reports they wanted,
  and they got web pages that displayed the dialog prompts until the
  report actually ran (and the report was then sent in HTML or .snp
  format).

  When I tried to use the same process for an Access Form, however, that's
  when I ran into the monstrous subclassing that Access uses on it's
  forms.

  I have two little apps I wrote a long time ago, one's MoveWindows (when
  you run the program, it builds a treeview of all the windows on your
  computer, and allows you to manipulate the coordinates and whether they
  are visible or not), the other is Window Info.  When that one runs, it
  displays the window info of whatever the mouse is over.  If someone has
  a place to put them up on the web, I can email the .exes out.  (They
  were written in VB, but almost everyone has the VB runtimes installed
  nowadays).  It's a 13k zip file with both .exes.  Run that Show Windows
  one, and you'll see the difference between an Access Form, and almost
  any other window on your machine.  Heck, the Show Windows app itself,
  when you move your mouse over the text boxes, shows each text box to be
  its own window.  Do that over an Access Form, and you'll see it's not
  what you'd expect.  There are several 'child' windows, but the only
  'control' is the active one, so when you move focus from one control to
  the next, the 'active' window moves to that control, everything else on
  the form is 'non-existant' as far as Windows is concerned.

  Drew

  -----Original Message-----
  From: accessd-bounces at databaseadvisors.com
  [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
  Sent: Thursday, August 26, 2010 8:55 AM
  To: Access Developers discussion and problem solving
  Subject: Re: [AccessD] Option Group's Control Collection - Weird
  Behavior

  A.D. / Michael,

  If I remember correctly, objects in Access are not individual "windows",
  in other words you cannot 
  get a handle to window for a combo or a text box (or anything else) in
  Access.  In most programs, 
  when a graphical object is drawn by the windows operating system,
  Windows maps the memory, Windows 
  draws it, and Windows hands you back a Handle To Window for that object,
  IOW it creates a handle to 
  the exact piece of screen real estate that Windows uses.

  This is all just vague memories but the bottom line is that every
  "object" on a form is somehow 
  drawn internally by Access (not directly by Windows), and I *believe*
  that is what you are running 
  into here.  When you programmatically move objects around, you are
  confusing the code internal to 
  Access that draws and keeps track of where objects are drawn on the
  screen.

  IIRC Drew knows a lot about this stuff, in fact I think it was Drew that
  discussed all this stuff 
  ages ago.

  John W. Colby
  www.ColbyConsulting.com


  Michael Mattys wrote:
  > Hi A.D.,
  > 
  > I changed the number to move in the loop to 10.
  > I haven't come upon a solution yet, but I do find this amusing!
  > 
  > Michael R Mattys
  > Business Process Developers
  > www.mattysconsulting.com