Alpha Video Training
Results 1 to 11 of 11

Thread: Field Rules vs. Form Masks and code

  1. #1
    Member
    Real Name
    Richard James
    Join Date
    Jun 2004
    Location
    Atlanta, Ga.
    Posts
    226

    Default Field Rules vs. Form Masks and code

    (I'm not sure if this is the appropriate forum, so feel free to move this elsewhere if it is not.)

    To All --

    When is it better to use field rules and when is it better to put a mask or conversion function on a form?

    Suppose, for example that I wanted to capitalize all last names as they are entered. Would it be better to do this on the form when that name is entered, or in a field rule? If I were to change an existing application with old data using field rules and then restore to a different set of data, would the new field rules be implemented with the restore of the application to the new data?

    -- Dick James

  2. #2
    "Certified" Alphaholic MoGrace's Avatar
    Real Name
    Robin
    Join Date
    Mar 2006
    Location
    Los Angeles
    Posts
    3,696

    Default

    Hi,
    The main difference I see in whether to use a field rule for formatting or leave it to the layout is that the field rule is global in scope. That is it will ALWAYS capitalize. So when you want something to always happen a particular way, then use the field rule. Check out the Help on Re-evaluating Field Rules to see which rules will update your data.
    Robin

    Discernment is not needed in things that differ, but in those things that appear to be the same. - Miles Sanford

  3. #3
    Member
    Real Name
    Jose Manuel Atienza
    Join Date
    Mar 2006
    Location
    Philippines
    Posts
    278

    Default

    Hello, Dick. I think this thread more properly belongs in one of the Alpha Five forums, since masks and data transformations are really Alpha Five features, not a database design issue.

    Aside from using a mask, there is another way to ensure capitalized data entries, and that is by using a data transformation field rule. The difference between the two is that a mask forces the user to choose upper or lower case before keying in a letter, so he is entering data in the desired case from the get-go. A transformation field rule, however, takes any combination of upper and lower case letters the user may enter and transforms it afterward into the capitalization pattern set by the field rule.

    The transformation field rule deals mainly with transforming upper to lower case and vice versa. It cannot determine whether there should be a character, a numeral, or a symbol at a particular place on the data string. That's what a mask is for. A mask can therefore provide you with greater control over what the user enters. (Although it might slow down your data entry, especially with a sloppy typist!)
    Last edited by jmatienza; 06-07-2006 at 12:51 AM.
    Jim

  4. #4
    "Certified" Alphaholic
    Real Name
    Cal Locklin
    Join Date
    Mar 2000
    Location
    S.E. Michigan
    Posts
    5,763

    Default

    I'm going to differ with Jim (Jose?). I think this does belong here since the general question applies to all versions and, in fact, doesn't even have to do with any specific command.

    My general opinion is: If the built-in field rule works, use it. If not, use something else.

    Masks are OK but I often find there are too many limitations. Personally, I would try to avoid using a mask that forced the user to type an upper case letter - I don't mind forcing the result to be upper case but I don't want to force the user to press the Shift key before typing the letter. Even for time entry in the format NN:NN, I prefer to use a CanWrite event. That way the user can just type 9 then press enter and the function can convert it to 09:00 - saves 3 keystrokes. Or, "810" would get converted to 08:10 - saves only 1 keystroke but multiply it by 200 orders a day and it starts to add up. For people who do a lot of data entry, these types of 'shortcuts' make a big difference.

    Regarding the specific example of capitalizing names (remember, this was just an example), I usually prefer to use a function in the CanWrite event of the field rules. Otherwise, I dare you to get the correct capitalization for McDonalds, O'Leary, etc.

    If you want this type of control over names, see my article on the Learn Alpha site called Improved Capitalization Checker. I've been using this for years and my customers seem to like it. It will also take something like "abc tool and die company" and make it "ABC Tool and Die Company". Try to get that with "First cap" or "Lower and first cap". I suppose you could build a function for "First word all caps, second word low and first cap, third word lower, all the rest low and first" but that wouldn't be very generic.

    The CanWrite event with my function would be:
    A_field_value = check_caps( A_field_value )

    FYI, the "time" logic:
    If an entry is 1 number, assume it is an hour that needs to be padded with a leading zero. If it's two digits starting with 0, 1, or 2, assume it is an hour and just add "00" for the minutes. If it is three digits, assume it is an hour and minutes but pad it with a zero at the beginning. If it's four digits - well, you can figure that one out. If the result creates an hour greater than 24 (or 12 depending on what you want) or a minute greater than 60, the function will show an error and tell the user to correct the entry.

  5. #5
    Member
    Real Name
    Jose Manuel Atienza
    Join Date
    Mar 2006
    Location
    Philippines
    Posts
    278

    Default

    Hello, Cal! Great to hear from you. Your post was well thought out and extremely educational (as usual). I think I have to look into your Improved Capitalization Checker. It sounds like something I'll find extremely useful down the road.

    I was named after both my grandfathers, but calling me "Jose Manuel" on this message board is a bit much. So you can call me Jim.

    About the appropriate location for this thread, with all due respect, I think that this forum deals with (or should deal with) table and set design and related issues like normalization. These are critical issues that are independent of database computing but are often overlooked in the mad scramble to learn Alpha Five.

    The other forums on this board are focused mostly on data entry issues (like this thread), layout design issues, networking issues, etc, assuming that the user has his database design fundamentals (as defined above) nailed. Unfortunately, for newbies like me this assumption is rarely the case.

    I needed a forum like this when I bought Alpha Five. As it is, I've learned many things about database design on this message board, but it required a lot of searching and sifting since the threads were not on one forum. I also had to go out of this site to learn a lot of other things. If this forum ever takes off, it has the potential to round out this message board and be another valuable resource to users.

    One more thing. This forum is buried near the very bottom of the message board. Don't you think this forum deserves more prominent billing?
    Jim

  6. #6
    "Certified" Alphaholic
    Real Name
    Cal Locklin
    Join Date
    Mar 2000
    Location
    S.E. Michigan
    Posts
    5,763

    Default

    Quote Originally Posted by jmatienza
    Don't you think this forum deserves more prominent billing?
    Yes, I do. Of course, I also think the AlphaBay should be more prominent and it's virtually hidden.

    As to whether or not this specific thread belongs here, I guess what belongs or doesn't is a rather gray area. Personally, I think the title should be Database/Application Design. After all, neither of these is specific to any one version of A5. I think restricting this to just set design (relationships) and normalization is too limiting. Besides there is plenty of info on normalization available just by doing a quick search on the internet. I've provided links to some of them in the past. If people would just spend 1 hour doing searching and reading, they would learn more than they needed about normalization. Heck, half an hour should be plenty. And, once you've become comfortable with the basics of normalization, set design becomes a no-brainer (well, almost). Of course, they'd still have to go through some trial and error like the rest of us before they were comfortable setting up their own tables and relationships. Until someone comes up with a true "brain transfer" machine, experience will still be the best educator. Training, reading, schooling just gives us the initial experience so we don't stumble quite as much trying to get through the rest.

    I'd also like to see discussions on:
    - form design in terms of size, color usage, buttons, OnKey usage, tab usage, and anything else that affects the ease of use. (Not "how to" but "when to" and "why to" These should be accompanied with good reasons -not just "because I like to do it this way" but something like "my users find it faster/easier because .......")
    - naming conventions because that would make it easier for someone else to handle an application if the current developer leaves, quits, etc. (I have proposed my own a number of times, with a rationale, but they seem to get little attention. I can only guess that they are too complicated for some or people don't like them because my they don't take advantage of the ability to assign long names to fields and indexes.)
    - Advantages of maximized vs. windowed forms. Again, not just "I like" but "this method provides this advantage in this situation." I almost always use maximized forms (not necessarily a maximized A5 window) but keep thinking there may be situations where windowed would work better but I just don't have the experience with them.
    - Comments in scripts - when to add them, perhaps even some 'standard' for setting them up such as adding some number of asterisks to denote various 'levels' of comments (i.e., "this relates to a whole section of the code" vs. "this relates to the next line or two"). This is something I've played with but never come up with anything I consider satisfactory.
    - I'm not sure how best to describe this so I'll just do the best I can.... I'd like to see at least the more professional developers set up some standards for "documentation" so that someone else could take over if something happens to them. For example, I have a list of all passwords for all applications that I keep in my office and my wife knows about it as well as one other developer. So, if we happen to get hit by a truck while driving to dinner tomorrow, someone will know where to find the passwords for all my apps. However, additional documentation needs to be done - things like the 'normal' documentation of how the app works, a list of contact people for each app, where to find the apps on my computer and how to tell which is the 'real' app vs. a test or development app. If anyone has actually had to go through such a situation, perhaps there are other things to consider also.

    And, anything else that relates to general database/application design as long as it is backed up with some reason rather than just "because". Once the reasons are available, people can make better choices. They may find that one set of reasons don't apply to their situation but a slight modification, or a combination with someone else's ideas, will make their own app work much better.

    Note also that I said "reasons", plural, because I would hope that various ideas are presented for any subject so that people can take the best of each depending on their own needs.

    Another key factor will be tolerance for other's ideas. That seems to be generally quite good on the A5 boards but this is one area where a lot will be a matter of opinion. Some will see the reasons that are presented as valid and others will think they are not. That's ok - we don't all have to agree as long as we respect the other people's opinions.
    Last edited by CALocklin; 06-12-2006 at 02:50 AM.

  7. #7
    "Certified" Alphaholic
    Real Name
    Cal Locklin
    Join Date
    Mar 2000
    Location
    S.E. Michigan
    Posts
    5,763

    Default

    I just tried the LearnAlpha site and discovered that the link to my Improved Capitalization routine isn't working. I'll try to update it and put a link to it on my own site. I have made a few improvements since it was initially released.

  8. #8
    Member
    Real Name
    Jose Manuel Atienza
    Join Date
    Mar 2006
    Location
    Philippines
    Posts
    278

    Default

    Your proposed renaming of this forum as the "Database/Application Design Forum" cleared up your position for me. On second thought, I agree with you that restricting the subject of this forum to tables and sets would be too limiting. It's too lonely as it is.
    Jim

  9. #9
    "Certified" Alphaholic
    Real Name
    Jeff Kletrovets
    Join Date
    Oct 2005
    Location
    Columbus, OH
    Posts
    1,135

    Default

    Greetings Cal

    I would be interested in using your improved capitalization checker if you would be kind enough to share it with the community once again. I tried getting it from LearnAlpha as well. I didn't see it on your site yet - perhaps I missed it?

    Regards,

    Jeff

  10. #10
    "Certified" Alphaholic
    Real Name
    Cal Locklin
    Join Date
    Mar 2000
    Location
    S.E. Michigan
    Posts
    5,763

    Default

    Quote Originally Posted by jkletrovets
    Greetings Cal

    I would be interested in using your improved capitalization checker if you would be kind enough to share it with the community once again. I tried getting it from LearnAlpha as well. I didn't see it on your site yet - perhaps I missed it?

    Regards,

    Jeff
    No. You didn't miss it. I've been busy with paying customers and "spring/summer issues" like mowing the lawn (2 acres), fixing the barn trim that's falling off, etc.

    Anyone who reads this and wants to be notified when it's done, send me your regular e-mail address and I'll put it on a "notification list". You can send the e-mail to Cal@aimsdc.net.

  11. #11
    Member smrogers's Avatar
    Real Name
    Shawn Rogers
    Join Date
    Feb 2006
    Location
    Reading, MA / 15 Miles North of Boston
    Posts
    516

    Default Re: Field Rules vs. Form Masks and code

    Hi,

    I was looking for your capitalization checker, but couldn't find it using your link -- could you tell me the date you posted that article? Thanks

Similar Threads

  1. Error in field rules or form
    By wcoole in forum Alpha Five Version 6
    Replies: 2
    Last Post: 07-14-2005, 09:05 AM
  2. Changing field rules via code ??
    By Jason Edwards in forum Alpha Five Version 6
    Replies: 3
    Last Post: 04-04-2005, 05:29 AM
  3. Tabbed Form with Field Rules
    By Bruce Roberson in forum Alpha Five Version 4
    Replies: 2
    Last Post: 11-18-2004, 04:22 PM
  4. Field Rules Not Applying in Form
    By djones092 in forum Alpha Five Version 5
    Replies: 4
    Last Post: 08-30-2003, 05:10 AM
  5. Open Code editor under field rules
    By Gman in forum Alpha Five Version 5
    Replies: 6
    Last Post: 01-02-2003, 12:17 PM

Bookmarks

Posting Permissions

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