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

jwcolby jwcolby at colbyconsulting.com
Thu Aug 26 14:04:39 CDT 2010


A.D.

 >     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.

My point exactly.  Of course MS is way to busy doing important stuff (like designing pretty 
toolbars) to fix bugs.

;)

To be fair to MS, this is pretty esoteric stuff even by my standards.  They may never have had this 
bug reported in a reproducible fashion.

You should definitely report it, preferable with a little database that will demo the problem.

John W. Colby
www.ColbyConsulting.com


A.D. Tejpal wrote:
> 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



More information about the AccessD mailing list