Public Function editMemo()
On Error Resume Next
With Screen.ActiveControl
.SelStart = 0
.SelLength = 0
End With
End Function

I'd like to use this function to prevent accidental deletion of memo (text
box) content when user sets focus to an appropriate control, eg.
txtMemo.OnSetFocus is set to =editMemo().

But I'm experiencing something that I don't understand: when a user presses
Enter on a preceding control Access doesn't clear the key buffer and adds a
CRLF (blank line) to the beginning of the txtMemo control content
(txtMemo.Text).

I must be doing something wrong...

TIA

Vlado

In news:%(E-Mail Removed),
Vladimír Cvajniga <(E-Mail Removed)> wrote:
> Public Function editMemo()
> On Error Resume Next
> With Screen.ActiveControl
> .SelStart = 0
> .SelLength = 0
> End With
> End Function
>
> I'd like to use this function to prevent accidental deletion of memo
> (text box) content when user sets focus to an appropriate control, eg.
> txtMemo.OnSetFocus is set to =editMemo().
>
> But I'm experiencing something that I don't understand: when a user
> presses Enter on a preceding control Access doesn't clear the key
> buffer and adds a CRLF (blank line) to the beginning of the txtMemo
> control content (txtMemo.Text).
>
> I must be doing something wrong...

I don't think you're doing anything wrong; I think it's just an
interesting bug in how Access handles keyboard input. Note that the
problem only shows up when the control's EnterKeyBehavior property is
set to New Line in Field. It's also a fact that, when a user's keyboard
action sends the focus from one control to another, it's the receiving
control that processes the last keystroke (Tab or Enter). You can
demonstrate this by putting code in the txtMemo's KeyPress event, and
displaying the value of its KeyAscii argument. Pressing the Enter key
in the previous control causes txtMemo's KeyPress event to fire,
receiving an ASCII value of 13.

It seems to me that there must be internal code attached to text boxes
that ignores the keypress that is pending when the focus enters the
control. But once the focus is in the control, the control must
correctly process the subsequent keystrokes. So there must be a flag
somwehere that tells the control that it has just been entered, and it
should ignore the pending keystroke. Somehow, when you use the
control's GotFocus or Enter event to manipulate its .SelStart,
..SelLength, or .Text property (and maybe some others), that flag must be
reset. So now the control processes the pending keystroke, instead of
discarding it, and enters a newline according to its setting.

As a test, I put this code in the control's KeyPress event, and the
undesirable behavior went away:

'----- start of code -----
Private Sub txtMemo_KeyPress(KeyAscii As Integer)

If KeyAscii = 13 Then
With Me.ActiveControl
If .EnterKeyBehavior = True Then
If .SelStart = 0 And .SelLength = 0 Then
KeyAscii = 0
End If
End If
End With
End If

End Sub

'----- end of code -----

Unfortunately, I don't see how to make this a public function, since you
need the KeyAscii argument.

By the way, I checked, and the same behavior occurs in Access 97.

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)

TYVM for your quick and professional respond, Dirk.

Quite interesting bug, isn't it? The problem is that if I want to make my
function work as expected I must do some additional coding on preceding
controls. Yes, it may be more than one control - imagine some controls with
..TabStop = False
..Locked = False
(I can't set .Locked = True since user may want to copy some text to
clipboard)

Ie. user can click any of the preceding control with TabStop = False and
then press Enter. For all preceding controls I must do something like that:
Private Sub precControl1_KeyDown(KeyCode As Integer, Shift As Integer)
On Error Resume Next
If KeyCode = vbKeyReturn Then
KeyCode = 0
txtMemo.SetFocus
End If
End Sub

Unfortunatelly, due to KeyCode (KeyAscii) I can't create a general function
for OnKeyPress od OnKeyDown property. I could simplify the code but it's
still some more stuff to do to make the =editMemo() function properly.
in public module:
Public Function fncEditMemo(KeyCode As Integer, ctlMemo As Control)
On Error Resume Next
If KeyCode = vbKeyReturn Then
KeyCode = 0
ctlMemo.SetFocus
End If
End Function

in form's class module (for each of the preceding controls with tabStop =
False):
Private Sub precControl1_KeyDown(KeyCode As Integer, Shift As Integer)
fncEditMemo KeyCode, txtMemo
End Sub

So that if I have a memo-field with three non-TabStop preceding fields I
must add the _KeyDown Sub to four controls. Yes, four! It must be added to
the last control which preceds the first of the non-TabStop controls, too.
Example:
http://img175.imagevenue.com/img.php..._122_547lo.jpg

If only Access has ClearKeyBuf function like we had in PC FAND... :'-(
SendKeys "{DELETE}" in the editMemo function could do the job (delete the
blank line) but it's quite risky...
Is there an API function to clear key buffer? Couldn't find anything in
Google.

Vlado

"Dirk Goldgar" <(E-Mail Removed)> píše v diskusním pøíspìvku
news:%(E-Mail Removed)...
> In news:%(E-Mail Removed),
> Vladimír Cvajniga <(E-Mail Removed)> wrote:
>> Public Function editMemo()
>> On Error Resume Next
>> With Screen.ActiveControl
>> .SelStart = 0
>> .SelLength = 0
>> End With
>> End Function
>>
>> I'd like to use this function to prevent accidental deletion of memo
>> (text box) content when user sets focus to an appropriate control, eg.
>> txtMemo.OnSetFocus is set to =editMemo().
>>
>> But I'm experiencing something that I don't understand: when a user
>> presses Enter on a preceding control Access doesn't clear the key
>> buffer and adds a CRLF (blank line) to the beginning of the txtMemo
>> control content (txtMemo.Text).
>>
>> I must be doing something wrong...
>
> I don't think you're doing anything wrong; I think it's just an
> interesting bug in how Access handles keyboard input. Note that the
> problem only shows up when the control's EnterKeyBehavior property is set
> to New Line in Field. It's also a fact that, when a user's keyboard
> action sends the focus from one control to another, it's the receiving
> control that processes the last keystroke (Tab or Enter). You can
> demonstrate this by putting code in the txtMemo's KeyPress event, and
> displaying the value of its KeyAscii argument. Pressing the Enter key in
> the previous control causes txtMemo's KeyPress event to fire, receiving an
> ASCII value of 13.
>
> It seems to me that there must be internal code attached to text boxes
> that ignores the keypress that is pending when the focus enters the
> control. But once the focus is in the control, the control must correctly
> process the subsequent keystrokes. So there must be a flag somwehere that
> tells the control that it has just been entered, and it should ignore the
> pending keystroke. Somehow, when you use the control's GotFocus or Enter
> event to manipulate its .SelStart, .SelLength, or .Text property (and
> maybe some others), that flag must be reset. So now the control processes
> the pending keystroke, instead of discarding it, and enters a newline
> according to its setting.
>
> As a test, I put this code in the control's KeyPress event, and the
> undesirable behavior went away:
>
> '----- start of code -----
> Private Sub txtMemo_KeyPress(KeyAscii As Integer)
>
> If KeyAscii = 13 Then
> With Me.ActiveControl
> If .EnterKeyBehavior = True Then
> If .SelStart = 0 And .SelLength = 0 Then
> KeyAscii = 0
> End If
> End If
> End With
> End If
>
> End Sub
>
> '----- end of code -----
>
> Unfortunately, I don't see how to make this a public function, since you
> need the KeyAscii argument.
>
> By the way, I checked, and the same behavior occurs in Access 97.
>
> --
> Dirk Goldgar, MS Access MVP
> www.datagnostics.com
>
> (please reply to the newsgroup)
>
>