I may have described this quite clumsily in the post title, but I'm very surprised that it is proving so hard to solve.

On one of the layouts in my database, there is a text field which is used for notes relating to that invoice/order. Because it appears in the header of a list layout, I've got limited space available.

What I'm finding is that the users put a wide variety of information into this field. Sometimes it's just a sentence or two, but often it can be lots of text copied from an email, or a list of accessories required.

If the content spills over the available space, then there's no indication that this has happened. So a user could quite easily missed some items off the end of a list, etc.

I had assumed that it would be fairly simple to add a warning of some kind, alerting users to the hidden information. But it seems to be really difficult to get anything to work.

Get(layoutobjectattribute) returns the complete contents of the field, irrespective of whether it is displayed or not. I found that several AI chatbots would hallucinate the existence of a "contentHeight" attribute which Get(layoutobjectattribute) doesn't support.

Other methods that I can find seem to depend on trying to count lines somehow. But even with a monotype font, it doesn't look like they will get an accurate number because of the text wrapping. (Counting the number of characters that will fit in the width of the text box doesn't work because of this)

The only workaround that I can think of is replacing the field with a text calculation, something like OriginalNotesField & "**END**"so that users know that if they don't see "**END**" to go looking for more notes. However that strikes me as being a bit of a kludge, and I'd prefer to have other interface elements triggered by the situation, e.g. having a button appear to go directly to another layout that displays the notes in full.

It does seem like this is just a fundamental limitation in the way Filemaker renders layouts. Or is there something I'm missing?

Edited March 8Mar 8 by Angus McKinnon

Indeed, there is no simple way to do this, at least not a reliable one. As you have noticed, even with a monospaced font you can only count hard line breaks, not the actual lines.

Perhaps in your case you could use a web viewer to display the text? Unlike a text field, a web viewer will show a scroll bar when there is more text to view.

To get an actual warning (i.e. a layout object that would show only when there is hidden text that overflows beyond the field's height) you would need to do what I suggested here:
https://fmforums.com/topic/110259-wrap-around-ellipsis/#findComment-492411

Thanks very much for this. It's reassuring to know that I'm not overlooking something obvious.

Since this is just one field on a page, I can afford little processing overhead. (It's a worthwhile trade-off compared to users missing important notes). So a script upon entry that does the measuring/comparison would be fine.

In the thread that you link to, what's the technique you're using to "measure the field's height after entering it and compare this with its default size"? I've tried various attempts with GetLayoutObjectAttribute but am clearly missing something.

1 hour ago, Angus McKinnon said:

what's the technique you're using to "measure the field's height

See the attached demo.

A few notes:

1. The script here is triggered on object exit.

2. The default height is hard-coded into the script.

3. The default height was measured using GetLayoutObjectAttribute() when the field is empty and active. This is different from the height dimension shown in Layout mode.

4. This simple implementation has a flaw: if you edit an overflowing field and shorten the text so that it no longer overflows, the script will still mark it as overflowing. That's because the field only expands as you type, not shrink as you delete. To get the correct result, you would need to re-enter and re-exit the field.

MeasureOverflow.fmp12

Thanks so much - that is incredibly helpful.

I've realised from your example file what was going wrong with my attempts. Your notes text field will expand when the user enters more text than it can hold. Mine don't, and I'm not sure why. Is there some layout option that I've missed? I found some references to auto-resize when searching, but that doesn't seem to apply here.

Is your field formatted to show a scroll bar?

13 minutes ago, comment said:

This simple implementation has a flaw: if you edit an overflowing field and shorten the text so that it no longer overflows, the script will still mark it as overflowing. That's because the field only expands as you type, not shrink as you delete. To get the correct result, you would need to re-enter and re-exit the field.

That would be absolutely for this scenario, as the users looking at this layout (warehouse staff) generally won't be the ones making major edits to the notes. An indication on entry to the layout is absolutely fine for that.

2 minutes ago, comment said:

Is your field formatted to show a scroll bar?

Yes! That was it. I have gotten into the habit of adding scroll bars as standard, and didn't even recognise the non-scroll behaviour.

From what I can see it's working perfectly now - a bit of tweaking and it'll be ready to deploy. Thanks again comment.

Just an afterthought: it may be more convenient to trigger the script on commit. Then you can make the script exit the field (if it's active) and re-enter it without fear of committing the record prematurely.

Perhaps consider providing a more structured way of capturing what is entered in this text box? Maybe you need more fields?

10 hours ago, comment said:

Just an afterthought: it may be more convenient to trigger the script on commit. Then you can make the script exit the field (if it's active) and re-enter it without fear of committing the record prematurely.

Thanks once again. I've got the script triggering on entry to the layout, and on commit. Seems to be working well.

I have ended up with the script entering the field (named layout object) and pausing for 0.25secs before measuring the active height. Without that pause it didn't seem to work consistently. All fine now though. Users will start accessing it tomorrow so we'll see if they can throw up any other gremlins.

10 hours ago, bcooney said:

Perhaps consider providing a more structured way of capturing what is entered in this text box? Maybe you need more fields?

You're not wrong. In an ideal world some of the information in this notes field would be split off into others. But I'm trying to keep things simple, and relatively compact. It's only a small proportion of outliers that spill over the space that's available, so harder to justify the extra overhead and space on the layout. Typically the layout gets printed for warehouse staff to prepare orders and I'm really keen to keep the majority of orders onto one sheet.

9 hours ago, Angus McKinnon said:

Typically the layout gets printed for warehouse staff

That doesn't sound right. An indication that there's more in the field than what is shown is of little use in a printout. Seems like there should be a dedicated layout for printing where this field would be large enough to show the longest expected content and set to shrink.

7 hours ago, comment said:

That doesn't sound right. An indication that there's more in the field than what is shown is of little use in a printout. Seems like there should be a dedicated layout for printing where this field would be large enough to show the longest expected content and set to shrink.

Like Bev, you're definitely not wrong. On ~90% of orders there are only a line or two of notes, or none at all. For the outliers, having a larger box would cause its own problems, e.g. making line items spill onto a second sheet.

Usually someone reviews each job on this layout, then prints it off to go and physically pick the items in the warehouse. So a quick reminder to review anything that's not showing is useful at this point. I've got a second layout available (accessed from a button which appears when a spillover is detected) so anyone who needs the notes in their entirety can do it that way.

It's a bit quirky and definitely not best practice, but seems to work for the users...

51 minutes ago, Angus McKinnon said:

Like Bev,

Uh-oh...

It’s a compliment

To whom?