"Command Unavailable" definitely seems an odd error code here. I'd first check to see if some other step in the script might be generating this error code. If you have advanced, this is an easy thing to check by using the script debugger to step through your script.
You might also consider posting your script here for others to examine for issues.
To post a script to the forum:
- You can upload a screen shot of your script by using the Upload an Image controls located just below Post a New Answer.
- You can print a script to a PDF, open the PDF and then select and copy the script as text from the opened PDF to your clipboard for pasting here. (with this approach, you can get multiple script steps on the same line, please edit the pasted text by inserting some returns to separate those steps.)
- If You have FileMaker Advanced, you can generate a database design report and copy the script as text from there.
- If you paste a text form of the script, you can use the Script Pretty box in the Known Bugs List database to paste a version that is single spaced and indented for a more professional and easier to read format.
I ran the script using the debugger, learning about the error (no dialog appeared). The step just wasn't executed. I also tried changing the script step beforehand to no avail. I even created and rewrote the script and got the same result. Odd.
I've attached the code for your review.
What does the data viewer say your value is for $filterFieldName, after you set the variable? And obviously, what is in the optional script parameter field when you set the script? And of course, did you name the field you want to go to with the correct Object name?
That was one of my first thoughts, a mismatching name. I confirmed that they are all the same (Starting Point Filter) and even copied and pasted in all three places.
If that was the problem, wouldn't I have gotten a different error or no error at all?
Don't know about the error, but once again, what does the data viewer say your value is for $filterFieldName, after you set the variable?
Also you mentioned this field is on a popover, is the popover still open/active?
If the object name was wrong, you'd normally get error #116--layout object is missing.
What happens if you use go to field instead of go to object?
BTW, there are ways to update a filtered portal that do not require Refresh WIndow [Flush Cached join results] -- a step that in some circumstances can cause delays waiting for your layout to redraw.
Steve, the data view shows that the variable is set to "Starting Point Filter", identical to the other three places.
The popover is open with the user entering data into the search field thereon. It is not closed when the script is run.
Phil, that's what I thought on the error code. I've tried Go To Field instead but that didn't work as I needed it to. (There was no error though.) I've come up with the attached workaround, which actually serves my purposes better. Although I still think the Go To Object should work.
I know about setting a field to itself to update a portal. I even think Refresh Portal might work too. However, in the limited experimenting with those, more complications are introduced. Although when we move the solution to mobile I'll have to take another look at it. Any suggestions?
however, in the limited experimenting with those, more complications are introduced.
From what I see here, having to reset the text selection in a field--which neither go to object nor go to field can do, puts the complications on the other foot. I can't see where "bumping" a match field adds any complications to this at all. (And haven't gotten around to trying the new refresh portal option in 14.)
Any ideas on the error for Go To Object?
Question: Can we go to a named field in a popover?
The popover may not be "open".
If the popover is used in a portal row ... there may be many occurrences.
Could this be the issue here?
is there a portal inside this popover?
You can put a popover inside a portal and it should work just fine, but if you put a portal inside that popover, that would be putting a portal inside of a portal and Filemaker does not support this.
but if there is no such portal in the popover, the mystery continues.
Go to field, if it refers to a field only found inside a popover, slide panel or tab panel will cause that popover to open or the tab/slide control panel to move to the "front".
I don't know if this issue has been addressed, however, I have experienced this issue twice. Both times it involved GOTO OBJECT from inside a portal to a field on the parent Layout. This seems to be a result of a bug that occurs while making incremental changes to the Layout. I have found that deleting the object and recreating it eliminates the problem. Maybe FileMaker has an answer as to why the field becomes "corrupt".
I was getting the same error message. I looked at the database design report and found that the object I had named had another name in the ddr (note: this is an object I had copied from a demo database). It was strange that the name was not showing up in the Inspector. So, I entered the name that was showing in the ddr and changed my script to use that name - and eureka, it worked. no more error message.