Have you attempted to run FileMaker 12 recovery on the file to see if that changes the behavior?
Thanks. I didn't realize that recover worked that way. I just tried it and it claimed to have found no issues. I did see that the resulting file size was larger which seems strang (old: 53,448,704 bytes; new: 53,481,472 bytes). If the claim is true that no problems were found, then the problem still seems more like a timing bug in FileMaker Pro. I'll use the slightly-larger recovered file going forward to see if the problem persists.
I have had the old frame of a pop-up menu seemingly burnt-in after converting a file. In FM 12 the outer frame of the field appeared in dark gray and could not be changed in FM 12 with the appearance panel of the inspector.
The file was converted without errors and a rebuild was error free as well. The problem turned out to be that the line thickness of the field in FM11 was set to 'none' without a border while the color was defined as the background color. I was able to remove the burnt-in frame by changing the color of the field's frame to 'transparent' prior to conversion.
I can't reproduce the issue with a simple file but the burnt-in frame appeared on every layout that had the line thickness set to 'none' while the color was not set to 'transparent'.
Thanks to CodeCruncher. I don't think that my problem is related to what you describe. My pop-up menu frames are all set to "1 pt". I am able to select an item from the pop-up menu. It's after I select it that it sometimes hangs FM 12.
I hope to gain more experience with my issue later this week when I know that I'll be adding new entries in the same manner as brought out the problem that I initially described on this forum thread. If I get through the entire week without a single problem, that will raise my confidence that perhaps the Recover suggestion worked.
Sounds good Paul. Just to let you know the recovery command should only be used to salvage records. I use it to check my databases for errors during development on a regular basis but only perform the recovery command on a copy of the file that I erase immediately after the recovery command does not show any errors. If the recovery command shows any errors I revert to my latest backup that did not have any issues.
One of my 'clean' files actually shows up as corrupted after conversion to FM 12 although it is meticulous maintained. I will take another look with the next update of FM 12. I know it's not the original file. My experience with the burnt-in frame illustrates that the conversion still has some bugs. Good luck!
Very interesting. Thanks CodeCruncher. What you describe is how I imagined recover may work. My impression from iDEViate's post was that it might work a little differently. Having no experience with recover myself, I'm learning lots from these posts. Thanks again.
I have not encountered this problem this week until now. Tonight, once again, I encountered this problem. Thus, I think that this encounter is fairly good evidence that "Recover" didn't resolve this issue. I can't think of anything else to try. I assume that this is a timing bug in FrameMaker Pro 12. I can only hope that the FM engineers find it soon and provide a fix. Depending on how many times I encounter this problem, I may fallback to FM Pro 11. (If that happens, I would surely like to get my money back for FM Pro 12.)
Thank you for your posts.
Do you have any third-party plug-ins installed? If so, what are they?
In the original issue, you mention a drop-down menu, but in later references, you mention pop-up menu. Although these are similar, these do act slightly differently.
How large is the value list being used for the drop-down/pop-up menu? Are the values static? Or, are the values taken from another table?
What other applications do you have running at the time of the crash?
Any other information you can provide to help replicate the issue would be appreciated.
> Do you have any third-party plug-ins installed? If so, what are
I have no (i.e., zero) plug-ins.
> In the original issue, you mention a drop-down menu, but in later
> references, you mention pop-up menu. Although these are similar,
> these do act slightly differently.
I apologize for the inconsistencies on my part. I just
double-checked: it's pop-up menus where the problem is occurring.
> How large is the value list being used for the drop-down/pop-up
> menu? Are the values static? Or, are the values taken from
> another table?
It's happened on at least three different pop-up menus (all on the
same layout). The sizes of those three are: 9 values, 12 values,
and 34 values.
The values for all these pop-up menus are static.
> What other applications do you have running at the time of the
Applications in terms of apps on my Mac? I have many applications
that are "running", many are idle, but they're "running". (I
apologize if I'm misunderstanding your question).
> Any other information you can provide to help replicate the issue
> would be appreciated.
Here's a theory that my be groundless (take it for what it's
I have multiple "web viewers" in this layout. I assume that FM
uses some threading logic to asynchronously load these pages. Is
it possible that that there's a thread-related timing window that
is causing this problem? I'm usually moving pretty quickly between
records, while setting these popup-menu values which means the web
pages are being loaded and reloaded fairly often (reloaded because
I'm also bouncing between table view and form view frequently).
I had two failures (so far) this morning. The first was the same
as all previous failures where I changed a value in a pop-up menu
and FM hung.
The second is more interesting though in that it wasn't directly
related to a pop-up menu change. This time, I changed a text field
in the record and then tried to move on to the next record. I have
a script to move between records which is bound to a function key.
The script is as follows:
Go to Record/Request/Page [Next]
As soon as I hit the function key that is bound to the above
script, FM hung.
That would seem to imply that the pop-up menu is a red-herring.
There's something more fundamentally wrong.
Has anybody else reported a problem such as this?
What you are describing indicates that your file can crash whenever you move to a different record right after a field has been modified and the change has not been committed. Enter the 'Commit Records/Requests [No dialog]' script step prior to the 'Go to Record/Request/Page [Next] script step and see if FileMaker 12 still hangs.
CodeCruncher: But this is the first encounter of trying to move to a new record. All of the other encounters were not trying to move to a new record. Are you suggesting that the two different types of encounters (i.e., 1. pop-up menu and 2. moving to the next record) of this problem have different root causes?
I might have misinterpreted one of your prior posts:
I'm usually moving pretty quickly between
records, while setting these popup-menu values which means the web
pages are being loaded and reloaded fairly often...
Ahh, got it. Thanks for the clarification. Yes, I'm moving between records regularly, that's true. However, at the time of a pop-up menu hang, there's no attempt to move to another record at that moment.