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

Forcing form calculated fields to refresh

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

    #16
    Re: Forcing form calculated fields to refresh

    I wonder if we're all talking about the same thing?

    In common parlance a "calculated field" in a form layout is a synonym for what the help file now calls a "calculated display value." They are created in a couple of different ways. check this page in the helps. These are never populated by scripts.

    Comment


      #17
      Re: Forcing form calculated fields to refresh

      Tom, I may be new to V11 but I am aware that calculated fields technically refer to table fields. I use that term to refer to "calculated values" out of habit, as do many others. I hope that my so doing is not affecting the answers I'm being given in this thread.

      Comment


        #18
        Re: Forcing form calculated fields to refresh

        Sam,
        Quite obviously it is

        try this in the future

        "when I push a button, a script I have does not do what I thought it should do"
        "a table level calculated field rule is not working correctly"
        "a form calcualted filed is not working properly"
        Cole Custom Programming - Terrell, Texas
        972 524 8714
        [email protected]

        ____________________
        "A young man who is not liberal has no heart, but an old man who is not conservative has no mind." GB Shaw

        Comment


          #19
          Re: Forcing form calculated fields to refresh

          I stand corrected Martin. I'm all for clarity especially in forums and certainly apologize for causing confusion. It's also a bit embarrassing to appear dense just because I wasn't with the semantics. Have a bit of empathy Martin because the last time I worked with Alpha Five in depth a calculated field typically referred to form fields. Of course that was in the last century.

          Comment


            #20
            Re: Forcing form calculated fields to refresh

            Ray, I owe you an explanation. I understand from your example why you would have thought I was setting up a query. Acctually I have a series of calculations defined to the form, two of which use the user entered date field. As I had done back in Alpha V1 I was intent on getting the calculations re-executed with the new date. New to V11 I had numerous syntax problems but today I had a breakthrough and my old technique of writing to a one byte field in the primary table finally worked and the form recalculated. I learned how important it is to write tbl.change_end(.T.) instead of tbl.change.end(.T.)

            You advice re creating a test database of my application is extremely well taken and I know I do myself a disservice by not having one to supply. My major inhibitions are two-fold: 1) My present database weighs around 100+ meg and it will be a lot of work to pare it down and still have it contain enough representative information for people to help me. This is not an excuse for not doing it but a reason for my delay in producing it. 2) This database has much customer sensitive information like credit card info, personal contact info like phone and email. I need to design a reasonable way to protect the privacy of these customers and still provide an acceptable test for the people here in the forum. I'm quite aware Ray of the importance of this if I want the Alphaholics (I like that term a lot) and other good folks at these forums to help me.

            Special thanks to you Ray for your entering several of my threads.

            Best ... Sam

            Comment


              #21
              Re: Forcing form calculated fields to refresh

              Sam, a bit late in that case, I found that this code does posititive refresh on the specific browse
              Code:
              parentform:browse1.Resynch("tentran")
              where the browse name is according to yours with the tablename in quotes

              Comment


                #22
                Re: Forcing form calculated fields to refresh

                Originally posted by Ray in Capetown View Post
                Sam, a bit late in that case, I found that this code does posititive refresh on the specific browse
                Code:
                parentform:browse1.Resynch("tentran")
                where the browse name is according to yours with the tablename in quotes
                Never too late, Ray.

                I tried this approach and couldn't get it to do an immediate refresh. I renamed my first (of two) browse object and used that name in your statement. For the table I wasn't sure what to use so I used the table the browse was based on "inv_head". When that didn't work I used the primary table "customer" and when that didn't work I used the name of the set "analysis".

                I think a poltergeist has invaded this form of mine.

                It seems I've got to make it a priority to pare down my database, cleanse it of sensitive information, and have something to offer those of you willing to help me. It's crystal clear to me that if I supplied this set and form and explained what was wrong, most of you "Alphaholics" would see fairly quickly what's wrong.

                While I have your attention, Ray, since I've never created a test DB, do I just create a new data directory, copy all files to it, give it a different name to A5, pare down and cleanse all the tables, and then zip up everything?

                Thanks for your support Ray and sorry that your routine didn't work for me.

                --- Sam

                Comment


                  #23
                  Re: Forcing form calculated fields to refresh

                  There's no standard. All depends on what your concerns are. If I interpret your scenario the Customer details is what you mention. Suggestion may be
                  1. backup your database and unzip it into a new folder
                  2. load A5 from that folder. Zap the customer folder. add back some fictitious customers using linking fields that match the other tables in the set
                  3. See that your problem replicates, remove unconnected tables and sets.

                  Comment


                    #24
                    Re: Forcing form calculated fields to refresh

                    The max size for an uploaded zip file of your sample database is 5 mb.upload limits.png
                    There can be only one.

                    Comment


                      #25
                      Re: Forcing form calculated fields to refresh

                      Dim tbl as P

                      Tbl = table.open("customers")

                      Tbl.recalc_calcFields()

                      Tbl.close()

                      Comment


                        #26
                        Re: Forcing form calculated fields to refresh

                        That's for table level calculated fields.
                        There can be only one.

                        Comment


                          #27
                          Re: Forcing form calculated fields to refresh

                          Sam, I am having the same issue in one form with calculated values not updating. The calculation is simply adding a few calculated fields from child tables. The child table fields update as expected but the calculated values do not (notice the correct grammar as I would have called them a calculated field as well). Anyway, I built a test table and form a few hours ago and everything works as you would expect it to however I too started my project with version 5 and then it stopped working somewhere along the upgrade path. I added a refresh button on the form and that saved having to leave the form and return back to see the updated calculated values. I also added the same refresh statements to the print report button and everything was okay until I started restructuring my database a couple of weeks ago. I had numerous sets that I built as I added functions to the database and decided I could reduce the clutter if I thought about what I was doing. This created a problem with my print report button as when I do the refresh during the print procedure, the form leaves the record that has focus and focuses on the top record in the embedded browse that is on the form. Anyway, if you get a solution on how to get the calculated value to update, I would be interested in trying it as well.

                          Larry Ternowski

                          Comment


                            #28
                            Re: Forcing form calculated fields to refresh

                            Originally posted by GMLMECH View Post
                            Sam, I am having the same issue in one form with calculated values not updating. The calculation is simply adding a few calculated fields from child tables. The child table fields update as expected but the calculated values do not (notice the correct grammar as I would have called them a calculated field as well). Anyway, I built a test table and form a few hours ago and everything works as you would expect it to however I too started my project with version 5 and then it stopped working somewhere along the upgrade path. I added a refresh button on the form and that saved having to leave the form and return back to see the updated calculated values. I also added the same refresh statements to the print report button and everything was okay until I started restructuring my database a couple of weeks ago. I had numerous sets that I built as I added functions to the database and decided I could reduce the clutter if I thought about what I was doing. This created a problem with my print report button as when I do the refresh during the print procedure, the form leaves the record that has focus and focuses on the top record in the embedded browse that is on the form. Anyway, if you get a solution on how to get the calculated value to update, I would be interested in trying it as well.

                            Larry Ternowski
                            Larry, I honestly do not understand the complications you outline above. If however I can help you by describing my application and how I got the form calculated fields to refresh, I'll plow ahead.

                            Here's my application:
                            A5analysis.jpg

                            The box at the top shows sales from the date of the first invoice to the present. The "Change Since Date Button" sets a new from date for an ad hoc recalculation since that date. This why I need to immediately recalculate the form's calculated fields. This was easy in Alpha Five Version1, as it required changing a field in the current record and that would enable the recalc. In Version 11 I was encouraged to try other techniques to refresh the form and nothing worked. So ... I fell back to what worked for me 16 years ago and it worked again.

                            I'll now upload the script that runs off the PUSH event of the button that changes the date.

                            You'll see some commented out lines in the script where I tested the VIEW status of the form. That test wasn't consistent so I ended up testing the table I was writing to. BTW, the customer record, primary in this set used by the form, has a 1 byte logical field that my routine reverses and writes to the current record.

                            Larry, there are people here who thought I was off my rocker to use my 16 year old solution but everything they advised to force a form recalculation didn't work.

                            Hope this helps you ... Sam
                            Attached Files

                            Comment


                              #29
                              Re: Forcing form calculated fields to refresh

                              I had a long struggle with embedded browse in similar regard.
                              This was where browse level EVENTS were being used to calculate while table field rules and form calculated values were active.
                              Very often a browse event recalc would take a value from the first record visible in the Browse into the row it was on.

                              I resolved it eventually I think, with functions in table field rules replacing the browse event functions. I have had it running for a few days reliably.

                              My suspicion is that resynching of the browse by the form recalcs would place the browse table pointer at the first record while the browse view pointer remained on the row.

                              I hadn't thought of trying viewport at the time.

                              As an afterthought - I read reports here of Alpha having bugs - in complex structures, the test is to create a simpler example. When the bug doesn't appear I know its in that setup. May or not be called a bug in Alpha but its a case of taming the beast - there are so many possible permutations that Alpha allows but no-one could test all in every combination. I again use the word triage. Maybe the method has to be altered.

                              And importantly - only a sample to experiment with could yield answers.
                              Last edited by Ray in Capetown; 10-12-2012, 02:40 AM. Reason: Afterthough

                              Comment


                                #30
                                Re: Forcing form calculated fields to refresh

                                Originally posted by Ray in Capetown View Post
                                I had a long struggle with embedded browse in similar regard.
                                This was where browse level EVENTS were being used to calculate while table field rules and form calculated values were active.
                                Very often a browse event recalc would take a value from the first record visible in the Browse into the row it was on.

                                I resolved it eventually I think, with functions in table field rules replacing the browse event functions. I have had it running for a few days reliably.

                                My suspicion is that resynching of the browse by the form recalcs would place the browse table pointer at the first record while the browse view pointer remained on the row.

                                I hadn't thought of trying viewport at the time.

                                As an afterthought - I read reports here of Alpha having bugs - in complex structures, the test is to create a simpler example. When the bug doesn't appear I know its in that setup. May or not be called a bug in Alpha but its a case of taming the beast - there are so many possible permutations that Alpha allows but no-one could test all in every combination. I again use the word triage. Maybe the method has to be altered.

                                And importantly - only a sample to experiment with could yield answers.
                                I'm fortunate, Ray, that I didn't have browse level events to consider although my form has two imbedded browses. Nonetheless, looking back I can't believe how difficult it was to force a recalculation in my scenario. Some smart people had me testing the view status of the form but that wouldn't work consistently for me. It would show that the form was in change mode when it should not have been. For me what worked was to test the table's status, not the form's. That's when I finally got it working.

                                Thanks ... Sam

                                Comment

                                Working...
                                X