No, the article does not help. I am using the functions as suggested, but they are returning the exact same values whether I am running the database on my Mac or on my iPhone. I am not running hosted from the Mac. I am editing the database on the Mac, then installing it to my iPhone via iTunes. Each time I do so, it prompts me whether I want to replace the existing iPhone version, which I say yes to.
Am I doing something wrong? It seems like Get(SystemPlatform) and Get(ApplicationVersion) should be returning different things depending upon where I open the database, right?
1 of 1 people found this helpful
This script should do it:
If [ PatternCount ( Get ( ApplicationVersion ) ; "iPad" ) ]
Go to Layout [ yourIPadLayout ]
Else If [ PatternCount ( Get ( ApplicationVersion ) ; "Pro" ) ]
Go to Layout [ yourDesktopLayout ]
Go to Layout [ yourIPhoneLayout ]
Please review my original post. The Get(ApplicationVersion) function IS NOT WORKING for me. It is returning "ProAdvanced 12.0v4" whether run from my Mac or from my iPhone. Likewise, the Get(SystemPlatform) is returning 1 from both places, where it should be returning 3 on an IOS device. Otherwise, I'm using code very similar to yours.
Just to make sure you are not being hung up by global field behaviour, I suggest you try changing your global calc field into a standard unstored calc to make sure it refreshes properly when you load the file or a record. This is because the global field may be opening up with its preset contents, hence giving the appearance that the function is not working. I may be barking up the wrong tree here, but if it was me I'd certainly want to rule out that possibility.
rm: you might also more carefully read the script. It doesn't use a calc field, but just evaluates the appversion live as the script runs.
The FUNCTION is working; but global calcs are not working as you expect them to.
The script should run fine as written.
I do think global calcs are a little hard to understand, it seems like they should perform like unstored calcs - but they just don't work that way.
It is an important distinction; and important that you have experienced it so you can get a handle on how they work.
You are right, the global field was messing me up. I only put it there as an indicator of what the get functions were returning, using a text field on the form to display its value. Instead, I replaced all of that with a message box showing the functions, and it worked fine. Thanks again!
You are right of course. Please see my answer to keywords above. This just shows how much I have to learn about FMP. Funny, programming for SO many years, and feel young and stupid again...
Do you know how to set up the field as an unstored calc?
Thanks a lot, keywords. I'm voting your answer as helpful, because of the time you gave me.
Steve came in first, so I must give him credit for the answer.
No, I don't know how to do that yet with a field. However, I don't really need a field. I only put one there so I could see what the Get function was returning. Then I realized I could do that with a message box instead, so I deleted the field.
Under what circumstances might I need an unstored calc in a field? And how would I do that?
On the right side of the field calculation dialog there is a button "Storage Options"
Click that and then click "Do not store calculation results"
An unstored calc is a "live" calc that updates itself whenever it is viewed.
You should definitely know how to use an unstored calc; and where you would use one; and and their advantages and drawbacks.
A common use for an unstored calc is to get some kind of aggregate from relate (child) records.
Such as, for an invoice, a sum of all the extended prices of the invoice items.
This calc will update itself as you enter and edit the line items.
Sometimes you will need to do a window refresh script step to see an up to date result.
The downside of unstored calcs is that they can't be indexed and search performance is poor.
Again using the invoice example, if you wanted to find invoices where the invoice total is greater than 1000,
Enter find mode
Set field invoic total, ">1000"
Perform the find.
Filemaker will then examine every record and recalculate its total and finally, display the records with the correct result.
This gets old fast with large record sets.
storage options.png 91.7 K
In the case of Keywords suggestion to change your original global calc to an unstored calc - that would have worked fine.
Your entire original approach would have worked with just that one change because the calc would refresh itself when your script checked the value of the field, it would show the correct value at that instant.
Good point, Bruce. Fact is, I didn't need a calc at all, as I explained in an earlier reply. Still, it's good to see these ideas being posted. Helps me learn more about FMP. Thanks all...