Input Masks

[jlgray0127]

Good Morning!
I have a form, where I am entering information. I need to insure, CAPS are used in this database, for everthing.
I tried the below Module I found on line, but can not seem to get it to work.

Can someone help me out? I'm not very familiar with modules, so am unsure of how this is supposed to be written, nor what to put in the keypress event on the fields in the form where needed.

Thanks

I was putting in Keypress, ConvertToCaps KeyAscii as was instructed. but Access says it doesn't know the macro, group, etc... not sure. It's name is saved as mdlTextStuff, but I didn't think that mattered. The code is below. Thanks, again!




Public Sub ConvertToCaps(KeyAscii As Integer)
' Converts text typed into control to upper case

Dim strCharacter As String

' Convert ANSI value to character string.
strCharacter = Chr(KeyAscii)
' Convert character to upper case, then to ANSI value.
KeyAscii = Asc(UCase(strCharacter))

End Sub

[lfpm062010]

The instruction is to put the subroutine "ConvertToCaps" in the "On Key Press" Event of your Textbox, Combobox, ..., etc.

http://msdn.microsoft.com/en-us/libr.../ff197089.aspx

Alternative is to use "UCase" function in "After Update" event. "TextBox1" is a text box on form.

Public Sub TextBox1_AfterUpdate()
'Convert to Upper case
Me.TextBox1 = UCase(Me.TextBox1)
End Sub

[Dal Jeanis]

I'd tend to do the second method, posted by lfpm062010. You don't want to be interrupting the user's every keystroke with a translation, which will slow down data entry a bit, and look a little "flickery", so translating the whole item to upper case afterwards, once, is preferable.

Technically, it should probably be in the "BeforeUpdate" event, since in theory you should be checking the data and fixing it before allowing it to ever be written to the database, but the AfterUpdate event will have the same effect, albeit with two physical writes to the record, one before, and one after the translation. If you had a thousand people banging on the application, and needed to squeeze every millisecond out of the process, then you'd do "BeforeUpdate".

And you'd write the application in something other than Access.

[Missinglinq]

...I'd tend to do the second method...

I agree with that, for the stated reason.

...Technically, it should probably be in the "BeforeUpdate" event...

Can't do that; the Access Gnomes have fits if you try to change a Control's Value in its BeforeUpdate event, even if you're simply changing the Case of the Value.

Linq ;0)>