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.
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?
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?
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.
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
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.