I have the attached field that I need to run a few calculations of off to validate the size of the field.

I have a calculation set to calculate the size of various characters and present a total size of "Character Units" used. A character unit representing the size of a lower case character (Upper case = 1.304113 units, commas and periods, etc = 0.5454545 units based on the font I use)

My goal is to validate based on 2 criteria: Character Unit count and number of text lines.

The field can not be more than 300 characters, and no more than 10 lines of text (not all lines will have full 30 characters, and some will be have carriage returns to break the line).

I have a attached two files to show basically what the ad could look like.

Let me know if you need more explaination. I appreciate any help.

Hmmm, an interesting problem. Perhaps this might help with the character unit count:

Length( Filter( field ; "ABCDEFGHIJKLMNOPQRSTUVWXYZ" ) ) * 1.304113 +

Length( Filter( field ; ",.;:'!" ) ) * 0.5454545 +

Length( Filter( field ; "abcdefghijklmnopqrstuvwxyz" ) ) * 1.0

You'd have to exhaustive with the characters inside the quoted text to ensure they're all there otherwise they won;t get counted.

Instead of trying to add a value count validation to this field, why not set up a 10 row portal?

I had thought a little about a 10 row portal. But from a user perspective, that would be a pain to manuver around. Especially since, FM doesn't validate until the field is exited.

It is just too much tabbing around to make a nice functional solution.

Although I am open to suggestions if anyone knows a way to handle that is user friendly...

I might be able to use the web viewer to enter into a HTML form field. I suppose that way you could have the field stop accepting text once you fill the text box... But I just don't have the skills yet to make it actually work.

With your version of FileMaker you can count the number of rows of a field, even if the field do not contain any carriage return.

HINT: You'll need to "throw an anchor on SUD"

I wish I could pretend that I knew what you are referring to in your HINT.

But I don't have a clue... :qwery:

The result of the function:

GetLayoutObjectAttribute ( "ObjectName" ; "height" )

is very different in version 9, because it depends by the "anchors" of the object.

I think that this file will show it to you...

BTW: the calculation is platform dependent, so mac users may need to fine tuning it.

Count_field__s_rows.zip

I don't see how it depends on the anchors.

The default anchors are two, say:

Nord and Ovest

GetLayoutObjectAttribute ( "ObjectName" ; "height" ) returns the exact height of the field

BUT

if you ADD the SUD anchor,

GetLayoutObjectAttribute ( "ObjectName" ; "height" ) returns the height of the field when selected and the result is different if the field contains one, two or more rows.

This is why the script has the step:

Go To Field

Try to put a Pause and a Show Custom Dialog with that function or to see the Data Viewer.

When you go to the field, the field stretches to show the full content (if necessary). This happens regardless of the anchors. Your script works the same if you uncheck the "south" anchor.

On the contrary, checking the "south" anchor can defeat the script because if user has enlarged the window, the field boundaries will stretch downward, regardless of the field's content.

Your script works the same if you uncheck the "south" anchor.

Yes, you are right... only now I see it.

But that wasn't the case with version before 9 ( or so I seem to remember and now I can't check ) and, from FileMaker site:

GetLayoutObjectAttribute function

...

Notes

1) If objects are set to auto-resize, attributes returned are based on the resized bounds of the object in its current state.

Your file works the same way in 8.5 too.

That is a good thing.

Serced a way to count the rows and found only on 9 so thought that were the anchors.

Possibly the calculation could be calibrated to adjust for size/font/platform?

CountHiddenRows.fp7.zip

calibration can act on changing text size in Browse Mode ?

Because increasing the size ( on Win ) the result is wrong.

calibration can act on changing text size in Browse Mode ?

No, and it won't wash your car either.

No, and it won't wash your car either.

Man, I was hoping, too!!!

Well, its not going to work as is. But gets me moving in the right direction.

Fortunately, the field I need the calc for will never change font size. So at least I have one less variable to account for.

I'll be back after I bash my head on the wall for a bit trying to get it to work!! :cofeebrake:

The result of the function:

GetLayoutObjectAttribute ( "ObjectName" ; "height" )

is very different in version 9, because it depends by the "anchors" of the object.

I think that this file will show it to you...

BTW: the calculation is platform dependent, so mac users may need to fine tuning it.

In looking at the file, I was getting the wrong numbers with the South anchor checked. If I uncheck the South anchor is gives me the right number. (But, only works correctly with the Font and Size you had set)

Thinking a combination of the 2 ideas might work... :pounce: