You might try removing and re-installing FileMaker 12 to see if that makes a difference. (This is in addition to the suggestions that I made in the other issue report.)
Greetings John Allen,
Thank you for posting.
I was unable to reproduce following your steps. If you follow the steps you provided in a new file do you experience a crash?
We did get a previous report of this error on Windows XP but the circumstances on reproducing were quite different. When you get the crash do you have any additional windows open accessing the same file?
If you cannot reproduce in a new file would you be willing to send me a copy of the file that produces the error?
For what its worth, I have also previously reported the crash with
Microsoft Visual C++ Runtime Library
Program c:\Program Files (x86)\Fil...
R6025 - Pure virtual function call
Issue on Windows 7, I am not actively developing in FM12 due to the numerous bugs, but even after sending in a sample file it was classified as unreproducable.
In my case it related to opening the dialog for changing a buttons action, multiple times in a row.
It may be worth re-installing visual c++ runtime libraries, but I think its something FMI should investigate along with numerous other bugs which still persist in 12 making it a sub-par product compared with 11.
Its also worth noting that I created a brand new file, with 1 layout and multiple button objects and could reproduce it effectively. Its a FileMaker Pro (advanced) problem, or a runtime library problem, not a solution file issue. (edit: Visual C runtime library not FM Runtime)
If you have access to a different xp computer with FileMaker installed on it, do you get the same behavior on it as you do the first computer?
I have been using FileMaker 12 (mainly for testing purposes), on an XP box here and have yet to encounter this issue on it so am wondering if the issue is specific to your particular machine.
I have the same error occuring on a Windows 8 machine (yuk) and my Windows 7 machine which has also undergone a recent re-install of everything from scratch, the problem occured before and still occurs today.
I have had it happen when attempting to 'change tab order', immediate crash, altough before clicking the close, I can see the tab order dialog populated with what appears the correct info.
I have also had it happen on the specify button dialog, although not as often and more so when changing multiple buttons
11 on the same machine has no such problem and never has, with the same (albeit not converted) solution files, but as mentioned above, I can reproduce it with a fresh file created specifically in 12.
Though it seems that 12 has now been abandoned, as per usual with mostly 3 revisions... so I will remain with my original plan to completely skip this release and hope the next version finishes the job that 12 set out to do, unless of course a v4 rev does one day surface.
In my environment, I've found the culpirt - CONDITIONAL FORMATTING on objects within the layout(s).
Once I removed ALL CONDITIONAL FORMATTING from my layouts, my tab order works fine.
So far everything works fine when I created strict BOOLEAN calculation fields that return either a 1 or 0 for each condition i needed them instead of using the original field(s). Then I use CONDITIONAL FORMATTING to look at the BOOLEAN calc, and I set it 1 field at a time. There is a possibility I may have originally selected multiple fields & set CONDITIONAL FORMATTING, formula = IsEmpty( Self ) and the PURE VIRTUAL FUNCTION ERROR occured.
You are definitaley on to something...
I duplicated a layout where I cannot set the tab order whatsoever due to the crashing.
Tried changing the tab order... Crash
I then removed all conditional formatting from the layout and can now change the tab order for that one layout.
There is nothing wrong with the condition's so I shouldn't have to do this, it works perfectly well in 11.
This just highlites that there is something seriously wrong with the underlying structure of converted files with FileMaker 12 and is no real workaround, basically having to re-create everything from scratch in order to prevent crashing.
I am far too concerned to convert our solutions (and clientS) to 12 with issues like this, especially considering another anomaly I have seen relating to conditional formatting on a converted file, which involves copying and pasting an entire layout to a new one, then witnessing the fact that the conditional formatting does not evaluate on the new copy until you double click (in my casse) the object so it resizes itself.. After which it all works again. No matter how simple the condition is. Something is going on under the hood of 12 and its not good.
I hope with this little extra info, FileMaker will look into it further and be able to re-produce, but I doubt we will see any kind of fix in 12.
A little more investigation has just made me realise that original converted layouts with isempty(Self) as a condition are failing to be evaluated period, I didn't notice this before. Deleting the condition and re-creating it 'exactly' as it was causes it to work.
Luckily for me, I decided not to move forward in 12 so everything I have been doing in 12 was for experimental purposes.
This probably deserves its own report though, unless it already exists.
I was almost about to post how removing all instances of Self and replacing with the actual field had cured it, except I was jumping ahead of myself. It made it possible to change the tab order occassionally, but still crashing. The only consistently crash free experience was to remove all conditional formatting..
Interestingly though.. Not a single crash for the same file / scenario on MAC OSX for me. It works flawless.
I believe the crash is based on how Windows XP handles runtime calculations. The more items that are being calculated, the more likely the crash occurs. It kinda sorta makes since to me. If you have 15 or more fields each with 2 or more conditions and formula = ******( Self ). The system trying to keep up with multiple SELF items sounds like a computer version of WHO's ON FIRST :(
One other note, so far I haven't had the crash when I set conditions for my fields, 1 field at a time. ie even though 4 fields should FILL RED when IsEmpty( Self ). I DID NOT select all 4 fields and set the conditional formatting. I set conditional formatting for 1 field. Selected the next field, set conditional formatting, etc. and I have limited my conditions to 1 condition for each field.
Also I've changed my way of using the conditional formatting. BEFORE I had conditional formatting, formula = IsEmpty( Self ) Fill red. 2nd conditional formatting for the same field formula = NOT IsEmpty( Self ) Fill green. NOW I have the field formatted green and 1 conditional format: formula = IsEmpty( Self ) Fill red.
Im using Windows 7 x64 also have the same on Windows 8 x64.
At least you have managed to pinpoint a specific area though, which deserves Kudo's
On my particular layout, I only referenced Self 3 times, the majority of the conditional formatting in use looks at specific values of fields within the same table occurence. About 10 instances, all fairly simple imo.
Each condition is always set separately, I have never selected multiple items and created conditional formatting this way.
Nonetheless, removing self dramatically reduced the interval of crashing from 'every single time' to every 3rd or 4th time of trying to set a tab order.
Removing all condition did make it crash free.
So far I have about 400 UI based layouts, possibly thousands of uses of conditional formatting... hmm.. Ill leave it there for now :)
I have faith in FileMaker, just not this version to-date.
I just happened upon this very same error in an FMPA 12 file hosted on an in-house server. The file was built from the ground up in 12 (ie, not converted from a previous version). The error manifested itself a little differently, so I'm willing to enter a new bug if someone asks me to. But I'll start here with the details first:
- Create a new button on a layout with "Perform Script" selected, but no script defined ("Perform Script [<unknown>]")
- Assign conditional formatting to the button, based on a field's settings. Two steps were present in the confitional formatting: one, if the field = 1, apply 30% opacity Green fill. Second, if the field = 0 or isempty, apply 30% opacity red fill.
- Define the script to be executed by the button. If the field in question is set, clear it, if it is not set, set it to 1
- Double-click on the button on the layout, and apply the script to the button
- Attempt to return to Browse mode. During the process of switching from layout to browse mode, Filemaker crashes.
- Upon restart, remove conditional formatting from the button, save the layout, and apply the script to the button. Switch to Browse mode, and the file does not crash.
Of course, I just tried to replicate it in a new (local) file, and it did not crash. Nor was I able to reproduce it in the file that did crash, using the same procedure as above on a different layout. In fact, I was able to restore the conditional formatting to the button in question after the layout was successfully saved with the script applied to it.
Sorry I can't be more help, but hopefully this assists with pinning the problem to conditional formatting and provides another condition to check for the issue.