July 24, 200718 yr 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
July 24, 200718 yr 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.
August 6, 200718 yr Author 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
August 30, 200718 yr Newbies 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
August 30, 200718 yr $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) ) )
August 31, 200718 yr Why you would have a field on the same layout twice I haven't the faintest... But yes you could run with your suggestion.
August 31, 200718 yr 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.
August 31, 200718 yr David's approach would work fine in that scenario but .. just out of curiosity - whys your id field on on there two times?
August 31, 200718 yr 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, 200718 yr by Guest
August 31, 200718 yr 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, 200718 yr by Guest
August 31, 200718 yr 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.
September 3, 200718 yr 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, 200718 yr by Guest
September 3, 200718 yr The reason that wasn't suggested in this case is because the user is running v8 not v8.5
September 3, 200718 yr 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.
Create an account or sign in to comment