Overlapping ListBox obscurs data.

[DocBrown]

I have code that will change a list box height when the user clicks in it. My
form is set up that when dropped down this way it overlaps another label and
listbox. The issue is that the other 'lower' list box obscurs the data in the
expanded listbox. I've tried to force the upper listbox to the front and the
lower one to the back but it has no effect. The interesting part is there's a
label associated with the lower control and it is being displayed 'under' the
listbox.

Any thoughts? or is this just another Microsoft Access Glitch.

John

 

[Dirk Goldgar]

I have code that will change a list box height when the user clicks in it.
My
form is set up that when dropped down this way it overlaps another label
and
listbox. The issue is that the other 'lower' list box obscurs the data in
the
expanded listbox. I've tried to force the upper listbox to the front and
the
lower one to the back but it has no effect. The interesting part is
there's a
label associated with the lower control and it is being displayed 'under'
the
listbox.

Any thoughts? or is this just another Microsoft Access Glitch.

It seems Access doesn't realize that it has to repaint the form to cope with
the top list box's size change. Add the line

Me.Repaint

after you change the size of there sizable list box.

 

[DocBrown]

Tried it and no difference.

Actually, as I experiment with overlapping List Boxes, they don't seem to
handle the front and back concepts correctly. Even when I set them to overlap
and don't change them with my function, they don't work correctly.

Borders are incomplete where they overlap, they don't 'look' like one is in
front of the other at times. They don't respond to the 'send to back' and
'bring to front'

Combo boxes seem to be better, but they always seem to bring their text to
the front when dropped down.

Sheesh, unless some one has a workaround, I'll need to relayout my form to
prevent overlapping List Boxes.

 

[Dirk Goldgar]

Tried it and no difference.

Odd; it worked for me.

Actually, as I experiment with overlapping List Boxes, they don't seem to
handle the front and back concepts correctly. Even when I set them to
overlap
and don't change them with my function, they don't work correctly.

Borders are incomplete where they overlap, they don't 'look' like one is
in
front of the other at times. They don't respond to the 'send to back' and
'bring to front'

I agree that the borders aren't as clear-cut when they overlap. And List
boxes are quirky -- it seems they always want to be on top.

Combo boxes seem to be better, but they always seem to bring their text to
the front when dropped down.

I don't know what you mean. Any control will be brought to the front when
it has the focus.

 

[DocBrown]

It's hard to describe in text, but it's easy to see on a form.

Create a simple form and add a list box. Then sligthly to the left and
above, create a second list box. Position them so that they overlap.

Populate them with a list. Then change to Form view and see what happens..
Then change the lower listbox to a combo and see what happens. Oh and to
make it interesting, change the back color on one.

It's quite interesting. Looks like a bug to me. *grin*
John

 

[DocBrown]

I just found that this has been a known problem since Access 97.

http://support.microsoft.com/kb/166295

Guess it might never be fixed. *sigh*

 

[Dirk Goldgar]

It's hard to describe in text, but it's easy to see on a form.

Create a simple form and add a list box. Then sligthly to the left and
above, create a second list box. Position them so that they overlap.

Populate them with a list. Then change to Form view and see what happens..
Then change the lower listbox to a combo and see what happens. Oh and to
make it interesting, change the back color on one.

I see what you mean. I didn't explore all the possibilities in my quick
test. I knew that list boxes don't play well with others, but I didn't
realize it's this bad.

It's quite interesting. Looks like a bug to me. *grin*

Yep. And I see you've found that it's been around for a long time, leading
one to doubt that it will be fixed. A lot was reworked in Access 2007, so I
guess it's possible this was addressed. I'll check, next time I have A2007
open.