Go To Field ($fieldname) ?

[Mandu]

Is there a way for a script to position the cursor in any field? I'd like it if the error-checking script could place the cursor in the field containing the error. "Go to Field ($fieldname)", if you will....

Thanks,

Chap

[Genx]

Hi Mandu, unfortunately not, however there is a small work around you might try given that in your case the field is guarranteed to be on the layout.

Create a new script called "GoToField[fieldName]"

If[isEmpty(Get(ScriptParameter))]

Show Custom Dialog["Note to developer: Please specify a field to go to via the perform script step"]

Halt Script

End If



Go To Field[Next]

Set Variable[$fieldName ; Get(ActiveFieldName)]

Loop

Exit Loop If[Get(ActiveFieldName) = Get(ScriptParameter) ]

Go To Field[Next]

If[$fieldName = Get(ActiveFieldName)]

Show Custom Dialog["Note to Developer: Field Not Found on Layout"]

Halt Script

End If

End Loop

Then just pass the field you want to get to as a parameter (note that all your fields will have to be in the tab order on your layout). I'm in a rush, so if anyone sees any errors in that script, please point them out to Mandu.

Cheers.

[Mandu]

Thanks for the reply - sorry not to have acknowledged sooner but apparently I missed the notification. Anyway, I get the idea and will try it. Thanks -- Chap

[mfisher]

Interesting workaround. I don't quite understand the reason for the "If[$fieldName = Get(ActiveFieldName)]" script step. If it's meant to be an exit condition, I would have expected the test to be for inequality. At any rate, the general idea is clear.

Another alternative would be to apply an object name to the target field. You may then go to this field by using a Go To Object script step. Unlike Go To Field, Go To Object accepts a string literal or variable for the name of the target.

After the Go To Object step, you may use the Set Field script step. If you turn off the "Specify target field" checkbox, the field which gets set will be the current field.

The steps to applying an object name to a field are:

- Go to layout mode

- Select the target field

- Click View > Object Info

- Type a name in the Object Info window

[David Jondreau]

$fieldName is the field the user was in when the loop began. If it returns to that field without having exited the loop, then presumably we're back where we started.

I think "presumably" is a weak point in this script though. You could have the same field on a layout twice.

I think the script would be better off instead with a $counter and ValueCount( FieldNames( Get( FileName); Get( LayoutName) ) )

[Genx]

Why you would have a field on the same layout twice I haven't the faintest... But yes you could run with your suggestion.

[JesseSFR]

I have layouts where there are two different fields named `id` on it all the time.... it definitely causes problems with this approach but there is no other way if you REALLY want to go to a field generically. Shame.

[Genx]

David's approach would work fine in that scenario but .. just out of curiosity - whys your id field on on there two times?

[David Jondreau]

Oh, I can think of a couple of reasons to have the same field more than once on a layout.

1) A portal.

2) A tab control with editable information on it, but above that is a that same information in view only form (so that it's always visible when users are on other tabs) and you don't want to use merge fields.

3) A search box with a global reporting field that's repeated in several parts of the layout (esp if scrolling is needed). Probably bad design, but it happens.

Of course, coming up with these makes me realize my modification to this technique may not work. A portal's fields only show up once in FieldNames regardless of the number of related records showing. And a non-visible tab's fields show up in FieldNames, but GoToNextField doesn't siwitch tabs.

Might be able to modify Genx's technique to get past the portal problem by using an If statement and a Get(ActiveFieldTableName). But that won't help #2 or #3.

Edited August 31, 2007 by Guest

[Genx]

Lets try combine a few things and add a few more:

Set Variable[ $fields ; FieldNames( Get( FileName); Get( LayoutName) ) ]



If[isEmpty(Get(ScriptParameter))]

	Show Custom Dialog["Note to developer: Please specify a field to go to via the perform script step"]

	Halt Script

End If



Go To Field[Next]



Loop

	

	if[ Get(PortalRowNumber) < 2] 

		Set Variable[ $i ; value: $i + 1]

	End If 



	Exit Loop If[ Get(ScriptParameter) = Get(ActiveFieldName) & "||" & Get(PortalRowNumber) or Get(ScriptParameter) = Get(ActiveFieldName)]

	Go To Field[Next]

	If[ValueCount($fields) = $i]

		Show Custom Dialog["Note to Developer: Field Not Found on Layout"]

		Halt Script

	End If

End Loop 

The above will take a script param as: fieldName "||" PortalRowNumber or just as fieldName

PS Code untested.

Edited August 31, 2007 by Guest

[David Jondreau]

One other thing about Get(ActiveFieldName) is that it just returns the field's name, not the base table or TO. So a "NameFirst" field of a Contact record, and a "NameFirst" field of a related, say, Family Member, both return "NameFirst".

Maybe that's what 6FR was talking about.

[Genx]

Yeh, but that's why we've got:

Get ( ActiveFieldTableName )

Set Variable[ $fields ; FieldNames( Get( FileName); Get( LayoutName) ) ]



If[isEmpty(Get(ScriptParameter))]

    Show Custom Dialog["Note to developer: Please specify a field to go to via the perform script step"]

    Halt Script

End If



Go To Field[Next]



Loop

    

    if[ Get(PortalRowNumber) < 2] 

        Set Variable[ $i ; value: $i + 1]

    End If 



    Exit Loop If[ Get(ScriptParameter) = Get(ActiveFieldTableName) & "::" & Get(ActiveFieldName) & "||" & Get(PortalRowNumber) or Get(ScriptParameter) = Get(ActiveFieldTableName) & "::" & Get(ActiveFieldName)]

    Go To Field[Next]

    If[ValueCount($fields) = $i]

        Show Custom Dialog["Note to Developer: Field Not Found on Layout"]

        Halt Script

    End If

End Loop 

Where the user could specify the desired field name as either: TableName::FieldName or otherwise TableName::FieldName||PortalRowNumber

Edited September 3, 2007 by Guest

[Genx]

The reason that wasn't suggested in this case is because the user is running v8 not v8.5

[JesseSFR]

Genx, sorry for the delay...

I name all my table id's simply `id` so if you have an id for the TO which that table is based upon and a related table as well you would have problems.

It looks like you have found a solution to that problem with the get(activefieldtablename) solution... very slick... I'll have to look at it a little more.