Does the form point to a pseudo row?

[esharris]

Each well-formed access table has (what I am going to call) a "pseudo row".
If a form is bound to a table with no rows, then the open form initially
points to this pseudo row. Similarly, a form also points to a pseudo row when
the user starts to add a new row to the end of a table. This pseudo row is
not a true row. Unlike a row, it does not have to satisfy any of the table
constraints.

Is there a way to programatically determine if a form points to the pseudo
row? I want to initialize a field in the pseudo row, when I open the form (or
start to add a new row). However, if the form points to a true row, the
program shouldn't do anything to the designated field.

 

[Brian]

The pseudo row is just a new, blank record. You will notice that another one
appears as soon as you type anything on that line. This is not evident in
Single view forms, where, unlike with Continuous forms, the user cannot
visually compare the blank one to a complete one on the screen simultaneously.

Here are some how-to's:

Identifying if you are on a new record:

If Form.NewRecord Then... 'Form.NewRecord is true whenever you are on a new
record. The will remain a new record until the record is saved, not just
until you type the first character in the record.

Go to a new record:

DoCmd.GoToRecord , , acNewRec

You can enter code in the BeforeInsert event of the form to populate fields
as soon as the user types the first character on any control in the new
record.

Private Sub Form_BeforeInsert()
MyControl = "abc"
End If

You could even start a new record and set some values in the form's open
event:

Private Sub Form_Open()
DoCmd.GoToRecord , , acNewRec 'go to new record
MyControl = "abc"
End Sub

However, be careful here. If a user opens the form, then closes it, he will
have just created a record with nothing but the "abc" in it, so make sure you
either require entry in critical fields (at the table level) and/or have some
sort of code in the form's BeforeUpdate event to ensure everything important
is complete before the user exits the form or otherwise saves the record.

A better idea might be to just use the BeforeInsert or set the default
values of some of the fields. The down side of BeforeInsert is that you have
to make sure not to try to change the value of the control the user is in
when he types the first character in a record, or your value may conflict
with his. The down side of default values is that they appear in the blank
record and can lead a user to believe that the record is an incomplete saved
record, not a new, blank one.