Forcing Caps Lock On 1

[bpitche]

Is there any way to use code to turn caps lock on if it is not already on? I am trying to keep consistency in the data entered in the database. I need it to be entered in all caps and stored in all caps. The ">" format does not store it in the tables as all caps, it just makes it appear all caps.


Thanks in advance,
Brad Pitcher
The Hoover Company
bpitcher@hoover.com
Brad Pitcher
The Hoover Company
bpitcher@hoover.com

 

[THoey]

I am not sure how to turn the CAPSLOCK on, you might try looking up the SENDKEY function. But, you can add the ">" format character to the field on the table, not just on the forms, and it will store the data as capitals.

Hope that helps... Terry M. Hoey
th3856@txmail.sbc.com
While I don't mind e-mail messages, please post all questions in these forums for the benefit of all members.

 

[mickeyg]

Brad,

I think there is an upper() that may help you. Place that function in the AfterUpdate event of your form widget.

Just a thought,
Mickey

 

[Terpsfan]

I've found this code snippet to be useful for forcing CAPS. The great thing about it is that it capitalizes everything on the table side as well. Just substitute your field names as needed. It works whether the user has caps lock on or off.

Private Sub ProductName_LostFocus()
Dim Uppercase As String
Uppercase = UCase([ProductName])
ProductName = Uppercase
End Sub

 

[rhicks]

Place the following code into a new module:

'*********************************************
'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

Now place the code below into the form that open first when the db opens:

Private Function CapLock() As Integer
CapLock = GetKeyState(VK_CAPLOCK) And 1 = 1
End Function

Private Sub Form_Load()
GetKeyboardState kbArray
kbArray.kbByte(VK_CAPLOCK) = 1
SetKeyboardState kbArray
End Sub

When the form loads the CapLocks will be turned on.

HTH
RDH Ricky Hicks

 

[ghubbell]

Hi Brad,
I've been contemplating this all day and all I'd like to add to all the fine ideas is "why do you care"? The tables are yours and any data from them should be viewed or manipulated through a form or on a report or a query. All of which your > Format would control. I'll guess you have a very specific reason for this that I just don't understand...

By the way, It is now common to preceive words written in uppercase to be as though someone is yelling or speaking with a strong tone. The tremendous variety of fonts available to users today can actually range from offending to soothing. You would be very surprised how a little difference like this can affect a persons day....

Food for thought?

Gord
ghubbell@total.net

 

[THoey]

Gord, I can see having them all caps if the person who wants to see the forms/reports likes all of the data to be consistant. If you ensure that all the data in the tables is already that way, you don't have to run a function like UCASE() on each field on the forms or reports. And probably the easiest ways to enforce this is at the data storage level, the table itself...

BTW, I myself prefer proper case, but that only works with names, not very good with stock numbers (Tzae1234)... Terry M. Hoey
th3856@txmail.sbc.com
While I don't mind e-mail messages, please post all questions in these forums for the benefit of all members.

 

[ghubbell]

Thanks and point taken Terry, however > in the Format property, not the inputmask property (which by the way if set to all of the tables "unoccupied" fields Format properties will be inherited by any new fields on a form or report), would give the same visual result, and not have to call a function. Gord
ghubbell@total.net

 

[THoey]

I like the idea of the unused fields being preoccupied with the ">". I don't know how many times I have added a new field, forgot the format and ended up going back, fixing the data and the table format.

Other than that, I think we are both saying the same thing... Terry M. Hoey
th3856@txmail.sbc.com
While I don't mind e-mail messages, please post all questions in these forums for the benefit of all members.

 

[ghubbell]

Yes! Ditto to what Terry said! (are you getting tired of me doing that!) LOL Gord
ghubbell@total.net

 

[bpitche]

Thank you rhicks. It worked perfectly and I appreciate it very much. All of the users know that they should be using caps for consistency, but it helps them if the caps lock is turned on automatically. I used the ">" for the field on the form and the table, but it still stored it in lowercase. I ran a report and all of the data that I entered displayed in lowercase. But anyways, this should work perfectly.

Thanks again, Brad Pitcher
The Hoover Company
bpitcher@hoover.com

 

[Darrylles]

Hi,

Gord - the > in the format propery only affects the content after leaving the field. The user sees lowercase as they type - forced ucase entry is a common requirement by many Tek-Tips visitors.

> can be used on the field in a table but doesn't help unbound fields.

Regards,

Darrylle "Never argue with an idiot, he'll bring you down to his level - then beat you with experience."

 

[danvlas]

Why not setting the input mask of text fields in the table(s) to
>CCCCC...C (number of "C"s depending on the field size) ?

That would do the trick...