Spell check - working as designed?

[Larry Kahm]

A client complained that minor changes to memo fields in a form were not
being saved, nor were they available in the PDF (S. Lebans' ReportToPDF)
version.

I reviewed the code, tested it, and could find no logical error.

The client then mentioned that the changes were based on a user hitting F7
for spell check.

I tested that with a sample record and was, well, shocked. Apparently spell
check does not dirty the record - and so the code-behind doesn't recognize a
change in the data (the save button doesn't activate, and a new PDF version
is not generated).

My questions: Is this working as designed? (How did I >not< know this?)
If so, what alternatives do I have to prevent these "hidden updates" from
occuring - or forcing the record to be dirty - to allow the data to be saved
and propogated to the report?

Thanks!

Larry

 

[Dirk Goldgar]

A client complained that minor changes to memo fields in a form were not
being saved, nor were they available in the PDF (S. Lebans' ReportToPDF)
version.

I reviewed the code, tested it, and could find no logical error.

The client then mentioned that the changes were based on a user hitting F7
for spell check.

I tested that with a sample record and was, well, shocked. Apparently
spell check does not dirty the record - and so the code-behind doesn't
recognize a change in the data (the save button doesn't activate, and a
new PDF version is not generated).

My questions: Is this working as designed? (How did I >not< know this?)
If so, what alternatives do I have to prevent these "hidden updates" from
occuring - or forcing the record to be dirty - to allow the data to be
saved and propogated to the report?

Fascinating! This was news to me, so I did a little quick testing in Access
2003. What version of Access are you using?

What I found was that, when the only change to the record was the result of
the spell check, the form's Dirty event did not fire and the text box's
Change event did not fire. However, the form's BeforeUpdate and AfterUpdate
events *did* fire, and they did so immediately, without waiting for me to
move to another record, close the form, or otherwise force the record to be
saved. So it seems that accepting the spell-checker's proposed changes is
considered to be also requesting that those changes be saved in the record.

Note that it is reasonabhle for the Dirty event not to fire in this
circumstance. The Dirty event is supposed to fire when the record is
dirtied directly by the user, and not when it is dirtied programmatically.
Invoking spell-check strikes me as more of a programmatic change, compared
to just typing in the control. Yes, in another sense, the use is explicitly
requesting a change to the record by invoking the spell checker, but it's a
step removed from the sort of user action that the Dirty event is intended
to trap.

It seems to me that, unless your version of Access behaves differently, you
could be using the form's AfterUpdate event to trigger the creation of a new
PDF. I don't know what you are currently doing in your code to "activate
the save button" or generate a new PDF. What is your current code doing,
and what triggers it? Not knowing anything about your application,
AfterUpdate seems on the face of it like the most logical event to me.

 

[Larry Kahm]

Dirk,

Thanks for a more thorough test that I was able to do. I am using A2003 and
my client is still using A2000; there's nothing different in the behavior
reported/detected.

The application has a Save button and a View PDF button. The former's cbf
checks to see if the record is dirty, determines if the record is being
added (as new) or edited (existing), and issues the "save report as pdf" to
incorporate the latest data into a PDF file stored on the network. The
latter's cbf pulls up the store version of the pdf from the network in
display mode.

The client is missing the spell-checked versions because the Save button
doesn't "do" anything when it is clicked after spell check. I shudder to
think of how many of the documents >don't< have the latest data (but that's
something a macro can take care of updating).

I'll add some code to the form's AfterUpdate event to ensure that the "save
report as pdf" is invoked, irrespective of any known changes.

Should I bother to test to see if F7 was invoked and trap that?

Thanks!

Larry

 

[Dirk Goldgar]

Dirk,

Thanks for a more thorough test that I was able to do. I am using A2003
and my client is still using A2000; there's nothing different in the
behavior reported/detected.

The application has a Save button and a View PDF button. The former's cbf
checks to see if the record is dirty, determines if the record is being
added (as new) or edited (existing), and issues the "save report as pdf"
to incorporate the latest data into a PDF file stored on the network. The
latter's cbf pulls up the store version of the pdf from the network in
display mode.

The client is missing the spell-checked versions because the Save button
doesn't "do" anything when it is clicked after spell check. I shudder to
think of how many of the documents >don't< have the latest data (but
that's something a macro can take care of updating).

I'll add some code to the form's AfterUpdate event to ensure that the
"save report as pdf" is invoked, irrespective of any known changes.

That should prevent the problem from arising. But I'm not sure about the
logic of having both a Save button and an automatic save. I usually don't
use a Save button in Access, because Access always saves a dirty record if
it can. Anything I have to do when a record is saved, I put into the form's
AfterUpdate event. The only time I have a Save button is when the record
should *not* be saved unless the user explicitly requests it, and that's a
more unusual situation that requires special programming.

Note that, in the AfterUpdate event, the form's NewRecord property will
always be False. So if you are using that to determine whether it's a new
record or an existing one that was just saved, you'll need to capture that
information no later than the form's BeforeUpdate event (probably in a
module-level variable), and hold it for use in the AfterUpdate event.

