Display Textbox Name in Textbox

[JohnBornsworth]

Hello there,

Is there a way I can setup text boxes within a form to display their name prior to a user entering them? I'd like to save some space and not have every text box labeled with a label near them. Rather the user will see what to enter with whatever is in the field to begin with. Any ideas? I'm assuming before saving each record the "default" data would need to be deleted. Or maybe there is masking technique over the text boxes? Thanks for any help.

Johnny Bee.

[Micron]

I see 2 possibilities:
- a form bound to a temp table wherein each field is set to a value governed by 1) the control tag property via code, or 2) its name (less desirable IMHO) or 3) a value set in the table either by query or vba code, or 4) possibly temp table field default values.

- an unbound form wherein each field is set to a value governed by 1) the control tag property, or 2) vba code. Code would have to deal with saving the record.

Either method might require validation to ensure all required fields have been modified. The tag property method would give you a basis for comparison; i.e. if the tag and control values are the same, no change was made thus (maybe) you don't allow the form to be saved. Probably someone else will have a better idea.

[davegri]

Here's an easy to understand method.

Textbox property sheet:
Format tab
Format Property: @;"This will appear until you type something else"

You can automate the process with code like this:

Option Compare Database
Option Explicit

Private Sub Form_Current()
    If Me.NewRecord Then
        Check_in_date.Format = "@;""" & "Check-In Date"""
        Check_out_date.Format = "@;""" & "Check-Out Date"""
        Total_days.Format = "@;""" & "Total Days"""
        Season.Format = "@;""" & "Season"""
    End If
End Sub


Private Sub Check_in_date_AfterUpdate()
    Me.Check_in_date.Format = vbNullString
End Sub


Private Sub Check_out_date_AfterUpdate()
    Me.Check_out_date.Format = vbNullString
End Sub


Private Sub Total_days_AfterUpdate()
    Me.Total_days.Format = vbNullString
End Sub

The FORM_CURRENT event will set the format values for a new record.
Then as each field is filled in the format value is removed so that the field can display in its natural format.
If a field actually needs a format setting, set to that value instead of vbnullstring in the afterupdate.

[Micron]

I understand the concept, but what if there are 20, 30 or more controls? That's 60, 90 or more lines of code to handle them all. You've shown 3 examples, but where did you get those field names from? I don't see them in the first post. Perhaps OP edited post while I was composing an answer? How does vbnullstring tell a user that a control should have a PO number, or last name, or address, etc.? Or did I read something into the requirements that isn't really there?

[davegri]

I understand the concept,

Good for you.

[Micron]

Further to my suggestion to use the control tag property, here's what I could have (should have?) posted as an example

Private Sub Form_Current()
Dim ctl As Control

If Me.NewRecord Then
    For Each ctl In Me.Controls
        If ctl.ControlType = acTextBox Then ctl = ctl.Tag
    Next
End If
End Sub

It may be a bit too simplistic for your situation (e.g. you may have multiple control types to deal with), but I think it's quite adaptable.

Also, if you wish to prevent saving a record where one or more controls still contains a tag value, something like this (untested)

Private Sub Form_BeforeUpdate(Cancel As Integer)
Dim ctl As Control

For Each ctl In Me.Controls
  If ctl.ControlType = acTextBox Then
     If ctl = ctl.Tag Then 
         Cancel = True
         MsgBox "Must change all default values before leaving  or saving this record."
         Exit For
     End If
  End If
Next

End Sub

One thing I didn't mention earlier was that I don't agree with using the control name as an initial value. That's because controls and fields should follow any generally accepted naming convention. This means that an initial value of txtPOSDate (as an example) would confuse most users. IF all of the labels for the applicable controls are associated/attached to the control, the validation (BeforeUpdate event) can present a list of label names, which are likely more meaningful to a user than some cryptic control name. I realize the goal here is to not have labels, but I thought the point worth mentioning for future consideration when validating multiple controls.

[Micron]

Good for you.

OK smarty pants. That was a typo. Should have been If I understand the concept.
Your sarcasm is duly noted.