label on top of listbox

[jesse]

Hi,

I can't get a label or textbox to appear on top of a listbox. I've tried send to back and bring to front but this doesn't work.

Is the listbox always on top for some reason? And if so, is there a way to get around that?

tnx!

kind regards,
Jesse

 

[SteveSchapel]

Jesse,

I don't believe I have ever tried it. But if it's not possible, I'm not surprised.

Can you say what is the reason you want to do this? Someone may be able to suggest an alternative idea.

 

[jesse]

Yeah, I was afraid of that.

the reason is that I have a label that I can drag across the form (using vba). But if I have listboxes on the form (which I do) then the label is dragged behind the listbox instead of over it (which isn't the effect I was going for).

 

[missinglinq]

Access simply will not let you obstruct the view of data, why would it? Storing, manipulating and displaying data is what a database is all about!

What exactly are you trying to do here, in practical terms? I have to say that, on first glance, this sounds like a very odd function for a database!

Linq ;0)>

 

[Galaxiom]

Double post

http://www.access-programmers.co.uk/forums/showthread.php?t=196631

 

[SteveSchapel]

Not strictly true, Linq. I mean, you can put a label or a rectangle or whatnot over the top of a textbox or combobox, for example, and obscure data. But listboxes and subforms and tab controls all behave differently.

I'm guessing that Jesse wants to have a label do some fancy manoevre flitting across the face of the form to attract attention of the user, like one of those scrolling banners whatever they're called.

 

[missinglinq]

I just tried to do it placing a label over a textbox, to check my memory, in v2003, and regardless of how you have the Bring to Front/Send to Back options for either control set Access won't allow it to obscure the data display.

 

[ChrisO]

Well, it’s a bit rough, actually a bit more than a bit, but it sort of works.

I changed it from a label, couldn’t get that to work at all, to an empty list box.

The blue list box can be dragged over the white one.

Demo attached.

 

[vbaInet]

That's right Linq. All these controls have different z-orders. A subform has a higher z-order than a textbox, listbox, combobox etc, and all these controls just mentioned have a higher z-order than a label, line, box etc. A subform is a container that can house any control, hence its higher z-order, whilst the others (textbox, combobox, listbox etc) are also containers housing their own controls. For example a combobox is housing a textbox and a button. Labels, lines and boxes don't house anything so they are not containers.

I think there might be a way to change their default z-order but it would have to be done via an API.

 

[SteveSchapel]

Hi Linq,

That's weird. I just tried it too - not that it's a biggie because, as you suggest, one wouldn't normally do it. Also Access 2003. And placing a label or rectangle over a textbox does obscure the data. The effect is more dramatic if you set the backcolor of the label or rectangle. Funny thing I noticed, though... I tried to do the same to obscure a checkbox, in a continuous form, and it does so -- except for the current record, where the checkbox pops through to the front.

Breakfast calls. I'll have another look later and maybe post a demo, because I find it odd that you are getting different results.

 

[ChrisO]

A Form seems to work okay.

New demo attached.

 

[Galaxiom]

A subform is a container that can house any control, hence its higher z-order, whilst the others (textbox, combobox, listbox etc) are also containers housing their own controls. For example a combobox is housing a textbox and a button. Labels, lines and boxes don't

Technically (and perhaps slightly pedantically) this is not correct. A subform is nothing but an ordinary form object displayed inside a subformcontrol. Subformcontrols can only house a Form Object which in turn has a Collection of Controls.

I also discourage developers from using the word "container" in this context because Access already uses Containers further up the scale of the object tree. I suggest using "holder".

Unfortuantely there are not many good alternative words for this. (The Word Thesaurus suggested urn, jug, pot or bottle. ) Collection is already taken. Assembly is already used in .NET

On a similar note I also discourage developers using the word "method" to describe the way they are doing something since Method has an important meaning already.

I always use the word "technique" in this context.

 

[vbaInet]

That's correct. I was talking more in general/abstract terms.

I come from a Java background so I'm used to the word "container"

 

[SteveSchapel]

Linq,

Please have a look at the attached, and let me know what I have misunderstood.

 

[vbaInet]

Interesting Steve. It works! Try it in 2007.

 

[ChrisO]

G’day Steve.

I don’t fully know the requirement here but there seems to be a need to ‘drag’ using VBA.

If ‘drag’ means drag then using a Form instead of a Label works, see my previous attachment.

But if ‘drag’ means position then it will still fail with List Boxes please see this attachment.

Regards,
Chris.

 

[jesse]

ChrisO you have solved my problem.

Thanks everyone for thinking along.

kind regards,
Jesse

 

[SteveSchapel]

vbaInet,

Yep, ok. Did that. Behaves the same in Access 2007.

 

[SteveSchapel]

Yes, I see. Thanks Chris, very interesting. And in addition, it looks like your clairvoyant instinct was firing on target, which is a bonus.

 

[vbaInet]

Steve, Yes it does work. It only comes to the front when it has focus. Hmm...