Should I bother to test to see if F7 was invoked and trap that?

You could, but the user could also have invoved spell-check via the menu or
toolbars (if you allow those to show), so it's probably not necessary. The
important thing to do is know that the record has been updated, for whatever
reason, and then do whatever it is you have to do. It seems to me, though
of course I don't know your application, that the AfterUpdate event should
really be the focus of this logic.

 

[Larry Kahm]

Dirk,

Further testing reveals that the form's AfterUpdate event gets processed

each time< the spell check changes a value.

Repeatedly saving the form's contents to PDF over the network is not
practical in that case.

Do you have any other suggestions?

Thanks!

Larry

 

[Dirk Goldgar]

Dirk,

Further testing reveals that the form's AfterUpdate event gets processed

Repeatedly saving the form's contents to PDF over the network is not
practical in that case.

Do you have any other suggestions?

Let me see if I understand what you are trying to do, and what the issues
are. In principle, when a record has been updated (whether added new or
edited), you want the record to be saved to a PDF. Am I right in thinking
that you need to know, in this process, whether the record was newly added
or not? Unfortunately, the action of the spell checker may fire the
AfterUpdate event multiple times for the same record, and you don't want to
run your SaveAsPDF process for every such occurrence -- only when the user
is done editing this record. Is that right?

If the above is correct, it seems to me that you need to defer the SaveAsPDF
process until either (a) the user moves to a new record, or (b) the user
closes the form. Only at that point would you want to determine whether the
record was modified and save it as a PDF if it was. Unfortunately, Access
doesn't provide a RecordExit event, though it was contemplated at one point
and even found its way into the help files. So to do this sort of thing,
you need some tricky code in the Current event and the Unload event.

Suppose you have code for the form's module something like this:

'----- start of example code for form module -----
Option Compare Database
Option Explicit

Dim varRecordID As Variant ' primary key of last "current" record
Dim mblnUpdated As Boolean ' was that record updated?
Dim mblnNewRecord As Boolean ' was that record new?

Private Sub Form_Current()

If mblnUpdated Then
SavePDF varRecordID, mblnNewRecord
End If

mblnUpdated = False
mblnNewRecord = Me.NewRecord

End Sub

Private Sub Form_AfterUpdate()

varRecordID = Me.RecordID
mblnUpdated = True

End Sub

Private Sub Form_Unload(Cancel As Integer)

If mblnUpdated Then
SavePDF varRecordID, mblnNewRecord
End If

End Sub

Private Sub cmdViewPDF_Click()

' Force the record to be saved if it's dirty.
If Me.Dirty Then Me.Dirty = False

' Force the PDF to be created if it hasn't been,
' or if it needs updating.
If mblnUpdated Then
SavePDF varRecordID, mblnNewRecord
mblnUpdated = False
End If

' ... here's where you put the code that displays the PDF ...

End Sub
'----- end of code -----

That would ensure that your SavePDF function would be called whenever the
user was done editing the record, and would pass the function what it
(presumably) needs to do its job. It also includes a change to the code for
the ViewPDF button to ensure that the PDF is updated, if necessary, before
it is displayed. I'm assuming the existence of a SavePDF function that can
be passed the key of the record to be displayed, rather than just assuming
that it's the current record.

That's just example code, of course, and untested at that, but you asked for
ideas.

 

[Larry Kahm]

Dirk,

Thank you for the code, it will undoubtedly come in very useful in some
future project. I am saving that newsgroup item.

I inherited this application, so there's very little "wiggle" room. What I
have to do is keep it simple.

There are four memo fields that are involved. I am going to update each
AfterUpdate event to include spell-check and reset the Dirty flag. That way
the existing code in the Save routine can remain "as is" and it will
continue to build the report based on the last set of changes and save it to
PDF.

I really appreciate your time and effort on this issue.

Larry