Layout Calculations in FM20.2.1

Found out that some calculations are not supported when used in a layout calculation:

Tried this:

LEt ( [

dp = Get ( DesktopPath ) ;
tp = Get ( TemporaryPath )

] ;

List (

"DocumentsPath: " ; dp ;

"-" ;

"TempPath: " ; tp ;

"-" ;

"FilePath: " ; Get ( FilePath ) ;

"-¶" ;

"convertFM DocumentsPath: " ;

ConvertFromFileMakerPath ( dp ; 1 ) ;
ConvertFromFileMakerPath ( dp ; 2 ) ;
ConvertFromFileMakerPath ( dp ; 3 )


it just stops rendering. The data viewer has no problems with it.

(Without the "ConvertFM ..." it works)


this works though:

<<ƒ:"DocumentsPath: " & Get ( DocumentsPath ) &

"¶TempPath: " & Get ( TemporaryPath ) &
"¶FilePath: " & Get ( FilePath ) &
"¶convertFM DocumentsPath: "
& ConvertFromFileMakerPath ( Get ( DocumentsPath ) ; 1 ) & ¶
// & ConvertFromFileMakerPath ( Get ( DocumentsPath ) ; 2 ) & ¶
& ConvertFromFileMakerPath ( Get ( DocumentsPath ) ; 3 )

1 Like

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.


Klinkt gut! Thanks, man. :slight_smile:

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 …

I meant your posting sounded good (was good, useful knowledge). :slight_smile:

1 Like

I never doubted you or your results! :slight_smile:

Hopefully Claris is aware of this issue and will issue yet another bug fix (YABF). LOL


thanks @OliverBarrett very much appreciated. I wish you would be the CEO of Claris International Inc.


Layout Calculation Object Observations.....

  • 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 :slight_smile: