13 Replies Latest reply on Dec 29, 2016 8:44 PM by BruceRobertson

    Script, Find records, from previous table's record/layout

    tleitzke

      I am trying to create a simple inventory ordering system. I have created an invoice and products table, with a third table for storing invoice ID and product ID reference. What I need to do is create a print-report of the portal/records of the specific invoiceID. I have a button on the form layout of Invoice table (which has the portal I want to print, with relation to Invoice by InvoiceID). The button currently does "Go To Layout(X)" followed by "Perform Find(X)"- which is set to find by InvoiceID, which comes out to (i am guessing) "0" instead of the previous layout's record's InvoiceID number. (price fields were removed after this image was taken, which is only change)

       

       

      Capture3.PNG

        • 1. Re: Script, Find records, from previous table's record/layout
          BruceRobertson

          When asking for help with a script that doesn't work, it is helpful to post a copy of the script.

          You can do that by using screen capture, or by printing the script to PDF.

          Even better is to post a copy of your file; or a clone of your file.

          • 2. Re: Script, Find records, from previous table's record/layout
            tleitzke

            There is not really anything in the script. I just added "show all records" so that any previous finds/sorts/whatnot is erased and the search will find from all records (just as backup)

             

            Capture.PNG

            • 3. Re: Script, Find records, from previous table's record/layout
              erolst

              If you want to print an invoice, it's best to do that from a layout based on the line items (ie your 'InvoiceParts').

               

              Create a layout based on the InvoicePart table occurrence (Layout Setup: Show records from ...), and all you need is (from the context of an Invoice record):

               

              If [ IsEmpty ( InvoicePart::InvoiceID ) ]

                Exit Script

              End if

              Go to Related Record [ from: InvoicePart ; layout: YourNewInvoicePrintLayout ; matching only ; current only ]

               

              which means the relationship itself performs the Find for you

              • 4. Re: Script, Find records, from previous table's record/layout
                tleitzke

                Wow. Now only if there was some documents that had something with relation to this :/

                 

                Thank you though. What is the point of having the if statement end the script if invoiceID is empty? (It is currently auto-generated from creation. Is it just an emergency backup incase something went wrong?)

                • 5. Re: Script, Find records, from previous table's record/layout
                  erolst

                  tleitzke wrote:

                  What is the point of having the if statement end the script if invoiceID is empty? (It is currently auto-generated from creation. Is it just an emergency backup incase something went wrong?)

                  Yes. Error trapping is a crucial component of coding. Just consider Murphy's Law.

                   

                  If the reference to that field is empty, that means that is is empty in the first related record, meaning there are no related records. That's why you reference a field that isn't supposed to be empty, like the primary key. (Speaking of which, it seems that your InvoicePart table doesn't have one.)

                   

                  GtRR is usually used to do something to/with those related records. If there are no RR to Gt, you'll remain on the current layout, and the next commands/steps will be applied to the records of that layout - with consequences ranging from the mundane (like here) to the catastrophic (Delete all Records [ dialog: off ], anyone?).

                  • 6. Re: Script, Find records, from previous table's record/layout
                    tleitzke

                    I figured that having a key for every invoicePart would be redundant since I won't ever be displaying them all and is used just as a storage (to me it makes sense, but to you it may not. I come from C# and C++ programming, which is not similar really). Should I be adding a key id to all the invoicePart?

                    • 7. Re: Script, Find records, from previous table's record/layout
                      erolst

                      It's not about displaying them all, but being able to identify each one unambiguously. In fact, every table (with the exception of Utility tables) should have a primary key.

                       

                      Next thing you know your users want a sophisticated way to select products and add them as line item. Once you get there, you'll find yourself saying: "I need to find the newly added line item in the display portal and go to the amount field so the user can easily enter the desired amount ..."

                       

                      In a join table you could create a primary key by concatenating all foreign keys to get a unique key - but then it is so much simpler to just define an auto-enter serial number or a UUID, and it avoids any complications that could arise from later changes.

                      • 8. Re: Script, Find records, from previous table's record/layout
                        tleitzke

                        The way it currently works, I already do have each "line item"/invoicePart containing a specific wanted amount.

                         

                         

                         

                        Capture.PNG

                        • 9. Re: Script, Find records, from previous table's record/layout
                          BruceRobertson

                          Plenty of documentation. Next step is to read it.

                          • 10. Re: Script, Find records, from previous table's record/layout
                            tleitzke

                            There are loads of documentations. But they are so simplified, that more than half the time it goes back to something similar to looking in the dictionary for a definition of apple to get "an apple is an apple"

                            • 11. Re: Script, Find records, from previous table's record/layout
                              BruceRobertson
                              The way it currently works, I already do have each "line item"/invoicePart containing a specific wanted amount.

                              This is a response to what?

                              • 12. Re: Script, Find records, from previous table's record/layout
                                erolst

                                tleitzke wrote:

                                There are loads of documentations. But they are so simplified

                                 

                                Nope, it's that you don't have the big picture yet.

                                 

                                The common theme is complexity out of simplicity (and I think that is true not just for FM). You have three tables with a simple structure, and already you could do loads of things with them, thanks to the relational interplay that can be as complex as you need it.

                                 

                                Same with the documentation. Most commands and functions have a simple API. The art is to know when to use what how where (and why (and who, if this were journalism school ...)).

                                 

                                tleitzke wrote:

                                looking in the dictionary for a definition of apple to get "an apple is an apple"

                                Horse, n. "A horse is a four-legged animal that breeds other horses."

                                • 13. Re: Script, Find records, from previous table's record/layout
                                  BruceRobertson

                                  Looking in the dictionary, I get this result.

                                   

                                  apple |ˈapəl| noun1 the round fruit of a tree of the rose family, which typically has thin red or green skin and crisp flesh. Many varieties have been developed as dessert or cooking fruit or for making cider.[ with modifier ] an unrelated fruit that resembles an apple in some way. See also custard apple, thorn apple.2 (also apple tree)the tree which bears apples.[Genus Malus, family Rosaceae: numerous hybrids and cultivars.]3 (the Apple) short for Big Apple.PHRASES the apple never falls far from the tree proverb family characteristics are usually inherited.the apple of one's eye a person of whom one is extremely fond and proud.[originally denoting the pupil of the eye, considered to be a globular solid body, extended as a symbol of something cherished.]apples and oranges N. Amer. (of two people or things) irreconcilably or fundamentally different.a rotten (or bad) apple informal a bad or corrupt person in a group, typically one whose behavior is likely to have a detrimental influence on his or her associates.[with reference to the effect that a rotten apple has on fruit with which it is in contact.]upset the applecart spoil a plan or disturb the status quo.ORIGIN Old English æppel, of Germanic origin; related to Dutch appel and German Apfel .