Alpha Software Mobile Development Tools:   Alpha Anywhere    |   Alpha TransForm subscribe to our YouTube Channel  Follow Us on LinkedIn  Follow Us on Twitter  Follow Us on Facebook

Announcement

Collapse

The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic


Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.


If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.


Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.



Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

Field Rules vs. Form Masks and code

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    Comment


      #3
      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-06-2006, 11:51 PM.
      Jim

      Comment


        #4
        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.

        Comment


          #5
          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

          Comment


            #6
            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, 01:50 AM.

            Comment


              #7
              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.

              Comment


                #8
                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

                Comment


                  #9
                  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

                  Comment


                    #10
                    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 [email protected].

                    Comment


                      #11
                      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

                      Comment

                      Working...
                      X