5 Replies Latest reply on Jul 8, 2014 10:02 AM by philmodjunk

    FMP 13 drops formatting on cell data export using AppleScript

    Tim_1

      Summary

      FMP 13 drops formatting on cell data export using AppleScript

      Product

      FileMaker Pro

      Version

      13

      Operating system version

      Mac

      Description of the issue

      FMP 13 loses cell data formatting when cell data is pulled using AppleScript. In previous versions of FMP, notably FMP 6, cell data retained formatting when pulled using AppleScript. For instance, I have a cell with a price. The price in a given layout shows the dollar sign and comma separator as set by Inspector > Data > Data Formatting > Currency, but the formatting is lost when pulled using AppleScript.

      Steps to reproduce the problem

      Changed cell formatting. Exported same data and selected "Apply current layout's data formatting to exported data" in "Specify Field Order for Export" dialog box hoping this would force FMP 13 to retain formatting during AppleScript.

      Expected result

      I expected to keep the formatting. Same AppleScript used on FMP 6 yields expected results. Dollar sign and comma remain. Any change made to "Selling_Price" field in FMP 6 is evident in cell data when pulled using AppleScript.

      Actual result

      Dollar sign and comma are lost, leaving a simple 5-digit number (ie. price)

      Exact text of any error message(s) that appear

      None

      Configuration information

      na

      Workaround

      Created a calculation field to add dollar sign and comma.

        • 1. Re: FMP 13 drops formatting on cell data export using AppleScript
          TSGal

               Timothy F Swenson:

               Thank you for your post.

               The data is stored in the database, and then the options to the field determines how it is displayed.  With Applescript, only the data is extracted.

               Creating a Calculation field to actually store the dollar sign and comma with the data would be the preferred method for Applescript.

               TSGal
               FileMaker, Inc.

          • 2. Re: FMP 13 drops formatting on cell data export using AppleScript
            Tim_1

                 So in some way FMP 13 handles data differently than FMP 6. As noted in my original post, using the exact same AppleScript, FMP 6 extracts the data with the same formatting used for display.

                 Can you please explain to me why it works in FMP 6 but not in FMP 13? 

                 Thanks!

                 BTW-- I disagree that creating a calculation field to add the dollar sign and comma is the preferred method for AppleScript. It's a bandaid at best. What if I had 50 different prices? I should then have another 50 calculation fields to modify the data?

            • 3. Re: FMP 13 drops formatting on cell data export using AppleScript
              philmodjunk

                   50 different prices should be 50 different records that all use the same field for the price and thus you would only need one calculation field to use to apply the needed format.

              • 4. Re: FMP 13 drops formatting on cell data export using AppleScript
                Tim_1

                     Sorry, Phi, not so. Imagine one product, a widet, whatever, that has 50 variations of size, color, whatever. Each variation has a different price. One record, 50 prices (ie. price01, price02, price03.... price 50)

                     I'm not suggesting something like this really exists. I'm saying to create a second corresponding price field as a calculation just to add a dollar sign and comma as a thousands separator is not practical.

                     50 price fields + 50 corresponding calc fields == impractical

                     Cheers

                • 5. Re: FMP 13 drops formatting on cell data export using AppleScript
                  philmodjunk
                       

                            Each variation has a different price.

                       And each variation should be a different record, possibly in a related table linked to a single General Product record. This still leaves us with just one field for all pricing.

                       But this is taking us from a bug report into a discussion of proper database design so I really don't think this is the right place for this discussion and will politely bow out at this point. wink