So what is happening the ConvertFromFileMakerPath function with second parameter 2 = WinPath fails (on MacOS) and the layout calculation won't render whereas the data viewer returns "?" but evaluates all other valid expressions.
Doesn’t sound good to me. Remember fm11v1 introduced layout variables but if they weren’t assigned they just displayed the variable name on the layout in browse mode, this behavior was defended first then later corrected.
Here in my example the entire calculation shows up in browse mode if one part of the Calc statement fails …
a layout calculation CAN be placed in a button label verbatim, but CANNOT be placed in a button bar segment label verbatim.
A layout calculation by itself as text on a layout, does not auto-resize the edit box when clicked, but IF you combine that calculation with any text, it behaves like legacy merge variables/fields and resizes when clicked.
If you add a button action to a text based layout calculation (resulting in a grouped object), the calculation remains within the bounds of the button itself, instead of auto-resizing.
A double-click of a layout calculation object. the edit box resizes. You have to manually resize it down again, but it retains that smaller size.
Is there a calculation dialog shortcut associated with a layout object after creation, or do you have to context- or regular menu select to get the dialog?
I'm not sure I [currently as of now] see any advantage to a layout calculation that we did not already have in button bar segment calculations...... ???
MAYBE (need to test), the GET calculations that, if in a button bar segment, do NOT work in a portal, but instead, return the information relative to the base layout, will work as a layout object.... TBD