Thank you for your insights. I recommend that you find that original Issue Report and post this same info there so that we have all of this info in one place. It's possible that you have identified a key detail.
But keep in mind that when you make any change to a layout and save it, there's a chance that it is the act of saving the new copy that cleared up the issue rather than removing the embossed setting.
Any number of items can get corrupted or can be corrupt in a file. That's why it is recommend to use a backup file that doesn't have the problem. Filemaker 12 is suppose to handle conversion so it being embossed shouldn't be the reason it crashed. To prove that is the problem I would create another sample databases in 11 with embossed fields and then covert it to 12 and see if the error reoccurs. If it does then use report an issue at the top of this page, then filemaker may add it to the know bug list.
Minor Quibble: The Known Bug List is a publicly accessible FileMaker community resource that I created and maintain. FileMaker INc. has it's own system for tracking bug reports that is not publicly accessible. Thus, any member that properly follows the guidelines provided can add a report to the Known Bugs List though this rarely happens. Instead, I usually review the issue report and add it to the list when I judge that the facts presented meet the criteria required for inclusion in the list.
I have been going thru 65 layouts of my file removing both embossed and drop shadow features, as they are peppered everywhere. On one particularly complex layout with lots of tabbed panels where things could hide, the file continued to crash on Set Tab Order until I had found every last embossed or drop shadow item. When I cleaned out the last item, Set Tab Order worked properly.
To add one more wrinkle, I have duplicated embossed items in V 12 which were originally created in V. 11. I am not sure if the duplicated items caused the problem or the original embossed items. However I did have it happen in a V11 file converted to V12 where I had made no changes in that file in more than a year.
S. Chamblee - I do still have V 11 on one computer and could test your idea. However I cannot - without doing over several weeks of work - resume my development on what you are calling an "uncorrupted fie." Set Tab Order is one of my final steps - and I have not used the Set Tab Order command for at least 3 months. I would need to search through many backups to find when the problem began, and could lose a lot of work if I had start from a backup that is now months old. I guess I feel that lightly tossing around the expression "corrupted file" - especially for a large file that could take weeks (without pay) to rebuild - is terrifying for a developer. And what guarantee do I have after all that work I might not encounter another corruption? I am in the process of addressing the problem that reliably caused the file to crash, and so far it has worked on every layout that was previously crashing. By the way, "Recover" said "no errors found." I know Recover isn't always reliable in finding actual problems. So I'm not sure what the differentiace is between "you have a corrupted file" and "your file has a bug you can fix by removing the offending elements." Right now I'm operating on the latter belief. Sorry to sound irritable but the thought of losing several weeks of work (the project was due yesterday) is hitting a nerve.
I'm fairly new to a lot of things, and I'm not sure wether this post is still active. I've had the exact same problem as described (filemaker crash upon trying to set tab order).
I tried most of the suggested solutions (embossed buttons, dashed lines, recover files), but none worked.
I eventually could solve my crashes by disabling the "sample data" being displayed in layout mode.
Hope this helps
What you describe could indicate that you have a damaged file or layout. It's possible that the show sample data is simply a feature that interacts with that damage in such a way as to cause the crash. And it's also possible that your data has been corrupted as the sample data setting displays actual data stored in your table.
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).
I definitely seem to have corrupted files, as the recover-function states. Without searching for a solution to this crash-issue I wouldn't have recognized it myself
Right now, I do not understand what in my files is or how they got corrupted and how this affects my work.
You write to not use recovered copies for development. If I don't have no backup or the backup lies to far back in time, what do I do?
What I said was if at all possible, don't use the recovered file. If you haven't made and kept back up copies of your file, your only option is to either rebuild your file manually or take a chance on the recovered copy.
What I mean by "rebuild the file" is to either start all over and remake the file from scratch or to carefully analyze the recover log looking for entries that say "changed" and trying to identify the portion of the data base file thus identified by that entry. You then delete that table, layout, field, script, etc from a copy of your file and recover it again--repeating this process until your file recovers without any report of file damage. You then have to rebuild by hand the portions that you removed. That's a major chore, but less work than rebuilding your entire file from the ground up.
I do not understand what in my files is or how they got corrupted
Computer files--not just FileMaker files are "black boxes". We can't look inside and see all the details needed to tell if they may have been damaged in some way. The only way that we know that a file might be damaged is when an application interacts with that file and we get an unexpected result such as the file suddenly closing or the application quits or "hangs" (crashes).
Your only real defense is to use recommended "best practices" for working with your files and to make lots of back up copies--especially during development: Saving Sequential Back Ups During Development
I do not understand what in my files is or how they got corrupted
Someone else asked the same question of TSGal over in the Report an Issue part of this forum. Her reply on possible causes of corruption was:
Corruption can occur many different ways. Corruption can occur in data, with graphics, with objects (fields, rectangles, other layout objects), etc. The causes can include low memory, memory conflicts when writing to disk, bad sectors on disk, etc.
To which I can add:
Putting a file in a shared directory so that multiple users try to open the file directly instead of using Open Remote can also damage a file. And if you have back up software making copies of open database files, the backup copies maybe damaged due to the file being open.
allright... thank you for your time and till next time.