How to move only labels and not textboxes when designing a form

[twgonder]

This has been driving me nuts.
I want to move all the labels left, but leave the textboxes where they are.


They both move, no matter what I try.
Do I have to clear the "Label Name" for the textbox first to get this done. What else is affected if I do this?

[June7]

Did you try click/grab/drag the anchor block at upper left of label?

[ArviLaanemets]

When creating a new form, I usually select all labels, cut them all (Ctrl + X), paste them back (the block of pasted labels will be situated in left upper corner of form), and then drag label block back to (approximately) previous location. After that I can continue with design at will - labels aren't connected to controls anymore.

[Minty]

If you move one label to the desired position (Using June's method) , you can then group them all and Align Left(or Right depending on where you moved them) and they will align independently of the controls they are associated with.

[twgonder]

The whole point is that I move a block of existing fields into the form, I like where I placed them for the most part,
I just need to adjust the labels for the largest label, and then do the same with the textboxes.
Nothing magical or illogical here.
It seems crazy to disassemble a group of fields then reassemble them again just for placement.
This is the kind of time wasting activity that Access encourages that I hate.
Even crazier if you have to "break" the associated label for a text box control.
Why have that property in the first place if you have to defeat it just to move only a label?


So, there is no easy way to just select and move only the labels?

[twgonder]

If you move one label to the desired position (Using June's method) , you can then group them all and Align Left(or Right depending on where you moved them) and they will align independently of the controls they are associated with.

I tested this suggestion every way I can think of, I can't get the labels to move independently.

Update: Okay, I finally figured a way to do this without leaving orphan text boxes all over the form. Thanks for the suggestion, but good grief Microsoft! Maybe move with shift, or ctrl, or alt or something to allow this basic movement of only labels?

To answer the other part of the question, what does this label name property do? Well I pressed F1, and guess what happened?
(It's bad enough I can't get offline helps, but when I'm using my precious online {connected by my celular} I get ...)

[Minty]

It's simple if you you use the align tools, select the controls or labels you want.
Right click and size to widest/narrowest.
Right click again and align left or right. It will only move the object you have selected on their own, not with the associated label or control .

[Minty]

Does this explain it better?

[mike60smart]

Hi

In Design View of the Form Select all Controls & Labels required.

From the Menu select - "Arrange" - Then Click "Remove LayouT"

You are then able to Move/Resize labels as necessary

[ArviLaanemets]

Even crazier if you have to "break" the associated label for a text box control.
Why have that property in the first place if you have to defeat it just to move only a label?

So you can easily recognize, which label belongs to which control, when you create the form using wizard
To break 'associations' takes only couple of tens of seconds. I spend much more renaming every one of them, because I prefer label names in format lblControlName

[twgonder]

Does this explain it better?

Yes it did, it took me awhile without it, but I got there.
The next person with the same problem will greatly benefit from your effort.

[twgonder]

So you can easily recognize, which label belongs to which control, when you create the form using wizard
To break 'associations' takes only couple of tens of seconds. I spend much more renaming every one of them, because I prefer label names in format lblControlName

Is there no downside to breaking the association?

[ArviLaanemets]

Is there no downside to breaking the association?

None! Anyone can do it in way he/she likes it!

[Micron]

None!

I disagree. You lose the ability to refer to the control's control collection. This collection only has one member - the label, whose index is 0. Where this comes in handy is for things like form validation where you loop over a bunch of controls (often using control tag property to group controls for validation). If you prompt user with

Msgbox "Please enter a value in the " & ctl.Name & " field"

you can get a message that says "Please enter a value in the txtCustName field" - not very intuitive. However, labels almost always have meaningful descriptions for the use of the field. Using

Msgbox "Please enter a value in the " & ctl.Controls(0).Caption & " field" will use the label caption instead. There might be other reasons one would benefit from the connection but none come to mind at present.

[twgonder]

I disagree. You lose the ability ... form validation where you loop over a bunch of controls (often using control tag property to group controls for validation). If you prompt user with

...

That little bolded part caught my attention! I've been testing a solution for multi-language that used the tag property in forms and report captions, command buttons and maybe some other controls I haven't yet figured out. The article and sample db for this translation scheme was written many years ago. I've had concerns that the way tagged was used to hold a translation key could be problematic if future applications use that tag property, or if Microsoft decides to change or remove it.

And now you talk about using it for validation (I'm not sure what you're referring to there), but if tag was overwritten, my whole translation scheme is destroyed unless I have a way to save and restore all those tags in the tag property of forms and reports.

But first, in the current versions of access, or with common utilities that people use, is there an reason to NOT use the tag property for storing the translation codes? Has Microsoft added any optional "user" fields to the objects, so that users can have their own protected area for this kind of storage? If so, how can those be made visible?

If it's a bad idea to use Access properties for storing something like this translation code, then I need to go in the reverse direction create a table of translations that allows a filling of the caption property based on some unique data in the other properties of labels and buttons.