Using the ">" forced capitalization in Memo field

[Don Barton]

I have a memo field. When my clients put a paragraph or so of text
into the field, some of text would be truncated when the field lost
focus. This should not be happening in a memo field, as I should be
able to use upwards of 32K worth of text data. I had no where near
that much data in the field. Why is this happening?
When I set up the memo field on the form, I placed a ">" (forced
capitalization) in the Format property, so everything would be in
capitals. Removing the ">" took care of the problem. I don't think
this is by design on Microsoft's part, and suspect this is a bug.
Has anyone else ever seen this? Could someone else try to verify
this? If so, it needs to be reported.

Thanks,
Don

 

[Allen Browne]

Well, you are correct that using something in the Format of the memo does
cause only the first 255 characters to display. If you want a source to
quote, see:
Truncation of Memo fields
at:
http://allenbrowne.com/ser-63.html

This has been the case in all versions of Access. If you really need the
field to be converted to upper case, use the AfterUpdate event procedure of
the text box to convert it to upper case. It is then stored that way, and
does not need to be formatted each time it is retrieved. (For existing data,
use an Update query to convert it to upper case.)

 

[missinglinq via AccessMonster.com]

I actually had the opposite problem; client wanted everything in the db in
caps EXCEPT the narrations in the memo fields! Found this hack somewhere a
while ago; don't remember where. It turns the CapsLock On and Off.

In a new module place this code:

'Windows API/Global Declarations for :CapLock
'*********************************************
Public Const VK_CAPLOCK = &H14

Public Type KeyboardBytes
kbByte(0 To 255) As Byte
End Type
Public kbArray As KeyboardBytes

Public Declare Function GetKeyState Lib "user32" _
(ByVal nVirtKey As Long) As Long
Public Declare Function GetKeyboardState Lib "user32" _
(kbArray As KeyboardBytes) As Long
Public Declare Function SetKeyboardState Lib "user32" _
(kbArray As KeyboardBytes) As Long[/code]

When prompted name the module ControlCapsLock

Private Sub MemoField_GotFocus()
'Turn Capslock On
GetKeyboardState kbArray
kbArray.kbByte(VK_CAPLOCK) = 1
SetKeyboardState kbArray[/code]
End Sub

Private Sub MemoField_LostFocus()
'Turn Capslock OFF
GetKeyboardState kbArray
kbArray.kbByte(VK_CAPLOCK) = 0
SetKeyboardState kbArray[/code]
End Sub

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

Answers/posts based on Access 2000

Message posted via AccessMonster.com

 

[Don Barton]

Well, you are correct that using something in the Format of the memo does
cause only the first 255 characters to display. If you want a source to
quote, see:
Truncation of Memo fields
at:
http://allenbrowne.com/ser-63.html

This has been the case in all versions of Access. If you really need the
field to be converted to upper case, use the AfterUpdate event procedure of
the text box to convert it to upper case. It is then stored that way, and
does not need to be formatted each time it is retrieved. (For existing data,
use an Update query to convert it to upper case.)

Hi Allen,
Appreciate your response, and verifying my conclusion. I discovered
this the hard way. The client who brought this to my attention is a
hospital laboratory. When tests are entered they should not
dissappear, which in this case they did. Does MS consider this a
bug? Your article felt like it made good sense, which it does, as
long as we're aware of the limitation (and the work around). Your
documentation of the situation was very helpful, and thanks for your
support of the Access Dev Community. This is one of the situation you
would never discover (the database in question has been in use for 6
years) unless it actually happens.

Don

 

[Don Barton]

I actually had the opposite problem; client wanted everything in the db in
caps EXCEPT the narrations in the memo fields! Found this hack somewhere a
while ago; don't remember where. It turns the CapsLock On and Off.

In a new module place this code:

'Windows API/Global Declarations for :CapLock
'*********************************************

Thanks missinglinq for the code and suggestion, as you say, there is
more than one way to skin a cat!
db

 

[missinglinq via AccessMonster.com]

"Does MS consider this abug?"

The answer would have to be "No!" since it's been around since day one and
they've never addressed it! M$ expects the memo field to be used for
memos/narrations/notes and nothing else. They don't expect it to be used to
store data that will later be manipulated, which is where most developers run
into problems with it. Like the gentleman (I believe he posted here, actually)
who insisted on keeping entire mailing addresses in the memo field, then was
amazed when there was no practical way to parse each and every element of the
address out of the field! Youjust have to use the field as it was intended to
be used! BTW, I usually post a link to Allen's site when people are having
trouble with memos.

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

Answers/posts based on Access 2000

Message posted via AccessMonster.com