8 Replies Latest reply on May 24, 2014 10:46 AM by nihmbrisby

    Starter Solution Script



      Starter Solution Script


           I'm finding it very helpful to study the scripts in the starter solutions.  Am I correct in assuming that these must be well written since they're made by filemaker to represent their best methods? 

           Anyways, I have a specific question.  I frequently see a script used in a trigger "Trigger | Refresh Search." It's attached.  A script trigger that runs when you start your session sets $$PLATFORM = "Desktop" for mac or pc.  (and then tablet, phone, and web for the other platforms).  Why does the script set the ID field = to itself if the platform is not a desktop?  

           Does it refrain from Refresh Window [Flush cached join results] in order to minimize the impact on the mobile device's web connection? (from filemaker help: Do not select this option if you know your script does not affect related data, and if you want to minimize the performance impact of re-accessing related data (particularly when sharing a database over a network).  If so is this just them 'being safe' or should I strenuously avoid these sorts of things when developing a fmp go solution?



        • 1. Re: Starter Solution Script

               Another question regarding a script I've attached. As you can see from the attached picture of the layout- It's an invoice.  In the pop up you select a product.  A button on the portal row captures the ID as a script parameter.  It's the next part that's new to me.  What I'm accusomted to seeing in other explanatinos solutions is this:

          1.           Set variables for InvoiceID, ProductID (which the button feeds to the script as a parameter (because you selected a product from the portal)), and any other info you want to take to the join table.
          3.           Go to layout based on join_Invoice_Product
          5.           create new record
          7.           set the record's foreign key's with the InvoiceID and ProductID
          9.           done

               However in the Filemaker starter solution,

          1.           they stay on the invoice layout
          3.           have the script navigate to the first field on the portal
          5.           navigate to last portal row (Go to Portal Row [last]
          7.           Set the product ID

               My questions:

          1.           Why do they do it this way?  I see that they declare one less variable and don't create a new window / go to another layout, but I don't know the significance of that (performance?)
          3.           Why do they set a variable for both the productid AND the item name? Couldn't they just take the product ID and refresh records?  The only reason i can think of is that their method ends in the Quanity field.  But couldn't you create new record in a different window, close the window, and navigate to the same field?

               It's not that I sense any problem with their method, rather I'd just like to know why they do it and if it's a 'best practice.' Especially since creating new records in join tables seems like something I definitely want to do the right way.


          • 2. Re: Starter Solution Script

                 Here's the image of the layout:

            • 3. Re: Starter Solution Script

                   One more question regarding Filemaker's invoicing solution.  I've attached an image of the script and an image of the relationship diagram (which also applies to the above examples).  On the pop up shown above, there's a script attached to the New Product button (see attached image).  

                   For the most part- their model accords with what I've learned elsewhere.   To create new products from the invoice layout (product is 2 steps away across a join table), a new product to is related to a Global Variable foreign key (which I'll refer to as MatchID (Global)) in the invoice table (with allow creation of records in the product side).  Then, on the pop up shown above, there's a script attached to the button that does some prep work and moves the slider to the new product slide.  

                   It's the first step of the script I don't understand.  The way I've seen it elsewhere, the 'prep work' is making sure the MatchID (Global) is cleared so that when you enter new product info (name, manufacturer, etc...) it creates a new record.  Instead of setting the MatchID (Global) to empty (""), there's this: (for ease of reading I've made the the MatchID (Global) red and the MatchID of the the new products Table Occurrence blue.

                   Set Field [invoices::PRODUCT ID MATCH FIELD; GetNextSerialValue ( Get ( FileNAME ) ; GetFieldName ( All Products | Popover::PRODUCT ID MATCH FIELD) )

                   It's like their setting the MatchID (Global) to the serial number before it's been generated.  If so, why? If not- what are they doing?

                   If this is the correct way to do it I'm at a loss as I've already set up with UUIDs.  

              • 4. Re: Starter Solution Script

                     And here's the relationship diagram (I hope I'm correct in thinking it's only one image per post).

                • 5. Re: Starter Solution Script

                       IT looks like this script is anticipating the ID to be generated automatically when the next new product record is generated in Products. Presumably, this then allows the user to enter data for the new product in a slider inside that popover and that successfully creates a new product record.

                       That's clever, but it can produce problems if the file is shared over the network and two different users run this script at the same time and thus get the same value returned.

                       It's also unnecessary unless FileMaker 13 has changed a basic behavior. If "allow creation of records via this relationship" where enabled for "New Product | Popover", the script could just clear the Match field in Invoices and entering data into one of the fields from New Product | Popover will create a new record in products that links automatically in Invoices by copying over the new record's ID. That avoids any issues that might occur when hosting the file over a network.

                       We usually use this field in the opposite direction--using allow creation to enter the layout record's match field value(s) into the fields of the newly created records, but the reverse also works.

                  • 6. Re: Starter Solution Script

                         Thanks Phil.  The method you outline was my plan (here's a clear tutorial for anyone interested: https://www.youtube.com/watch?v=5FS-ETvvFbQ starting around 14:45).  I'm surprised to see that not only is their way not necessary, bu your point about duplicate serial numbers makes it seem downright dangerous.  Perhaps their scripts aren't so great to learn from?  Unless anyone has support to offer for their method for creating new records in child tables I think I'll go with the method I've seen outlined elsewhere- capturing the 2 primary keys and creating the record in a new layout (as opposed to having the script navigate to the last row of the portal).


                    • 7. Re: Starter Solution Script

                           The starter solutions are not created by super programmers that never create mistakes. I've pointed out flaws in them myself. But they are created by experienced knowledgeable folks and do serve as useful examples of how you might go about designing things. I've learned a number of useful tricks from them myself.


                                capturing the 2 primary keys and creating the record in a new layout

                           Is a method that I've used frequently, but it's not the method that I outlined here.

                      • 8. Re: Starter Solution Script

                             My bad- I thought the method you outlined was for creating new records in a distant table (ie on the far side of a join table) and was addressed to my 3rd question.  My point about "capturing the 2 primary keys and creating the record in a new layout" was in reference my 2nd post and describes the method I've learned for creating a new record in the actual join table after capturing the product's primary key from a button's script parameter.

                             This is (as best I can tell) how the starter solution does it in order to have a nice searchable list as opposed to a colossal dropdown (presuming, ultimately, 1000's of records) list in a portal row.  This part I get and works perfectly for me.  However, in the starter solution (again, as best I can tell)- despite having already 'gotten' the product primaryID, they also get the corresponding product name and stay on the invoice layout by navigating to the portal row instead of storing the invoices id in a variable and creating a new record in a new off screen layout (so in this case they do take advantage of the 'allow creation' property).    

                             I just wanted to be sure that this wasn't an inherently superior method before I did all the work of making join tables work.  I was especially concerned cause I honestly couldn't tell any difference between the two methods.  One method (new layout) is the one I've seen in literally every tutorial.  The other method I've never seen- but was crafted by the actual people at Filemaker.  I want to use the best possible method for this very fundamental procedure.

                             I didn't mean to criticize the filemaker devs.  It's tough to find out about some of the more advanced stuff that should be in scripts (or at least advanced to me- like 'allow user abort" and 'flush cached join results').  Their scripts are replete with these things.  To know when, where, and how to use that stuff- it's hard to know whose example to follow.  Many of the issues I'm guessing they address (networking issues), I've yet to learn about.  I can't learn everything in advance- my hope is that if I follow 'best practices' I won't find myself in a bad place when I do learn about them.