I'd double check that field by entering layout mode, clicking it to select it and then comparing what is shown in "display data from" in the Inspector's data tab with what is shown in your script.
Make sure that the text, including the text to the left of the :: is exactly the same.
And might this be a field from a related table, a table other than the one on which your layout is based?
The only way that I could reproduce what you report was when the field was from a related table and there was no related record.
Thank you for responding. The field name is consistent between the field and the script. I think the related table issue is the problem.
This layout is based on "Services", several of which might appear in one contract. The previous designer built the print layout, where I'm trying to insert the signature, based on Services so it would pick up all the services that are in the contract. There are fields from both the Services table and the Contract table on this layout. I've tried basing the container field in either table, but that didn't work. To my thinking the container field should correctly be based in Contracts since there is one signature for the contract, regardless of the number of services. If I change the layout to be based on Contracts, my script works but I only get one of multiple services appearing.
I think my problem might be the lack of a joined table connecting Contracts and Services. I think I'll try that (on a backup of our live database, best practice right?) and see if that would solve the issue, since the print layout contains data from both tables. Does this sound like the right track to you? Or is there a simpler way to do it using a table occurence? (I read your tutorial, good stuff there but not sure how to set that up in this case).
I don't know if you need a join table or not from the info provided, but the presence or absence of a join table is not the source of this error in your script.
If the layout is based on services, then go to field [ Services::contract_form_print_CM_Signature] should not produce the error that you report. I'd check to see if the layout is really based on Serivces. Does that text appear to the right of "Table:" in the status tool bar when you enter Layout Mode?
Also, the Select/Perform option doesn't seem to make sense for this go to field step as this is a container field. Try clearing the check box and see if that makes a difference.
Yes Table:Services is on the status tool bar. Field is Services::Contract_Form_Print_CM_Signature. I unchecked the Select/Perform option, signature still not showing.
Could this result from a damaged db file?
"Signature still not showing" is actually a different issue from "Go to Field isn't working". Go to Field doesn't modify any data so whether your signature does or does not appear in the field is not due to Go to field putting the focus into the field.
When you run the script debugger, do you still get an error code when the go to field step executes?
PS. the one use for the select/Perform option when used with Go to Field to put the focus in a container field is when a file was inserted into the container field with Insert Field and with the "Store a reference" option specified is to open the "by reference" file in the system's default application for that file. (and this doesn't work on interactive container fields either.) I don't think that is what you are trying to do here, but let me know if I am incorrect.
Sorry for the confusion of my last post. And, the plot has thickened....
To be clear, getting the signature to show is the "goal" of the script, but yes the "102 field is missing" error occurs at the Go To Field step.
What's even stranger is that today I went to use the script on a different contract record and it worked with no errors in Script Debugger. I changed the signer so it would clear the signature and that worked also. Then I went back to the contract I had worked on previously where the script was not working, and got the same result as before, error 102 at the Go To Field step.
When the Go To Field step fails, and I step into the next step, Insert Picture, using Script Debugger, I get error 3: Command is unavailable (for example, wrong operating system, wrong mode, etc.). I don't know if that's useful but thought I would let you know.
So for some reason, the script works on some contract records, but not on others. Specifically, the Go to Field step is successful on some records and not on others.
Is it possible that you were performing this script while in find mode?
No, the script is activated by a button. There are finds performed within the script, but I'm back in browse mode by the time I reach the Go to Field step.
I suspect my FM file is damaged. For a script to work on one record and not work on another of the same type performing the same process makes no sense.
It makes sense to run a recover and see.
I've been scratching my head from near the beginning on how you can get that particular error message if you layout is based on the services table occurrence and the field is specified to be from the same.
You might also just try creating a new layout in your file on the theory that your layout is damaged. I've had a few cases where damage to a layout produced strange behavior but recover did not detect any issues.
Things to keep in mind about Recover:
While Recover almost always detects and fully corrects any problems with your file...
- The recovered copy may behave differently even if recover reports "no problems found".
- Recover does not detect all problems
- Recover doesn't always fix all problems correctly
- Best Practice is to never put a recovered copy back into regular use or development. Instead, replace the damaged file with an undamaged back up copy if this is at all possible. You may have to save a clone of the back up copy and import all data from your recovered copy to get a working copy with the most up to date information possible.
And here's a knowledgebase article that you may find useful: What to do when your file is corrupt (KB5421).
Well, reading KB5421 and your comments was kind of depressing...lots of caveats.
Our solution is not what you would call "less complicated". 378 layouts, 49 tables and approx. 1800 fields total, many of which are obsolete and even named as such, yet never deleted. My predecessor was a certified hoarder. ;)
I've never done more than compact the file in the past when things acted squirrely, for fear of making things worse.
I will do a compact first, and if the inconsistency persists I will try recreating the contract print layout. That layout has probably been edited more than any other over the years, so I wouldn't be surprised if it was damaged by now. I didn't even know layouts could get damaged!
Do you think it would be helpful to just reindex the fields that are on that particular layout?
It doesn't seem likely that re-indexing would affect this particular issue--assuming that the file really is damaged, but it would do no harm to do so.
I would be inclined to to a full recover of the file and test the recovered copy. If the recovered copy works where the original fails, it confirms that your file is damaged and then you can try less drastic "fixes" to see if they work.
And just because it is "best practice" to not use a recovered file, it doesn't mean that you never ever put a recovered copy back into service, sometimes, it is your only option.
When I select "Recover..." and it asks me to select the file to recover, how do I select a remote file? There isn't a "Remote" option...
I'm on a Windows 7 machine. The file is located on a Mac on our network running FM Server. Windows Explorer doesn't see that machine.
This thread is pretty old, but I wanted to (belatedly) say thanks for your help. I hope you get this and happy holidays!!
What wound up working was to move the signature field from the Services table to the Contracts table, and simplify my script to only address the "Contracts" table and only within the layout "Contract Set Up" that was based on that table. The "Contract Form Print" layout is based on "Services" (in order to pick up all services in the contract). Making my changes on the Contracts side solved the "field is missing" error, and placing the Contracts::Signature CM field on the print layout displays the signature correctly.
Here is a screenshot of the edited script: