Results 1 to 8 of 8
  1. #1
    Join Date
    Oct 2007
    Posts
    214

    Question Unanswered: Typing Records in CAPS

    Hi All,

    I want access to automatically enter data (letters) in caps lock even if the caps lock is not on. It is annoying going from caps when I want to enter data in access then taking the caps off to go back to word or something. Can I use a code in my form operations to make the data automatically in caps? I hope this makes sense. Thanks for any help!

  2. #2
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    There are several ways to do it.

    The simplest is to use a Format of >. The result is that the text is always shown in uppercase, but the data itself is stored as typed. That means you have to use the format everywhere you see the field.

    Input Masks can also be used to do the job, but they get ugly and can really annoy the h**l out of users and I don't recommend their use tbh.

    You can also use VBA and the UCase function to force the data to uppercase after it's entered, which is what I would do. The benefit of this is that you only have to deal with it at the data entry screen. It's only a little more complex to do than the format property. To do this one, just make a small VBA BeforeUpdate code for each field you need converted to upper case that says Me.TextBoxName = Ucase(Me.TextBoxName).
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  3. #3
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    format mask I would argue is the better option... users see the capitalisation immediately. I'm a firm believer in keping the display as close in sync with the storage....

    if you haven't designed any forms yet put it in as part of the column (field) definition in the table then every form will pick up that format rule and apply it to the form, but if you have already designed forms then you will need to either delete the old conorl and put in a new one, or just duplicate the format rule (">").

    in essence it doesn't matter whether you apply it in code or as a format rule, unless you use that column in more than one form.... if you only use it once then the vba code is fine, but if you use it in more than one form then use a format rule in the table.
    I'd rather be riding on the Tiger 800 or the Norton

  4. #4
    Join Date
    Oct 2007
    Posts
    214
    Thanks to the both of you! I was able to get this working and it makes my life easier ... funny how something so minor can make work a lot easier.

  5. #5
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    ^ Agreed there!

    Healdem, there is no such thing as a Format Mask. It's either the Format property of > or it's an Input Mask of >aaaaaaaaaa (for a 10 character text field).

    I have to correct you there because you suggest a "format mask" of ">" (suggesting a Format property of >) which "shows the capitalisation immediately" and that it doesn't matter if you do it by code or by "format rule" (suggesting an Input Mask). Very confusing!

    The problem with Input Masks is clicking. When you click in a field that has an Input Mask, the cursor lands mid-mask and the user has to backspace to the beginning of the mask before starting typing. Only Input Masks do that. And yes, I am well aware that the best practice is to TAB to the field (not click) which is fine, but most users just don't do it. It's also instinctual to click in a field when you are about to edit one field of an already saved record that you just navigated to... perhaps like modifying a phone number.
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  6. #6
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    fine format / input mask (it should read as format....)... its a while since I've dabbled in the black arts of Access, especially table design....<feeble excuse> these days what little active development I do in a db field is more PHP/MySQL.<f/eeble excuse>

    the point remains the same .. its better to enforce the rules at table level, than it is at form level.. that way round every time you use the column the form will drag through the formatting from the table.

    At least it used to if my ageing failing memory doesn't lie to me
    I'd rather be riding on the Tiger 800 or the Norton

  7. #7
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    Realise, I meant no offense, I just wanted to clarify for forum visitors

    I am still learning PHP/MySQL development... it's a big "field" (oh dear God, sorry about that) and the more I delve into it, the more I realise I have to learn still. I've done tutorials and such, but I need some experience... and that's the killer for me because I am always too busy coding MS Access databases to have the time to build something from scratch with PHP. I even got stuck at the first hurdle... how do you make a secure login. Some kind of encryption thing got me stuck. I guess I'll get it... in time.
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  8. #8
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    Just my 2 cents....in a few of the customer type db's I had to design which ended up being check-writing db's off of the data, while the user's preferred to NOT see all caps for data entry/retrieval, the checks HAD to be written in all caps. This led to storing the data in non-caps but utilizing the ucase() in the check-writing reports.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •