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

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

    Calculated Fields on Forms

    I want to place a calculated field on a form. I calculated this field at the set level and then (in trying to debug) at the database level. Every time I try to place the field on the form, A5 crashes, telling me I have perfomed an illegal function. (If I calculate the field only at the form level, it works.) What's up, and what can I do? I need to use the calculated figure in several places throughout the database, which is why I want it at the set level.

    Roy

    #2
    RE: Calculated Fields on Forms

    Without seeing the calculation it's hard to say. Remember you can define a variable for a form, make it global, let the user enter a value for the variable, or a value to be used in your calculation, in a calculated field --- it will then be available anywhere in your application until exiting.

    Could you be more specific as to what you want to do?
    There can be only one.

    Comment


      #3
      RE: Calculated Fields on Forms

      Nothing fancy. I just want to display on my form the last five years worth of contributions, but I want to do so with a calculated field.

      All past contributions are stored in the History.dbf. The history database contains Pledge1991 through Pledge2000 for each donor. I want the form I am trying to design to display the last five years of data, but want it universal enough that when I roll over the campaign next year, I will not have to change each field on the form to update it for a later year.

      For the current years form, I want Pledge1995 through Pledge1999 displayed. I have a global variable called CurYear (current year) which has the string value of 2000 (next year, to rollover the campaigh, I want to change only this variable, to 2001).

      This is the formula I wrote for the calculated fields inside the History.dbf. When I press the evaluate button, the proper values display at the bottom of the expression building screen (so I know the language is correct):

      Plg_PY1 =eval("History->Pledge"+ltrim(str(val(Var->CurYear)-1)))
      . . .
      Plg_PY1 =eval("History->Pledge"+ltrim(str(val(Var->CurYear)-5)))

      So, armed with correctly evaluating calculated fields, it's on to the form. When I try to drag the calculated variable Plg_PY1 onto the form, Alph5 crashes. Every time. At exact same moment. Its seems that I am not able to place a calculated field onto a form, even though the calculated field is made available to me in the drag and drop field listings.

      I hope I was descriptive enough.

      Roy

      Comment


        #4
        RE: Calculated Fields on Forms

        The good news:

        I can verify the program behaviour you have experienced.

        The bad news:

        I don't know why.

        In the application experience I have we use three year tracking on most history. We have fields for

        data current year
        dataly last year
        datapy previous year

        and we have operations to archive the datapy information, move the dataly info to datapy fields, move the current data to the dataly fields, clear the current year fields for use. You might consider a similar approach if we can't find another solution.
        There can be only one.

        Comment


          #5
          RE: Calculated Fields on Forms

          Stan,

          Actually, that's exactly what I have been doing today, with only a slight variation. It's still elegant, but I'd rather not have to have that additional table. But, thankfully, HDD memory is cheap.

          Thanks.

          Comment


            #6
            RE: Calculated Fields on Forms

            PMFJI, but do you get the same behavior if you use separate names for each of the five calculated fields?

            -- tom

            Comment


              #7
              RE: Calculated Fields on Forms

              Instead of the complex
              eval("History->Pledge"+ltrim(str(val(Var->CurYear)-1)))
              through -5, I had also tried
              Plg_PY1 = History->Pledge99
              Plg_PY2 = History->Pledge98
              . . .
              Plg_PY5 = History->Pledge95

              and resigned myself to updating the variable assignments by hand once a year. Even these didn't work (indicating its not the complexity of the formula that is at work against me here).

              There was a mistake in my earlier post (my #2). The third line of my sample code (representing the 5th variable) should have been Plg_PY5, not Plg_PY1 (the latter being the variable name for the 1st variable). I really did assign unique variables for each line. (Tom, that may have been your real question. My apologies to anyone else who may have been working on this question for the error.)

              (Tom--PMFJI?? this is a new one for me)

              Roy Lasris

              Comment


                #8
                RE: Calculated Fields on Forms

                Pardon me for jumping in (PMFJI)
                There can be only one.

                Comment


                  #9
                  RE: Calculated Fields on Forms

                  BINGO. (as in Bingo!)

                  -- tom

                  Comment


                    #10
                    RE: Calculated Fields on Forms

                    Is it possible having the same field defined twice (once in the parent table of the set, and once in the child table of the set) is causing the difficulty? I'd look for ways to simplify this.

                    Also, I'd verify that it's possible to drop *any* newly defined calculated field where you are trying.

                    It may be time for you to zip up a sample pack and show it to us.

                    -- tom

                    Comment


                      #11
                      RE: Calculated Fields on Forms

                      But I'm NOT getting older.

                      Comment

                      Working...
                      X