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

Auto save. Records are saved witn no need to press save record

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

    Auto save. Records are saved witn no need to press save record

    Records are saved without pressing "save record".

    For most part is good, but in cases where by accident a field is erased or changed part of the data, It gets saved.

    To prevent saving blank records I have this code on every table field definition:
    on record event cansaverecord

    t=table.current()
    if t.xxxx = ""
    cancel()
    end if

    Where xxxx is the field name important in that table.

    Is there a way to force the user to save the record upon changes?
    No matter which field is entered or altered.

    #2
    Re: Auto save. Records are saved witn no need to press save record

    Bit of an issue here Mike with multiple "saves".
    One way is to look at all fields when departing the form, and trap the errors and ask for confirmation at that point.
    What I've done in tne past is to put a Conditional Object beside the fields, usually containing a red ball when ther is an error situation. That way, the errors are trapped as they occur.
    See our Hybrid Option here;
    https://hybridapps.example-software.com/


    Apologies to anyone I haven't managed to upset yet.
    You are held in a queue and I will get to you soon.

    Comment


      #3
      Re: Auto save. Records are saved witn no need to press save record

      I put a script on the form's Can Save event so the user can choose.

      tbl = table.current()
      Answer=UI_YES_NO+UI_QUESTION_SYMBOL+UI_SECOND_BUTTON_DEFAULT
      response = ui_msg_box("Please confirm.","This record has been changed."+chr(10)+chr(13)+" Do you want to save it?", Answer)
      IF response = UI_YES_SELECTED THEN 'Yes selected
      tbl.dchanged=date()
      ELSE
      cancel()
      END IF

      Comment


        #4
        Re: Auto save. Records are saved witn no need to press save record

        Thanks for responding Ted and Sandy. If I read you right Ted, are you suggesting to put
        Conditional Object beside the fields
        ?
        That sounds like a monumental task. The problem here is not trapping an error.
        A user accidentally adds a space to a name fields or erases part of it, that is not an error. (I know the person made an error, no the computer program)
        Now in Alpha, exiting after such circumstances, the records gets updated and saved. No questions asked.

        The solution from Sandy seems good, It lets me know that a change was made. But I seem to have a problems with it, because it warms me and ask me, but unless I correct the accident, no matter what I say, yes or not, it saves the changes.
        Is there more to the code?

        Comment


          #5
          Re: Auto save. Records are saved witn no need to press save record

          Mike, Sandy's code is correct. Describe where you re placing the code.

          Otherwise have you considered having the form not default to edit mode. User can click around harmlessly but must purposely elect to edit before allowing changes.

          Comment


            #6
            Re: Auto save. Records are saved witn no need to press save record

            Problem is that users don't check, just click through Sandy in my experience.
            How many fields Mike?
            See our Hybrid Option here;
            https://hybridapps.example-software.com/


            Apologies to anyone I haven't managed to upset yet.
            You are held in a queue and I will get to you soon.

            Comment


              #7
              Re: Auto save. Records are saved witn no need to press save record

              If you reply "No," you are sent back to the in-process form. <Esc> will remove the unwanted changes, but we also have Oops! and Save buttons because why would the casual user know about <Esc>?
              Last edited by Sandy Garrett; 07-21-2013, 12:31 PM.

              Comment


                #8
                Re: Auto save. Records are saved witn no need to press save record

                To Sandy An Ray, Correct I had the code in the table not in the form.
                I did the change, but I get the following
                Script:CanSave line:9
                tbl.dchanged=date()
                Property not found
                tbl.dchanged subelement not found.
                Suggestions or advice, Please?

                Comment


                  #9
                  Re: Auto save. Records are saved witn no need to press save record

                  If the script is running in the form, tell us about the table or set supporting the form.

                  Sandy's code establishes a pointer to the table supporting the form. If you check the help file you'll see that her code points to the parent table if the form is supported by a set of tables. Sounds like you need the pointer to reference a child table, not the parent. Ok?

                  Comment


                    #10
                    Re: Auto save. Records are saved witn no need to press save record

                    Sorry, I should have removed the dchanged reference before posting. We have a dchanged field on all our user forms to track who has changed what where. At the end of the workday we gather up all the changed records to share, and dchanged is how we know what to grab.

                    Except changing a picture doesn't trigger CanSave - which is flat out evil :-(

                    Comment


                      #11
                      Re: Auto save. Records are saved witn no need to press save record

                      Mike, still working on the problem with slowing up.
                      This one. Are you using the Audit feature?
                      Creates a CSV which you can analyse for changes - if you have security configured, or at least user names.
                      See our Hybrid Option here;
                      https://hybridapps.example-software.com/


                      Apologies to anyone I haven't managed to upset yet.
                      You are held in a queue and I will get to you soon.

                      Comment


                        #12
                        Re: Auto save. Records are saved witn no need to press save record

                        The form is based on a table, not a set.
                        I just read that the script reffers to a ddate, an specific field in their system.
                        Of course that will not work on mine.
                        I did not realize it.
                        So the question of tracking changes in the form, seem that she only tracks one field.
                        If that field does not change, any changes on the rest of fields, will not be trapped and if an erroneous data was changed, will be recorded. Am I correct so far?

                        Comment


                          #13
                          Re: Auto save. Records are saved witn no need to press save record

                          Changes in fields are not tracked. Dchanged is written to only when the table is saved through one specific form. The form will not save unless something has changed, so dchanged is written only if there has been a change, iow if the record is "dirty." A5 will not save an unchanged record.

                          Unfortunately changing a picture does not mark the record dirty. I even tried adding a field that was supposed to change when the picture did, but no joy. So the jury is out whether redefining standard English words qualifies as a bug, but at least the documentation is correct.

                          Comment


                            #14
                            Re: Auto save. Records are saved witn no need to press save record

                            Originally posted by MikeData View Post
                            The form is based on a table, not a set.
                            I just read that the script reffers to a ddate, an specific field in their system.
                            Of course that will not work on mine.
                            I did not realize it.
                            So the question of tracking changes in the form, seem that she only tracks one field.
                            If that field does not change, any changes on the rest of fields, will not be trapped and if an erroneous data was changed, will be recorded. Am I correct so far?
                            Just leave off the line with
                            tbl.dchanged=date()
                            . That is the path if user selects (Do you want to save it?) YES, otherwise the changes will be Cancel()ed

                            Comment


                              #15
                              Re: Auto save. Records are saved witn no need to press save record

                              Clever...

                              It works an is clean.
                              It work in exiting the form, go to next record and on "querybyform"
                              It takes a bit or retrain your exiting, going to next record or clicking "querybyform" .

                              It is almost natural.
                              case 1
                              You make a change intentionally, click save, just select exiting, go to next record or click "querybyform": you are asked "save this record? say yes and you are on your way to your clicking.

                              Case 2
                              You make a change accidentally and do not know it, click save, just select exit, go to next record or click "querybyform": you are asked "save this record? say no and you stay in that form.
                              The cancel does not cancel you changes, untill you press ESC or CANCEL CHANGES, then accidental changes are erased.
                              Once you press those keys, you can click select exit, go to next record or click "querybyform" and you go on your way to your clicking.

                              In either case do not save the record, use the above flow. That is why is not natural, as you will tend to save the record, upon changes.
                              I you save it, you still will be asked to save the record again.

                              That is what I got. Am I wrong?

                              Comment

                              Working...
                              X