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

Calculated Fields in Embedded Browse

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

    Calculated Fields in Embedded Browse

    I have a form with an embedded browse... and that embedded browse has two columns which are calculated variables (vs calculated fields).

    When the form is run directly from the control panel... all is well. That is, the calc variables are refreshed in the embedded browse as one would expect based on the form's processing.

    When the form is run via another form... i.e. when the form is opened via a script run on a different form... the calc variables do not refresh, never, not at all... as one would expect.

    There is NO DIFFERENCE, and I mean NO DIFFERENCE, in anything my code, logic, globals being set, or anything like that... to account for the different behavior. The ONLY difference is how the form is opened. That is, 1) opened via the control panel or 2) opened via a script on another form.

    Also, NOTHING, not refresh, refresh_layout, resync, etc., etc., etc. will force the embedded browse to refresh properly... other than to close and re-open form.

    Any ideas... other than me zipping the app so you can verify what I have outlined above?

    Thanks,

    Mike
    "all things should be as simple as possible... but no simpler"

    Mike

    #2
    Re: Calculated Fields in Embedded Browse

    Hi Mike,
    A sample will probably be in order as what you see as no difference, there may actually be one.....do all the events trigger the same when opened via control panel vs script?
    Mike
    __________________________________________
    It is only when we forget all our learning that we begin to know.
    It's not what you look at that matters, it's what you see.
    Henry David Thoreau
    __________________________________________



    Comment


      #3
      Re: Calculated Fields in Embedded Browse

      The ONLY difference is how the form is opened. That is, 1) opened via the control panel or 2) opened via a script on another form.
      When you open via the script on another form you are not using any filtering of the records that eppear on the second form?

      What are the expressions used for the calculated values?
      There can be only one.

      Comment


        #4
        Re: Calculated Fields in Embedded Browse

        Stan... nope, no filter expression is specified when the script opens the form. The calc variables which don't "calc" are:

        Num_Reged = dbsum("registrations","Ses_Rec_Id",Sessions->Rec_Id,"Reg_Count")

        Openings = iif(calc->Num_Reged>0,Sessions->Max_Num-calc->Num_Reged,Sessions->Max_Num)

        Mike... everything seems to happen as expected.

        Thanks guys.
        "all things should be as simple as possible... but no simpler"

        Mike

        Comment


          #5
          Re: Calculated Fields in Embedded Browse

          Michael, I'm surprised it works from the control panel. Since Num_Reged is a column in the browse it must be evaluated for each row in the browse. Each "evaluation" requires Alpha to open another instance of the Registrations table and its index in order to do the calculation. That's a whole lot of disk activity and "figurin". All of which must be completed before the browse object itself is displayed on the form. You then nest the computed results for each row in the calculations defined for the Openings column. Openings will of course fail if the dbsum() computation in Num_Reged is not complete when Alpha tries to compute "Openings". This design is ripe for timing issues over which you have little control.

          I'm curious whether the Registrations or Sessions tables are open in the "calling" form?

          Have you tried "de-nesting" the calc expression for "OPenings"? i.e. restating it without using any other calc display variables. Avoiding the use of nested calc values in other calc variable expressions can sometimes help.

          It may be time to consider storing these computations somewhere and then pulling them from storage instead of computing them on the fly.

          Comment


            #6
            Re: Calculated Fields in Embedded Browse

            Tom... thanks for the reply.

            Our original design was to not have to calc openings "on-the-fly." But, we had issues with 1) an Alpha "post" rule not behaving as we would expect and then 2) an issue with us doing the post ourselves. Those issues revolved around Alpha not consistently posting/adding to a Number_Registered field on the related Session record, each time a Registration record was added.

            D'd if do, D'd if we don't :-)

            For now, the work-around is having the script that calls the Form, close itself after calling the Form. We are then re-opening the calling Form, when the called Form is exited.

            -Mike
            "all things should be as simple as possible... but no simpler"

            Mike

            Comment


              #7
              Re: Calculated Fields in Embedded Browse

              Originally posted by michaelwpayton View Post
              For now, the work-around is having the script that calls the Form, close itself after calling the Form. We are then re-opening the calling Form, when the called Form is exited.
              Mike,

              Does the script open the form as a dialog?
              Peter
              AlphaBase Solutions, LLC

              [email protected]
              https://www.alphabasesolutions.com


              Comment


                #8
                Re: Calculated Fields in Embedded Browse

                Peter... no, not a dialog... this one was just using the simple, default, open form action from an action script.

                We typically do things via code, rather than using AS... so, I checked to see if that made a difference... no such luck... same result using code instead of AS. It has to have something to do with the calling form being open, after it opens the form with the calc variables. But, we (4 of us have looked) are just not seeing it.

                We love A5, but... I have to admit... there are many times when we have to come up with what I consider to be a "work-around." Not a big problem, so long as we continue to be able to find those "work-arounds." And, the fact that we always have found a "work-around," is a tribute to A5. There's not much you can't do with this stuff, even if sometimes you don't know exactly why you may have to do what you have to do :-)

                -Mike
                "all things should be as simple as possible... but no simpler"

                Mike

                Comment


                  #9
                  Re: Calculated Fields in Embedded Browse

                  Those issues revolved around Alpha not consistently posting/adding to a Number_Registered field on the related Session record, each time a Registration record was added
                  Michael if you want to revisit this I would think it would be relatively straight forward. -- tom

                  Comment


                    #10
                    Re: Calculated Fields in Embedded Browse

                    Are both forms based on the same table?
                    Does the form behave normally if opened from the CP while the other form is still open? Or do you have to close the first form?

                    Comment


                      #11
                      Re: Calculated Fields in Embedded Browse

                      Tom...

                      Initially, we had a posting rule setup so that when a Registration record was added, it would add to the Number_Registered field on the related Session record. Thinking that that was working... we calc'd the number of Openings based on the fields on the Session record.

                      Recently, the client told us that the calcs were wrong and... when we checked it out... sure enough, the client was correct. That is, the Number_Registered field had not been kept "in-sync." After working long and hard to figure out why things were out of sync, we finally decided to (for now) calc the number of Openings on the fly, as I have been discussing here.

                      Sooner than later, we will be moving this application to v10... and moving most of it's functionalty to the Web. So, I'm not sure it's worth spending much more time on the posting issue at this point... but thanks for the offer :-)

                      Gabriel...

                      The two forms are not "based on" the same tables, but they do access a couple of the same tables... if that makes any sense to you. At this point, we believe the second form never performs correctly, i.e. refreshes correctly, if the first form is open. That is, it seems to be about the first form being open at all... rather than being about the first form calling the second form.

                      Thanks guys,

                      Mike
                      "all things should be as simple as possible... but no simpler"

                      Mike

                      Comment


                        #12
                        Re: Calculated Fields in Embedded Browse

                        Originally posted by michaelwpayton View Post
                        Gabriel...

                        The two forms are not "based on" the same tables, but they do access a couple of the same tables... if that makes any sense to you. At this point, we believe the second form never performs correctly, i.e. refreshes correctly, if the first form is open. That is, it seems to be about the first form being open at all... rather than being about the first form calling the second form.

                        Thanks guys,

                        Mike
                        Exactly what I was thinking. It is not that the form is opened from the CP vs opened from another form, but rather if the other form remains open it does not work. This is not decipherable without an actual sample..

                        Comment

                        Working...
                        X