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



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

verifying pre-form data input

  • Filter
  • Time
  • Show
Clear All
new posts

  • verifying pre-form data input

    Ok boys (and girls - - - can't leave them out) here is a nice little challenge for you. This is probably very simple, but it has escaped me. Maybe I need to get some more sleep. Hmmm what is that??? Oh yes . . . that is what I used to do when I was much younger.

    Converting A4 to A5. In A4 I have a script that does all the following for me. It opens a DB, gets key info from client for a lookup key, does xlookup of proper record, verifies proper data entry and give appropriate error message if needed, then updates entry in DB and gets next item from client. This occurs for the 5 items we are checking. These are logicals that will not allow 2 sequential 'false' entries, i.e. last entry was T this entry was F = good, last entry was F this entry was F = NOT good error message, exit script, do not allow further entry

    It then closes that DB, gets info for next key item to verify, open another DB and does xlookup to get the appropriate record, and verifies the field data entered is greater than the current field value. If not, it gives an error message and asks for new data again. It does NOT update the field; this is only to verify the data input is valid prior to opening the DB this data will be used in. This is done again with the next piece of data.

    Once the data entry has been verified I close the DB, I then open and create the new record in a different DB and populate that with the data I have collected, save the data and reopen in change mode. Then the client adds additional data to the form and saves the data.

    Now that A4 method is there, here is what I have tried to do so far in A5. I created a form attached to my 'menu' table with all the data in global variables and the 5 logicals in checkbox format populated with F as default. For all the key values I use the 'exist' xbasic command to verify I have a good key. Field1 is the lookup key to check the logicals, Field2 is the lookup key to verify the data in Field3, and Field4 is the key to lookup to verify the data in Field5. I also have a Button object on the form that they will push after data verification has been done. I have set the variable 'datagood' to F as default and the button will not execute if that is still false. I also have an 'Abort' button that will cancel this form and the data.

    So here is my problem, how do I fetch the appropriate record based on the key provided to verify the data? And second, what is the best way to display the error messages that are generated if the data is not valid?

  • #2
    RE: verifying pre-form data input

    Don, you've got me thoroughly confused (key issues have an asterisk)...

    - It opens a DB,
    (now called a table)
    * gets key info from client for a lookup key,
    Does "client" mean the person using the computer (user) or is this from a client table somewhere?
    - does xlookup of proper record,
    If a user input a value then I assume this value is used as the key value to verify that it is a valid key.
    * verifies proper data entry and give appropriate error message if needed,
    What data entry? Is this just a reference to the Xlookup verifying a valid value?
    - then updates entry in DB and gets next item from client.
    Updates what entry in DB? If the input (from "client"?) was to a global variable is this value put in a table somewhere? If so, which table - the only table referred to previously was the one mentioned in Xlookup.

    Finally, why go through all this bother? It seems easier to me to just create a field validation that says the value must exist in a table and then have it pop up the list if the input value is wrong.


    • #3
      RE: verifying pre-form data input


      If you can just sketch out the line of execution you need to take that might be more instructive than your own admirable conversion efforts.

      I'd start with any one of three ways to get the data into Alpha. Push a button which runs a line of Xbasic code that requests data by Dialog Box or even a ui_get_text box. This avoids opening a table, you can retrieve the keys and compare the entry values independently of the table lookup values if you want. Lookups are still possible if you want them.
      If you open a table for a lookup, Alpha makes it possible to grab the a_field_value entry with the CanWriteField event and test this before it gets into the table, so you could control the lookup entry this way.
      As you can see, Xbasic can do this task in a few ways and its more flexible than Alpha Four was. Try using your imagination.



      • #4
        RE: verifying pre-form data input

        I, too, am having trouble following the event sequence, but I might try supplying some generic code for what you appear to want.

        The below listed Code will find and display your "formname" based on your "tablename" using the "indexname" you created on "keyvalue" for the table; or it will display an appropriate message if "keyvalue" is not found.

        (Of course, it does assume that the user is a network administrator of a faith based institution; if that's not the case, you may want to change the "msg" to something more of your liking.

        if exist(keyvalue,"tablename","indexname")
        f = form.load("formname")
        title = "Error"
        code = ui_ok + ui_stop
        msg = "That key doesn't exist, you moron." +chr(13)+chr(10) +"Clean out your desk and get off the premises. Your FIRED." +chr(13)+chr(10) +"And, by the way, don't change your password" +chr(13)+chr(10) + "or we'll have you excommunicated."
        end if


        • #5
          RE: verifying pre-form data input


          Following your religious nature...
          That's "ui_stopsymbol you moron. Consider yourself excommunicated.

          (Sorry, I couldn't resist the temptation.)


          • #6
            RE: verifying pre-form data input

            Oops! That's ui_stop_symbol. I guess this means I now have to excommunicate myself.


            • #7
              RE: verifying pre-form data input

              What the hell....we'll start our own religion.


              • #8
                RE: verifying pre-form data input

                How about "Orthodox Druid - Reformed"? That's always sounded good to me.


                • #9
                  RE: verifying pre-form data input

                  "Orthodox - Reformed"?

                  Sounds like a Baptist minister who showed up for happy hour.....sounds OK to me.....


                  • #10
                    RE: verifying pre-form data input-->Appendium

                    Ok guys for those that love coding attached is the A4 script that i have to do the things needed to collect the information and post it to the proper files. This is a trucking company who has drivers, trailer, and tractors that must have data updated in order to settle with thier drivers for the loads they hauled.

                    get driver # and verify
                    get tractor # and verify odometer greater than last entry
                    get trailer # and verify reeferhours greater than last entry
                    get driver record
                    user enters answers to 5 T/F questions
                    (abort if last and current question answer were F
                    if last answer was T or F and current answer is T update file)
                    user enters Y/N to 5 types of service questions
                    if N answer go to next question, if Y get appropriate info for file

                    after all info entered, now open and populate the 'settle' DB (in A4 or table in A5)


                    • #11
                      RE: verifying pre-form data input

                      hmmmmmmm client looks at error message, and contemplates for 30 seconds, reaches for phone, dials number, "hello . . . . YOU are fired", hangs up phone and smiles. Now I do not have to worry about problem. Think I will modify error message just a LITTLE.

                      hehehe oh well BTW there is no form for this inquiry, only used dialog boxes then updated of the file IF needed. Please see the A4 script I added to clarify my problem (appendium to this thread) I should have done that to start off with. once the data is collected then I open a form and populate it.

                      Thank you all for your input BTW it has been both entertaining and instructional ( I like the entertaining part best tho) Orthodox reformed druid hmmmmmmm


                      • #12
                        RE: verifying pre-form data input

                        you are looking at the A4 section that explains what i did in A4.

                        my problem is in A5 at the end of the tirate.

                        Thanx tho