Given that it's not consistent, it will be difficult to figure out what/why it is happening.
Can you describe in detail the typical situation where you'll get the wrong tab panel as the front panel?
Since you are using scripts to fix the issue, but still get the wrong panel uppermost, have you tried enabling the script debugger so you can watch the script attempt to select the correct tab panel?
Off hand, one possible scenario that might short circuit which panel is uppermost is if the cusor is being put in the field on that wrong panel--as that would pop that panel to the front.
Here is a screen shot of two scripts that behave erratically. And today, after a couple of months of working properly, whenever the second script ran, it crashed Filemaker. I tried to isolate where that was occuring, but it did not behave consistently. By the end of the day, things were back to normal, but I'm not sure why.
Any time you get crashes, you should use Recover to check for damage to the file. Not only can file damage cause crashes, but crashes can damage your file. See info on recovering files at the end of this post for more on that.
In your scripts, I see references to three different windows by name. Which contains the tab control? Is this layout being viewed in Form View or List View?
While this should have nothing to do with the issue at hand, I strongly suggest that you not use copy/paste to move data from one window/layout to another. This destroys any data the user may have previously copied to the clipboard and that can confuse and irritate your users unecessarily. Copy/Paste also will fail if the field referenced by these steps is not present on the current layout. Insert steps have this same limitation.
I recommend using Set Variable to copy the value into a variable and then using Set field to copy the value in the variable into the specified field. (And you can use a calculation in this step to combine the current value in the field, "; Title was" and the data in the variable.)
This won't fail if you later edit the layout to remove a referenced field, the clipboard data is not changed and the focus on various fields (might affect your tab control) is not changed.
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.
Thanks for this. I will make some adjustments and follow up on checking for damage.
The first script above shows the Go to Object command. Essentially, that script is launched from the main window, called "ParadigmDBase". The user is on what is labled "Masterfile.". The user clicks a button that's on the Masterfile Layout. This opens up a window called Bio Notes (for entering notes pertaining to a person).
As it stands, I have not mentioned the layout in the Create Bio Notes script because that's already up in the window. After selecting the window, I thought I could just continue copying (which I now know isn't the best way to go about this). However, when the window was selected, instead of going to the default tab on the Masterfile layout, it goes to another. So I added the script step "Go to Object Contact Info Tab" which is how I named that object in the Inpector.Sometimes it works and sometimes it doesn't. I don't know if this helps.
Again, thanks for your time.
I need an answer to this question that I've already asked: What is the viewing mode specified for the layout with the tab control? List or Form view?
I'm wondering if this layout is in list view such that "scroll window [home]" then takes you to a different record than that which is the current record where go to object put the focus on the specified tab.
This might explain why this works part of the time as the found set you have could, conceivably be different and thus you may or may not be looking at the current record after the window is scrolled.
Woops, sorry. The view is Form View. Scroll home was just used as a convenience to make sure that the person sees the part of the form that they should be seeing on return to that window.
Well so much for that idea.
Did you try using the debugger to monitor and step through your scripts?
Yeah, I've tried a couple of times, but never got an error. I just ran the debugger again and it showed no errors. Given the inconsistency in the way this thing is behaving, that didn't surprise me. So far no crashes today. That's what worries me. I think the next step is to go through the recommended processes for handling damaged files. I'll let you know how that goes.
I wasn't looking for any reported errors, but rather to see if any script triggers such as OnRecordLoad were being tripped by your script and thus interfering with the correct function of your script and possibly selecting a different tab panel than expected.