Risk in using Combo

[Frank Situmorang]

Hello,

I want to ask again my question in my last time thread, regarding asking
confirmation whether to do changes or not.

My question is why for some computer this code works, and for some is not
Private Sub SuplierNo_BeforeUpdate(Cancel As Integer)
If Not IsNull(Me.[ProjectID].OldValue) Then
If Me.[ProjectID] <> Me.[ProjectID].OldValue Then
If MsgBox("Anda telah merobah!!, apakah sengaja mau merobah?",
vbYesNo + vbDefaultButton2 + vbQuestion) = vbNo Then
' Undo the changes
SendKey "{Esc}"
Cancel = True
End If
End If
End If
End Sub

But when we change it to after update and replace SendKey "{Esc}"
Cancel = True
with Me.[ProjectID] = Me.[ProjectID].OldValue

It works.

But for some computers of my subbordinates it works even with the old VBA. I
wonrder it happenned on my computer as a developper.

Pls. help

 

[Douglas J. Steele]

SendKeys is extremely unpredictable. If focus changes while the code is
running, the key stroke will be set to the new window. Realistically, use of
SendKeys should be avoided at all costs.

You could just have easily used

Me.[ProjectID].Undo

 

[Linq Adams via AccessMonster.com]

Anytime you have a problem with code working on some machines and not others
you need to state the Access version and Windows version being used on PCs
where it works and on PCs where it doesn't. Post back and let us know that.
Also, you need to state exactly what you mean by "doesn't work" i.e you get
an error message (what error) the messagbox doesn't appear and so forth.

SendKeys is very unreliable; they work in some situations/versions and don't
in others! They should be used only as a ***LAST RESORT*** when nothing else
is available! In this particular case, to undo changes, they can simply be
replaced with

Me.Undo

You also need to complete this statement:

"But when we change it to after update and replace

SendKey "{Esc}"
Cancel = True

with Me.[ProjectID] = Me.[ProjectID].OldValue"

What? What happens when you do this?

The single most common reason something works on one PC and not another is
that references are missing on the non-functioning machine, but I see nothing
in this code that should require a reference to work.

Post back the info requested in my first paragraph and I or someone else will
take a look.

Linq

--
There's ALWAYS more than one way to skin a cat!

Answers/posts based on Access 2000/2003

Message posted via AccessMonster.com

 

[Linq Adams via AccessMonster.com]

Sorry, Doug! Didn't see you there! Had to walk the dog mid-reply!

Linq

--
There's ALWAYS more than one way to skin a cat!

Answers/posts based on Access 2000/2003

Message posted via AccessMonster.com