A simple shortcut for moving your layout parts

Occasionally when you’re working on layouts, particularly those with multiple sub-summaries you require the flexibility to change part heights without all objects and parts below being moved. The process of rearranging objects can become time consuming as you extend parts and select and drag objects until you get everything in the desired location.

One easy way to change the height of a layout part without shuffling the objects below or being limited by the position of objects above is to use a modifier key when resizing the part.

Holding the Alt key (Win) or Cmd key (Mac) will allow you to drag the bottom boundary of the part across other objects on the layout (up or down). Normally, dragging a layout part further down will move all objects below it the same relative distance. In most cases this is what you want, sometimes it’s not. With this modifier key, you get to choose.

Carriage returns and the case of the disappearing data

Over many years of developing FileMaker solutions I've been flummoxed on more than one occasion by the invisible foe that is – the carriage return.

My broad recommendation?

Don’t allow entry of carriage returns into a field unless :

• You have a lot of spare time on your hands and enjoy troubleshooting client problems.
• The fields in question specifically require carriage returns, e.g. large blocks of text which require paragraphs to be included within the text.
• You (the developer) are controlling the insertion and removal of carriage returns because you need them for establishing relationships or other developer controlled trickery.

For those of you who haven’t already come across this issue I’ll explain why it happens and what the consequences are.

Mr Average User is entering data into the database and hits the Return key after typing in the required value. Pretty standard stuff for an Excel power user and he expects things to work the same in FileMaker. When the cursor doesn’t switch to the next field in the tab order he uses his mouse, clicking into the next field on the layout. No harm no foul as far as he’s concerned.

What the user doesn’t realise is that they’ve entered the value they intended plus an extra character, the carriage return.

The day continues on and then later that day, the next day, next week or a month later some peculiar behaviour is reported.

A particular customer’s last name isn’t being shown on printed invoices. The user verifies the data shown on the screen is correct and everything seems ok. The problems arises when a concatenated field is using one or more fields that contain carriage return. A simple calculation like Firstname & "" & Lastname produces unexpected results.

Instead of returning John Smith we end up with

John

Smith

The field on our print layout only includes provision for one line so the lastname is not shown at all, even though the user sees the value recorded in the Lastname field for the relevant contact. Let the confusion begin!

This scenario can also cause problems when you’re passing script parameters separated by carriage returns as you’ve got more values than you were expecting.

How can we avoid this problem?

• Configure your fields so that Field Behavior includes Go to next Object using Return.
• Check any data you’re importing from other data sources doesn't include superfluous carriage returns.
• Don’t assume that just because you can’t see a problem, there isn't one.

Pick a button, any button – so long as it’s the first one

Recently, I was using the Show Custom Dialog function to provide a series of options to the end user. My original intention was to allow input of 3 alternate phone numbers and then depending on which button was selected, identify one of the phone numbers as the default/preferred.

In my initial testing it seemed to be working ok however after further testing the process began to fail. A quick session with the debugger confirmed that it was working ok sometimes, but not all the time. The script looked ok, the logic seemed correct, but still no joy.

If all else fails – RTFM. A quick review of the help entry for Show Custom Dialog uncovered a specific detail that I wasn’t aware of.

Given I can configure the buttons to be labelled in any way and also script the underlying logic to behave differently based on which button is clicked I’m not sure why this restriction is required.

But, at least I’m now aware of this behaviour - and so are you.

Moving layout objects can be a real drag

Ever wondered why you couldn’t drag and drop some objects to the required location on your new layout? It was working in others ok so why not this particular layout?

The Page Margins option under the View menu (available in Layout Mode) stops objects from being dragged outside the printable area.

While this is helpful to stop objects being inadvertently moved outside the printed area it doesn’t distinguish between a layout intended for printing and one designed for user interaction. Layouts intended for user interaction will generally use areas on a layout that are beyond the standard print dimensions. While you can still use the arrow keys to move selected object(s) outside the printable area this is much slower than using drag and drop.

The solution? Pretty simple really, just de-select the Page Margins menu option and drag your objects anywhere you please.

Note: The Page Margins preference is associated with each file so a set of open files can have a variety of Page Margin settings (some showing margins, others not).

Extra Insight - Take particular notice when connecting remotely to client solutions. It can be confusing (and time consuming) if you don’t realise that Page Margins have been selected before starting some layout modifications.