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
Devcon 2020 Goes Virtual! LEARN MORE >

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

Variable Scope and Calc fields in a sub-browse

Collapse
X
Collapse
 
  • Page of 1
  • Filter
  • Time
  • Show
Clear All
new posts
Previous template Next
    #1

    Variable Scope and Calc fields in a sub-browse

    Having a great deal of trouble getting data from calculated fields in a line item browse into the parent record...

    That said, I am pretty sure that the parent record cannot see the calc fields from a sub browse used to enter line items.... I think that the calc fields are local vars...

    I have dimmed a complete set of global vars to match the calc fields -- variations on names (of course) :D Hoping to transfer the calc data to the global vars and then into the record fields... Not much success -- yet..

    My question is : Does it do any good to dim a bunch variables as shared that have the same names as the calculated fields....?? Or does this cause more problems.. ??
    My hope here is that the shared vars would be seen by the parent record.

    For the curious, I need to have item data from the browse in the parent record because much of the data has to be summarized. Putting the data in the parent record reduces the number of records that have to be 'looked at' by about 45%. This due to not having to 'look at' the line item records to get the data. Along about October, it can take from 2 to 5 minutes to 'summarize' data and present it on a modal form.

    As usual, I am open to suggestions that don't require my harming myself!!
    D
    Tags: None
    #2
    Re: Variable Scope and Calc fields in a sub-browse

    Originally posted by dik_coleman View Post
    Having a great deal of trouble getting data from calculated fields in a line item browse into the parent record...

    That said, I am pretty sure that the parent record cannot see the calc fields from a sub browse used to enter line items.... I think that the calc fields are local vars...

    I have dimmed a complete set of global vars to match the calc fields -- variations on names (of course) :D Hoping to transfer the calc data to the global vars and then into the record fields... Not much success -- yet..

    My question is : Does it do any good to dim a bunch variables as shared that have the same names as the calculated fields....?? Or does this cause more problems.. ??
    My hope here is that the shared vars would be seen by the parent record.

    For the curious, I need to have item data from the browse in the parent record because much of the data has to be summarized. Putting the data in the parent record reduces the number of records that have to be 'looked at' by about 45%. This due to not having to 'look at' the line item records to get the data. Along about October, it can take from 2 to 5 minutes to 'summarize' data and present it on a modal form.

    As usual, I am open to suggestions that don't require my harming myself!!
    D
    In general, the contents of fields in a browse on a form are referenced (incomplete addressing) with

    Browseobjectname:Fieldobjectname.value

    I believe this would apply to calculated fields in a browse as well as "real" fields.
    There can be only one.

    Comment

      #3
      Re: Variable Scope and Calc fields in a sub-browse

      Dik:
      Having a great deal of trouble getting data from calculated fields in a line item browse into the parent record.
      Chances are.. you used the calc field name. You should use the column title name instead.

      My question is : Does it do any good to dim a bunch variables as shared that have the same names as the calculated fields....?? Or does this cause more problems.. ??
      No, it doesn't do any good because:
      a-You still have to make the correct reference to the calc field, instead of directly, now you have to make it through a variable and
      b-It will confuse you more than it will confuse alpha and
      c-If you make the correct reference, you won't need them on the first place.

      Comment

        #4
        Re: Variable Scope and Calc fields in a sub-browse

        thanx for the response....
        not quite sure how to use it -- yet -- but I have some ideas
        let you know how it works.
        D

        Comment

          #5
          Re: Variable Scope and Calc fields in a sub-browse

          The syntax:
          parentform:Browse_name:title_name.value

          Comment

            #6
            Re: Variable Scope and Calc fields in a sub-browse

            I am not sure that what I need to accomplish can be done with A5...
            This is not a complaint, just a statement of opinion..
            Sooooooo ............ since I cannot submit zip with data and forms - cuz it's not anywhere near that far done.... I am going to attempt to explain exactly what is needed from a parent record and a series of child records.

            Background:
            there are several 'groups'. they make up a collection of 'conditional lookup tables' which are called by a 'category' choice. As req'd by A5, all tables have identical field names and structure.
            an example of a lookup table is:
            charge--ntxbl--stxbl--slstax
            -30.00--20.00--9.15--0.85
            -35.00--23.00-10.98--1.02
            -40.00--28.00-10.98--1.02 the dashes are just spacers.

            each table is slightly different, some have no 'ntxbl' or non-salestaxable values and therefore, will have sales tax values and some have only ntxbl and no slstax values.

            data entry and the lookup and filling of line item values is not the problem

            data entry into the parent record is not the problem

            data summary from the child record and transfer of data to the parent record IS THE WHOLE PROBLEM....

            I will try to illustrate but it may be ?????? and it IS the worst case scenario. Most parent records will have only one child (line item) entry; some will have two or three that do not mix grp1 and grp2 -- see below.

            After data entry into new record of parent; line items are entered into the following 'matrix':
            Remember that all data after the choice of the category (except days and units) is auto filled from the lookup tables. Ud's are a multiplier for the cost extensions - which contain 'ext' in the name. Two other points -- only grp3 REQUIRES that days be considered -- it's a storage factor -- and grp1 is a combo group that combines a group2 action; so each grp1 entered must also add to the grp2 totals -- and it gets worse -- you can have multiple entries for the same group but with different pricing. This data must also be summarized as a part of the group.

            Here's an example of the line item (child) records contained in one parent record:

            Category-SubCat-Days-Units-UD's-Charge--Ntxbl-Stxbl-Slstax-NText-SText-SText-LineTot
            -Grp1--------------1----2----2----30.00-20.00--9.15--0.85--40.00-18.30--1.70---60.00
            -Grp2--------------1----2----2----15.00--0.00-13.73--1.27---0.00-27.46--2.54---30.00
            -Grp3--------------3----4---12----10.00-10.00--0.00--0.00-120.00--0.00--0.00--120.00
            -Grp4-----SC1-----1----4----4-----7.00--0.00--6.41--0.59---0.00-25.64--2.36---28.00
            -Grp5-----SC2-----1----4----4-----9.00--0.00--8.24--0.76---0.00-32.96--3.04---36.00
            -Grp1--------------1----1----1----32.00--22.00-9.15--0.85--22.00--9.15--0.85---32.00 Line Grand Total: 306.00
            ROW TOTALS----------------------------------------------182.00-113.51--10.49----------------------> 306.00

            OK that's the raw data.... Now here's what I need to get into the parent record------------>
            Total dlrs for NTxbl -- that I got, just total(lineitemtable->lineitemfield,grp->parenttable)
            Total dlrs for Stxbl also OK
            Total dlrs for Sls Tax also OK
            Total dlrs for NTxblExt also OK
            Total dlrs for STxblExt also OK
            Total dlrs for StsTax also OK
            Total dlrs for all lines also OK
            Row chek Dlrs just a calc fld adding up the row total $'s

            Now; I need to get the following values into variables so I can transfer them into parent record fields:
            for grp1: # occurrences = 2, UD's = 3, $NTxbl = 62, $STxbl=0.00, $SlsTax = 0.00, $Total = 92.00
            for grp2: # occ = 3, UD's = 5 (don't forget it's part of grp1), $NTxbl = 0, $STxbl = 54.91, SlsTax = 5.09, $Total = 60.00

            For each group AND FOR EACH SUB GROUP (eg SC1 and SC2) - # occ, #UD's, $Ntxbl, $Stxbl, $SlsTax, $Total
            Even tho some of these #'s are (currently) always zero, the tax law could change and I don't want to have to go back to make changes in the code only in the lookup tables.... ergo total each field....

            I currently have a 'slew' of global vars that mirror all of the calc fields on the set form, but I would really like to eliminate them, AND I can't get them to properly accept the calc data anyway...

            I'm not sure that I am being completely clear, but I hope so...

            The main question is :CAN IT BE DONE?????

            I may not have tried every variation of count() and total() but I'm sure I came close...... along with a multitude of select and case clauses in scripts attached to the save event of the line item.

            Answer = No, new direction
            Answer = Yes, help please....

            That took the better part of an hour and I sincerely hope that I am not overtaxing 'my welcome' with this horrendous reply?????
            D

            Comment

            Previous template Next
            Working...
            X