delay dirty and autonum assignment

[Christopher Glaeser]

The sample code that follows is used to open a form and pre-fill some of the
fields ...

DoCmd.OpenForm "frmMyForm", DataMode:=acFormAdd
Forms!frmMyForm!ContactName = Me.ContactName
Forms!frmMyForm!ContactAddress = Me.ContactAddress

This is similar to setting frmMyForm default values, except the code above
sets the Dirty bit, and the autonum used for frmMyForm primary key is
allocated. Default values do not set the Dirty bit, and the autonum is not
allocated until the user begins to edit the form. Is it possible to
programmatically pre-fill fields in a form without setting the Dirty bit? I
want users to be able to be able to review and possibly cancel the
pre-filled form without allocating the next autonum. Of course, I could
maintain the pre-filled data in a temporary form and then copy the data to
the real form if the user does not click Cancel, but I was curious if Access
supported this feature directly. Perhaps something like ...

DoCmd.OpenForm "frmMyForm", DataMode:=acFormAdd, _
ContactName:=Me.ContactName, _
ContactAddress:=Me.ContactAddress

Best,
Christopher

 

[Lynn Trapp]

You can do that with an unbound form. After the user is satisfied that the
data is correct, run an insert statement to insert the data into the table.
The next autonumber will be assigned at the time of the insert.

 

[Dirk Goldgar]

The sample code that follows is used to open a form and pre-fill some
of the fields ...

DoCmd.OpenForm "frmMyForm", DataMode:=acFormAdd
Forms!frmMyForm!ContactName = Me.ContactName
Forms!frmMyForm!ContactAddress = Me.ContactAddress

This is similar to setting frmMyForm default values, except the code
above sets the Dirty bit, and the autonum used for frmMyForm primary
key is allocated. Default values do not set the Dirty bit, and the
autonum is not allocated until the user begins to edit the form. Is
it possible to programmatically pre-fill fields in a form without
setting the Dirty bit? I want users to be able to be able to review
and possibly cancel the pre-filled form without allocating the next
autonum. Of course, I could maintain the pre-filled data in a
temporary form and then copy the data to the real form if the user
does not click Cancel, but I was curious if Access supported this
feature directly. Perhaps something like ...

DoCmd.OpenForm "frmMyForm", DataMode:=acFormAdd, _
ContactName:=Me.ContactName, _
ContactAddress:=Me.ContactAddress

Best,
Christopher

One solution might be to set the default values for those controls --
instead of the values -- yourself, when you open the form:

DoCmd.OpenForm "frmMyForm", DataMode:=acFormAdd
With Forms!frmMyForm
!ContactName.DefaultValue = Chr(34) & Me.ContactName & Chr(34)
!ContactAddress = Chr(34) & Me.ContactAddress & Chr(34)
End With

 

[Christopher Glaeser]

You can do that with an unbound form. After the user is satisfied that the

data is correct, run an insert statement to insert the data into the
table. The next autonumber will be assigned at the time of the insert.

Excellent. I think this is similar to QuickBooks invoices. Thanks!

Best,
Christopher

 

[Christopher Glaeser]

!ContactName.DefaultValue = Chr(34) & Me.ContactName & Chr(34)

Thanks for the quick response. What is the purpose of the Chr(34)?

Best,
Christopher

 

[Andi Mayer]

Thanks for the quick response. What is the purpose of the Chr(34)?

type into the immidiate window: ?Chr(34)

 

[Christopher Glaeser]

!ContactName.DefaultValue = Chr(34) & Me.ContactName & Chr(34)

type into the immidiate window: ?Chr(34)

Thanks, that's good to know, but why not

!ContactName.DefaultValue = Me.ContactName

I'm guessing is has something to do with potential Null values, but I'm not
clear on why Null values can't be assigned.

Best,
Christopher

 

[Andi Mayer]

Thanks, that's good to know, but why not

!ContactName.DefaultValue = Me.ContactName

I'm guessing is has something to do with potential Null values, but I'm not
clear on why Null values can't be assigned.

no, a string value has to be in quotes

 

[Dirk Goldgar]

Thanks, that's good to know, but why not

!ContactName.DefaultValue = Me.ContactName

I'm guessing is has something to do with potential Null values, but
I'm not clear on why Null values can't be assigned.

Best,
Christopher

It doesn't actually have anything to do with Null values. The
DefaultValue property is a text property that may be set to a (string)
representation of the value to be assigned to the control by default.
The form this string should take depends on the data type of the
control's value. If the control is bound to a number field, this might
be a valid assignment:

ControlReference.DefaultValue = "1234"

That assigns a string representation of a number value.

If the control is bound to a date field, this might be a valid
assignment:

ControlReference.DefaultValue = "#01/19/2005#"

That assigns a string representation of a date value. Note the use of
the date delimiter '#'.

If the control is bound to a text field, either of these might be a
valid assignment:

ControlReference.DefaultValue = """my default text"""
ControlReference.DefaultValue = Chr(34) & "my default text" &
Chr(34)

Either of the above assigns a string representation of a string value,
including the quotes surrounding the text.

In your case, your controls are bound to text fields, so we set the
default value to a string representation of the string value to be
assigned.

Note, by the way, that normal conversions allow you to use the string
representation format to be used for non-text controls, so that's a
handy form to use when you're setting the DefaultValue property for a
heterogeneous set of controls.

 

[Christopher Glaeser]

In your case, your controls are bound to text fields, so we set the

default value to a string representation of the string value to be
assigned.

Thanks Dirk, this is quite helpful. I had not noticed a distinction between
text and string. This explains a syntax error I had encountered.

Best,
Christopher