I don't know if this is applicable to your situation but are you using any plug-ins that have not been updated? If you are using older plug-ins update them.
Also in some case where you are crashing a lot in an up converted file, it is possible that you may have some corrupt design elements on the layouts in question. As you are copying and pasting elements form one layout to the other, those very elements may be the source of your problem. Try only moving fields and leave all the other elements out of the copy and paste and that may releive your situation.
Thanks for the reply. I talked the support folks at FileMaker and they had me reinstall FMP Advanced. That didn't work. Then they had me use a different account on my computer and that reduced the crashes by a lot. I had 3 in 7 hours. I think you could be right about the "crud" from the old file. Now that most of the layouts are converted things are working better.
Great! I have had many files that go through conversion have a few layout elements that are just sideways after conversion and just to mouse over will cause an issue, deleting these elemnts in layout mode and rebuilding the button or reiporting the object has done woders to fix these little annoyances.
The more I hear about this, it seems that FileMaker's new layouts with CSS are optimized for 12 and using converted classic layouts creates a lot of overhead to do things in the new format. Someone pointed out that looking at the code of a converted FP7 layout to FP12 made it huge compared to the amount of code for an FP12 layout. The lesson may be that we need to start converting classic layouts to themed layouts, unless you need a classic layout for something like IWP. I sure like the new themes and they make the layouts much more professional, but have an awful lot of classic layouts to convert.
I too have run into some bugs when working in classic layouts and I've seen the same button bug where you double click on the button to edit the assigned script and it beach balls and then crashes. I avoid this by option clicking to pull up the edit button selection instead of double clicking to avoid this problem.
"The lesson may be that we need to start converting classic layouts to themed layouts, unless you need a classic layout for something like IWP."
From what we heard at the DevCon, Taylor is right, when using 12 I think there is a need to convert layouts to the themes provided in 12 so as to avoid overhead.
Using multiple themes into 12 will also create overhead as opposed to using one theme, even if you delete the remants of the other themes.
However, not sure of the impact of converting an FP7 which uses graphics and other local items to FP12, even after deleting them. Are they removed completely or are they still causing some kind of overhead like the multiple themes?
Am I following this right? Are you saying if I have a solution with tons of customized layouts it would be best to pitch these and use on the 12 themes?
That will give you the optimum performance regarding layouts.
Let's take FP12's native gradients for example. A native gradient will be about 0.052kb whereas an image gradient of say 1px by 1px (which obviously isn't even big enough for a gradient to actually work), is about 13.00kb.
You don't HAVE to change the customised layouts to FP12 them layouts, but from my understanding you would be better off in the long run for an optimal solution.
We are converting to FP12 very soon and have hundreds of customised layouts. Many with beuatiful customised graphics which have taken hours of labour. Over time I am hoping to slim these down as much as possible and use the basic components of FP12 as much as possible.
The way the layouts work in FP12 is that you have the theme default style and local styles on top of that. Local styles can increase the overhead (perhaps only very slightly) and when you convert your solution from FP7 to FP12 and it's previously been fully customised - then all those styles are now 'local' styles which are not theme defaults and will be adding on some kind of overhead.
Really? And this is causing "converted" databases to crash?
And I keep reading that the Classic Theme is the only one supported but IWP. This doesn't mean that my customized interfaces will no longer work? Or will cause crashes.
If this is causing crashing this is a major deal breaker for me.
I can't confirm that is what is causing your crashing. My response is only with regards to the optimisation of files.
Taylor or someone else may be able to confirm for you whether or not that is the route cause of crashing issue.
Sorry, I didn't mean to confuse things. I don't have anything crashing but the previous posts here were dealing with crashes and pointed to pre FMP 12 layouts as the cause.
Crashes occasionally were happening to me on FMP12 v1 clients when I did certain things like double click on a button in layout mode and sometimes clicking on functions in script mode. Many of these bugs were fixed in v2 that came out about a week ago. However, realize that the size of converted classic layouts has much more code than native themed layouts in 12 and I while I have no proof, I can postulate that much smaller code means it works much faster and is better optimized.
Thanks. I was very worried with these answers, especially in response to the "Crashing Constantly" title line. I was further alarmed when reading that at DevCon there was some kind of info that we need to convert layouts to avoid overhead which I take it was being pointed to as a possible cause for this "crashing constantly."
Surely this was throughly tested by FMI before release. If this kind of increase overhead was leading to crashes or making files unusable after conversion this would have been stated.