9 Replies Latest reply on Aug 10, 2011 7:33 AM by JLAFARGUE

    calculation for new row added

    BLACKBERRY23

      Hi,

       

      I have a table with calculations in it, 2 rows with a subtotal, vat and overall total to add up the cost of each row. I have added a 'add row' button and 'delete row' button but the subtoal, vat and overall total doesnt add up now the new row added!

       

       

      Also when i subform a section so it is flowed underneath the table it magles everything underneath and then wont move to the place it should be?

       

      Does anyone know how to solve these problems.

       

      Mnay Thanks

        • 1. Re: calculation for new row added
          whyisthisme Level 4

          if you name each row and cell the same thing (such as Row1 and NumericField1) then you can do the total calculation as sum(Row1[*].NumericField1); this will then include any new rows because it will just call them Row1[1], Row1[2], etc and that will all be captured with the *.

          • 2. Re: calculation for new row added
            BLACKBERRY23 Level 1

            thanks for the tip, but it didnt work!

            Any more suggestions? on how this can be done?

             

            also why dose everything move when you put them into a 'flowed' subform i can get my document to look right as it moves every thing and doesnt allow you to move them at all.???

             

            Many thanks

            • 3. Re: calculation for new row added
              JLAFARGUE

              I suspect that for your totaling, you are putting the recalculation of the totals in the wrong event. 

               

              Object in a flowed subform move because that's what they do.  They are postioned like Tetris cubes, falling into the next logically available space.

               

              As for making a subform flowed so that you can add or remove subforms dynamically, you have to make the subform up in the hierarchy flowed, and the subforms underneath it positioned.  For example, if you have a form with one page and two subforms, and each of those subforms has various fields, you would make the page subform flowed and the two subforms underneath it positioned. 

               

              Also, I found it easier to prevent LiveCycle from scrambling the fields if the subforms under the flowed subform took up the entire width of the flowed subform. 

              • 4. Re: calculation for new row added
                BLACKBERRY23 Level 1

                I still dont undertand this?? Is it possible for someone to take a look at my form please?

                • 5. Re: calculation for new row added
                  JLAFARGUE Level 1

                  Are you talking about your table or the fact that LiveCycle scrambles the objects on the form when you make a subform flowed?

                  • 6. Re: calculation for new row added
                    BLACKBERRY23 Level 1

                    both...my table wont add the field in the new row added and it scrambles everything when placed in a page subform.

                    • 7. Re: calculation for new row added
                      pguerett Level 6

                      Send it and a description of how to duplicate the issue to LiveCycle8@gmail.com and I will have a look when I get a chance.

                       

                      Paul

                      • 8. Re: calculation for new row added
                        JLAFARGUE Level 1

                        If you are talking about a table object, in LiveCycle help, search 'totals'.  It tells you how to set up table totals.  The entry example uses FormCalc as the scripting language, but I'm sure Javascript can be used with the same algorithm. 

                        • 9. Re: calculation for new row added
                          JLAFARGUE Level 1

                          OK.  I'm still new at this myself.  I just sent a note on the table because that's what I found in the Help menu.  As for Flowed/positioned and how LiveCycle behaves, and without seeing your form specifically, I can give you some of the principles I've found.

                           

                          The Content and Flow Direction of a subform refer to properties applied to objects in the subform, not the behavior of the subform itself.  When a subform is positioned, all of the objects in it display exactly where the designer puts them when building the form.  When a subform is flowed, the objects in it are displayed one under another if the flow direction is top-to-bottom. They are displayed one after another moving left to right if the flow direction is western text (left-to-right). Object which don't have enough room to fit on the line are moved down to the beginning of the next line.  Try putting three text fields on a new blank form, setting the top subform to flowed and then changing the flow direction between top-to-bottom and western text to see how the objects get moved. 

                           

                          As for the positioning of the subform itself, it depends on the setting of the content and flow direction of the subform above it. 

                           

                          The basic plan I use when building a form which will add or subtract subforms is to have the subform or forms at the higher levels flowed, and subforms that are at lower levels positioned.  That way the subforms move around but the object in them don't change position relative to each other.  Also, all objects in the form must be in subforms.  It doesn't matter if it's the only object in the subform, but put them all in subforms. 

                           

                          I'll use a simple example of a job application form which has two subforms. One subform is for the job applicant personal data, and the second is for his work history.  The second subform may have one or more instances.

                           

                          The highest form level, named sfApplication, has a content set to flowed, and a flow direction of top to bottom.  All of the subforms the next level down will be the width of the form, so the personal data, named sfPersonalData, and the subform for work history, called sfWorkHistory, will stack on each other like building blocks.  sfPersonalData and sfWorkHistory will be positioned, so objects within them will stay put. 

                           

                          On the binding tab for sfWorkHistory, I’ll check the Repeat Subform for Each Data Item box. If I initially position sfWorkHistory below sfPersonalData, each time I press the Add button for sfWorkHistory, another instance is created either at the bottom of the form (if the add button is not part of sfWorkHistory) or somewhere in the midst of the sfWorkHistory instances (if the add button is part of sfWorkHistory).   SfPersonalData stays put. 

                           

                          However, if I initially position sfPersonalData AFTER sfWorkHistory, then sfPersonalData moves down or up as I add or delete instances of sfWorkHistory.

                           

                          One more thing:  Make sure that the content area in the Master page is the correct size.  If it is bigger than your page subform, the subforms will appear to slide under the page breaks and pop up on the next page, like a road going under a bridge. 

                           

                          I hope this helps.