I named a field on my layout: 1B-L::FilterField1 (object name). I'm trying evaluate the contents of this field with the following calculation:

If(

GetField($LayoutName & "::FilterField1") < 1

)

It doesn't work. If I use the same to define a variable, I get a "?". $LayoutName is fine, it returns 1B-L.

Any ideas?

OR to put the question in a more general way:

Is it possible to get the content of the field through a variable matching the object name, instead of the field name itself? Given that the object to evaluate is a field, of course...

GetField($objectname)

Hi,

GetLayoutObjectAttribute is the function you're looking at if you're really refering to an object name.

GetField ( ) or Evaluate ( ) may be used if the string you're creating with this concatenation is a fieldname.

HTH

I'm confused as how to use this. What I have so far is:

$FieldXY =

GetLayoutObjectAttribute ( ($LayoutName & "::FilterField1"); "content")

But it doesn't return a result at all. Any ideas?

Hmm

Where did I mentionned a portal ? Are we talking about objects at all ?

Sometimes, opening the FileMaker Help may be...helpful.

If it's not, probably this is because we're not talking about objects ( Layout Mode > Clic a field > Get Info > ObjectName )

Or may be Get ( LayoutTableName ) would be more helpful than Get ( LayoutName ) if you used it to declare that variable. Still trying to guess though.

Edited May 14, 200817 yr by Guest
FM Help wasn't clear enough

Sorry, I realized that those parameters are optional. Still, not getting a result. (see above) "content" should, according to FileMaker's help, return the content of the field, yes?

If I set a variable $FieldXY = ($LayoutName & "::FilterField1"), I get: 1B-L::FilterField1 and a field with exactly that object name exists on my layout. So that's working...

Embarrassing: the referenced field was empty - all working as it should.

THANK YOU so much for your input. You're fantastic!

Ok

There are fields and there are objects. Fields may be give an object name since FileMaker 8.5. That's where it is handy to have GetObjectLayoutAtribute to retrieve the content of a field on a layout by simply giving it a short name.

The name can be given through the GetInfo box.

Now, for fields, what you need is the Related Table Occurrence name ( not the Layout Name ) before the "::" assuming this field is a related field. For sure, if the Layout Name match your TO name and you're not targetting a related field, it might work.

So, if you name your field 'ObjectTest' and you are using a calculation of type GetLayoutObjectAttributes ( "ObjectTest" ; Content ; "" ; "" ) you'd get the same result as if you were using GetField ( YourRelatedTo & "::fieldName" )

Not sure I'm clear enough

These things happen. There's a function for that called isempty ( ) ;)

Edited May 14, 200817 yr by Guest

I am curious as to why you've put this technique together? I can't imagine a scenario where it would be useful.

I second the querry. At least with a hardcoded fieldname. If tha field is passed into a variable, then it's really useful.

There's plenty of use for this!!

Just one example: with this technique you can analyze field content through object names for restricting field access in multi-user scenarios.

What if level 2 users are allowed to change the content of a field, but only after a level 1 user has made an initial entry? What if the ability to change field content further depends on the status of the record (active/inactive)? Or other criteria which change dynamically as people work with records?

Here's what I came up with:

1. Replicate the field name as an Object Name for each field you want to control access. For example following my own naming convention, I would use; T1C • MAIN WORKORDERS::Due Date

2. Set a Script Trigger OnObjectEntry to execute the script below, using parameter Get ( ActiveLayoutObjectName )

If [$$AccountLevel = "2" and Evaluate (Get(ScriptParameter) < 1)]

Go to Object Name [Object Name (Get(ScriptParameter))]

Set Field []

Else

Commit Records/Request

EndIf

The script checks if the field is empty or not without hard-coding the field name. It's 100% layout independent. And all you need to do is two things to include an unlimited number of fields in your access control script: set the object name, and link the script to the trigger.

Suggestions/Critique of any kind welcome!

Cheers,

Michael