I am trying to add an undo button to my form. If the record is dirty,
I'd like the user to be prompted to confirm he wants to undo the
record. If it's not dirty, just ignore.

The problem is that simply clicking on the "Undo" label makes the
dirty property = True. (Same thing happens if I use a command button,
instead of a label.)

What's causing this? I do have some AfterUpdate and AfterInsert code,
but I wouldn't think that would be triggered by clicking on a label
(or command button).

Any ideas?

I think I narrowed it down to the call that opens the form, rather
than any code in the form itself. If I comment out a specific line,
Dirty stays false when I click on the label. Otherwise, any click
event on the form makes Dirty = True.

Below is the code that opens the form. It's behind a command button on
a continuous subform, fsubEvents. The problem is being caused by the
third to last line:

Forms(stDocName).Controls("PatientID").Value = Me.Parent!PatientID

Commenting it out fixes the issue. I just don't see why. The basic
user flow is: User clicks on a record in a continuous subform,
fsubEvents. The main form is frmPatients. The form that opens depends
on the form that's called (based on the record in fsubPatientEvents).

###

Private Sub cmdViewEvent_Click()

Dim stDocName As String
Dim stLinkCriteria As String
Dim stQuery As String
Dim rstTemp As New ADODB.Recordset

stQuery = "SELECT EventFrm, EventID "
stQuery = stQuery & "FROM PatientEvent INNER JOIN TypesEvent ON
PatientEvent.EventTypeID = TypesEvent.EventTypeID "
stQuery = stQuery & "Where PatientEvent.PEventID=" &
Me.PEventID
rstTemp.Open stQuery, CurrentProject.Connection, adOpenKeyset,
adLockOptimistic

stDocName = rstTemp("EventFrm")
stLinkCriteria = "[EventID]=" & rstTemp![EventID]

DoCmd.openForm stDocName, , , stLinkCriteria

' this line makes Dirty = True for all click events on the form
that opened
Forms(stDocName).Controls("PatientID").Value = Me.Parent!
PatientID
rstTemp.Close
Exit Sub

End Sub

###

0 1 <(E-Mail Removed)> wrote in
news:893da083-ef45-43b1-9021-(E-Mail Removed)
m:

> ' this line makes Dirty = True for all click events on the
> form
> that opened
> Forms(stDocName).Controls("PatientID").Value = Me.Parent!
> PatientID

Yes, of course it dirties the form whose name is stored in the
variable stDocName. Is it possible the recordset is looking up the
wrong record and assigning the wrong form name to that variable?

Looks like very strange code to me. I don't see why you couldn't
have a saved QueryDef that's the same as the recordset without a
WHERE clause, and then use a DLookup() to get the value you need.
Even if I were going to do it with a recordset, I'd never use ADO
for something like this -- it's simply completely unnecessary to use
anything other than DAO.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

On Feb 12, 7:03*pm, "David-W-Fenton" <NoEm...@SeeSignature.invalid>
wrote:
> 0 1 <hhholme...@gmail.com> wrote innews:893da083-ef45-43b1-9021-(E-Mail Removed)
> m:
>
> > * * ' this line makes Dirty = True for all click events on the
> > * * form
> > that opened
> > * * Forms(stDocName).Controls("PatientID").Value = Me.Parent!
> > PatientID
>
> Yes, of course it dirties the form whose name is stored in the
> variable stDocName.

I see why it would dirty it upon opening, but once the form is open,
this code is over isn't it? How does it permanently create a scenario
where any click even on the opened form dirties the record?

> Is it possible the recordset is looking up the
> wrong record and assigning the wrong form name to that variable?

The correct record and correct form seem to always be assigned.

> Looks like very strange code to me. I don't see why you couldn't
> have a saved QueryDef that's the same as the recordset without a
> WHERE clause, and then use a DLookup() to get the value you need.
> Even if I were going to do it with a recordset, I'd never use ADO
> for something like this -- it's simply completely unnecessary to use
> anything other than DAO.

I completely agree. I inherited much of this code, and because there
was so much of it I've tried to work with it rather than rewrite. But
so much of if seems unnecessarily complicated and, for lack of a
better word, long-winded.

> --
> David W. Fenton * * * * * * * * *http://www.dfenton.com/
> contact via website only * *http://www.dfenton.com/DFA/

0 1 <(E-Mail Removed)> wrote in
news:0f22adbb-6600-4a43-80b5-(E-Mail Removed)
m:

>
> I see why it would dirty it upon opening, but once the form is
> open, this code is over isn't it? How does it permanently create a
> scenario where any click even on the opened form dirties the
> record?
>

Changing the data in the table or query inside a form makes it dirty.

A form stays dirty until the record that is dirtying it is either saved
or cancelled.

In your example the form is dirtied by the calling code as soon as it
is opened. It will stay dirty until explicitly saved, implicitly saved
(by changing record or closing) or undone.

Access does not check that the form is dirty when it is opened, it only
checks when the form is touched by the user.


--
Bob Q.
PA is y I've altered my address.

0 1 <(E-Mail Removed)> wrote in
news:0f22adbb-6600-4a43-80b5-(E-Mail Removed)
m:

> On Feb 12, 7:03*pm, "David-W-Fenton"
> <NoEm...@SeeSignature.invalid> wrote:
>> 0 1 <hhholme...@gmail.com> wrote
>> innews:893da083-ef45-43b1-9021-bab354a54
> (E-Mail Removed)
>> m:
>>
>> > * * ' this line makes Dirty = True for all click events on the
>> > * * form
>> > that opened
>> > * * Forms(stDocName).Controls("PatientID").Value = Me.Parent!
>> > PatientID
>>
>> Yes, of course it dirties the form whose name is stored in the
>> variable stDocName.
>
> I see why it would dirty it upon opening, but once the form is
> open, this code is over isn't it? How does it permanently create a
> scenario where any click even on the opened form dirties the
> record?

Are there subforms involved?

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

>>>
>>> Yes, of course it dirties the form whose name is stored in the
>>> variable stDocName.
>>
>> I see why it would dirty it upon opening, but once the form is
>> open, this code is over isn't it? How does it permanently create a
>> scenario where any click even on the opened form dirties the
>> record?
>
I missed most of this but is done after the form opens to "undirty" the
record?

The normal action of clicking on a label selects the entire field. Once
selected any action in that field would dity the form, so what happens after
that click?

> > I see why it would dirty it upon opening, but once the form is
> > open, this code is over isn't it? How does it permanently create a
> > scenario where any click even on the opened form dirties the
> > record?
>
> Changing the data in the table or query inside a form makes it dirty.
>
> A form stays dirty until the record that is dirtying it is either saved
> or cancelled.
>
> In your example the form is dirtied by the calling code as soon as it
> is opened. It will stay dirty until explicitly saved, implicitly saved
> (by changing record or closing) or undone.

> Access does not check that the form is dirty when it is opened, it only
> checks when the form is touched by the user.

I added to the OnLoad event of the form a line to set Dirty = False,
and using Debug.Print Me.Dirty (right after the Me.Dirty = False line)
confirmed that Dirty was indeed set to False after the form opened.
But then I clicked on a command button - a command button that didn't
even have any event or code associated with it, other then
"Debug.Print Me.Dirty" in the Click Event - and watched the Immediate
Window: Dirty turned True. This is what puzzled me. Clicking on a
command button with no "real" code behind doesn't change the data in
any way. I do have code that affects the recordset in the form's
Before Insert and After Insert events, but my understanding is these
only trigger when you insert a character into a record.

As for the resolution, see my reply to Marshall Barton's post about
the open args event, which solved the issue.

> Well, that explains it. *Now the question is why di you have
> that line of code? *And, if a record already exists, doesn't
> it already have its PatientID set?
> I seems like you may want to set the PatientID for new
> records (events?), but there is no reason to set it when the
> form is opened.

Very true. PatientID needs to be set for new records, but not for
existing ones (in which the PatientID is already there). Not sure why
the original programmer programmed it that way, but I suspect it had
something to do with the weird way he was populating two tables.
Imagine a many-to-many, but the junction table and one of the tables
on the one side weren't linked. This was the part of the database
model.

When the user opened the form (which was based on the table on the one
side of the m:m), and entered his first character, the AfterInsert
code would open a new ADOB.Recordset and populate the junction table
with the appropriate child fields for both sides of the m:m. Doing
this (I guess) created a value for the junction table's autonumber
(and PK) field. This value was then copied to the form's recordset
(Me.Recordset).

> To arrange for new records to have the PatientID set
> automatically, get rid of the offending line of code and
> change the open form code to use the OpanArgs arguments:
>
> * * DoCmd.OpenForm stDocName, , , stLinkCriteria, _
> * * * * * * * * * * * * * * *OpenArgs:= Me.Parent!PatientID
>
> And add code like this to all the event forms' Load event
> procedure:
> * *If Not IsNull(Me.OpenArgs) Then
> * * * Me.PatientID.DefaultValue = """" & Me.OpenArgs & """"
> * *End If

This did the trick, and the phenomenon of the Dirty becoming True
simply by clicking a command button (with no real code behind it) has
gone away. I guess I don't see how setting the PatientID via OpenArgs
is any different than setting it via a line like
Forms(stDocName).Controls("PatientID").Value = Me.Parent! (I don't
understand Open Args all that well.)

It seems the above code says:

If Open Args has a value (which it will every time, right? In this
case, it's always set to Me.Parent!PatientID), then make the default
value of PatientID = to the value of OpenArgs (which is always
Me.Parent!PatientID). How is this different than:

Forms(stDocName).Controls("PatientID").Value = Me.Parent!

It seems perhaps the outcome is the same, but the means of getting
there is different.

Thanks for your help.

0 1 <(E-Mail Removed)> wrote in
news:665e0a7d-a4c6-452e-bac5-(E-Mail Removed)
m:

> I do have code that affects the recordset in the form's
> Before Insert and After Insert events, but my understanding is
> these only trigger when you insert a character into a record.

I would never edit the form's recordset. You should edit the data
loaded in the form's edit buffer directly, instead. I know you
resolved your problem elsewhere, but editing the recordset is
precisely the kind of thing that can cause confusing results, and
really should be avoided, as far as I'm concerned. It's a very
un-Access way of doing things.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/