I went through the desert on a button with no name...

[Function G Solutions]

: OK, I know it was recently Halloween, but gremlins in my layouts I don't need. Anyway, I've been chugging along fixing this and reformatting that in layouts. Now, mind you, I am dealing with an FM6 system converted to FM11, and there are three database files - each with a table of the same name as the database. These are "Inventory", "Gallery", and the transaction table, "Consignment". Some of the button controls got broken after conversion, and these are mainly in layouts that reside in the "Gallery" database.

So it looks like any button that navigates to anything other than a local layout (in the Gallery file) or performs a script that involves going to a layout in another file (via calling a script in the other file that goes to a layout over there) - those are all broken. So I looked at the relationships that existed prior to conversion to make sure that I didn't break a needed relationship. They are all in good shape.

Then I thought it a good idea to simply create a replacement for each broken button, in case there was a behind-the-scenes something affecting this in the broken buttons. No joy. I ran the script debugger, and it never shows an error

(Last error =0), then the only thing I thought might be a problem was that the debugger showed the button as , but it says that even for buttons that work OK, so... What is going on? Any ideas? Have you seen this, but then again, how many people still have systems with multiple database files, each calling layouts in the others?

Edited November 10, 2010 by Guest

[Fitch]

"Broken" doesn't tell us much. A script that is called in another file does not automatically bring that file's window to the front. This is a change in behavior from FM6, so you'll need to add a Select Window step to your scripts.

http://www.filemaker.com/downloads/documentation/fm8_converting_databases.pdf

[Vaughan]

So it looks like any button that navigates to anything other than a local layout (in the Gallery file) or performs a script that involves going to a layout in another file (via calling a script in the other file that goes to a layout over there) - those are all broken.

During the conversion process Select Window steps are added to scripts. What's probably happening is the buttons are working and running the scripts, but the original window is being moved to the front at the end of the script, which makes it look broken.

It's a common clean-up item and is quite expected. While removing all the unnecessary Select Window steps (some are needed) make sure Commit Record steps are put in each time a record needs to be closed usually after one or more set field steps, otherwise you'll end up with record locking problems.