13 Replies Latest reply on Aug 8, 2015 9:01 AM by philmodjunk

    Frequent crashing in FMP 14



      Frequent crashing in FMP 14


      FileMaker Pro



      Operating system version

      OS X  Yosemite 10.10.4

      Description of the issue

      Cut-and-paste and copy-and-paste cause crashing.

      Also, adding layout elements from scratch and then switching to browse mode causes crashing.

      I'm working in a database that I began building in December 2014 (8 months ago) -- from scratch -- in FMP 13.  I've just "upgraded" (a term I use extremely loosely) to FMP 14 Advanced and find that even the most basic pasting causes frequent crashing -- whether in LAYOUT mode or working with field content in BROWSE mode.

      On another note:  I give the new script writing work screens and the mechanisms to assign button scripts a MASSIVE thumbs down.  Like the Jolly Green Giant's thumb.  Basically, FMPA 14 stinks in every way that I've tried it.  Total waste of money... and my user time.

      Steps to reproduce the problem

      Cut-and-paste or copy-and-paste:

      1.  Any object in layout mode (even one you created from scratch using the toolbar tools)

      ... and/or ...

      2.  Any text in a text field while in browse mode.

      Expected result

      A proper pasting of the object or text.

      Actual result

      Spinning beach ball followed by crash message.

      Exact text of any error message(s) that appear

      It's the crash message.  You know the one.

      Configuration information

      It was the default install of FMP Advanced 14.


      Use FMP Advanced 13 or earlier.  Don't buy FileMaker any more.

        • 1. Re: Frequent crashing in FMP 14

          Joan Martensen:

          Thank you for your post.

          There is a known issue when switching from Layout Mode to Browse mode when displaying in List view and there is a grouped object.  Does this match your layout?  If not, let me know more about your layout so I can try to replicate the issue.

          FileMaker, Inc.

          • 2. Re: Frequent crashing in FMP 14


            LAYOUT WORK:

            1.  I've crashed multiple times today while working on a FORM layout, not a LIST.

            2.  The layout probably features grouped objects.  I use those heavily.

            BROWSE WORK:

            1.  Multiple times in last few days, I tried to copy text from one field and paste it into another field.  When I hit "paste", nothing happened.  I re-copied and re-pasted and no results ever appeared.  Like the computer didn't have a functional clipboard.  The only cure was to quit FMP and relaunch.  Then suddenly, everything was fine.

            This does amend my first report.  I said even Browse mode was crashing.  That was wrong.  It does not crash.  It just plays deaf.

            • 3. Re: Frequent crashing in FMP 14

              Joan Martensen:

              I'd like to see a copy/clone of the database file so I can work with it here.  Check your Inbox at the top of this page for instructions where to send the database file.

              There is a known issue with Apple under Mavericks (Mac OS X 10.9.x) and Yosemite (Mac OS X 10.10.x) where some of the keyboard shortcuts fail to function.  Generally, you will see this with command-L (Layout mode), but it can also occur with command-C (Copy) and other command keys.  The next time this occurs, look under the Edit menu and see if the keyboard shortcut for Copy is present.  If not, select "Copy" from the Edit menu, and also select "Paste" from the Edit menu.  If this works, then this is the OS shortcut issue, and quitting and Relaunching FileMaker are the known workarounds.

              FileMaker, Inc.

              • 4. Re: Frequent crashing in FMP 14

                I decline your invitation to upload my database.  It contains privileged information, including Social Security Numbers, etc.




                I will not be submitting it.

                If there is a known problem with shortcut keys working, then that is probably the cause.  I use them heavily, since 25 years of working with FMP on a daily basis has led me to the obvious shortest ways to get things done.  Also, I've already lost 4 hours of work today to the constant crashing.  So, I'm working exclusively in FMP 13 now.   Please put me on the notification list for when there is a fix to this crashing problem.  Until then, I won't be using FMP 14 again.







                • 5. Re: Frequent crashing in FMP 14

                  They don't need your data, just the file. You can use save a copy as to generate a clone (no records) copy of your file to upload for their examination and then no sensitive data should be present in the copy that you upload.

                  Hope you encrypt that file if it's storing stuff like SSN's.

                  • 6. Re: Frequent crashing in FMP 14

                    Thanks Phil.  I realized the same thing as soon as I posted my last comment.  I've sent a clone.

                    Basically, I'm just fuming mad at having to constantly battle all the unnecessary awkwardness of FMP 14.  At this point, I'm too furious to even think straight or vent my frustrations coherently.  (Good thing it's Friday and I get a few days to decompress.)


                    • 7. Re: Frequent crashing in FMP 14

                      Joan Martensen:

                      File has been received.  It opens to the Home layout.  Is the layout where the crashing occurs?  Are there any specific objects that seem to trigger the crash when edited in Layout Mode?

                      When an update to FileMaker Pro is released that resolves this crashing issue, I will let you know.

                      FileMaker, Inc.

                      • 8. Re: Frequent crashing in FMP 14

                        "When an update..."???

                        That would seem to be a pretty strong indication that this is an FMP 14 bug...

                        • 9. Re: Frequent crashing in FMP 14

                          Today, I was working on the form view layouts:  "Lease - Form", "Tract - Form", and "File - Form".  I was adding a large gray tab object to each, putting portals on the tab object, and count fields on the actual tab part (the part that sticks up above the rest of the tab object).

                          However, if memory serves, several of the crashes happened while I was working with list view:  "Lease - List", "Tract - List", and "File - List".  It's hard to remember the details, since there were so MANY crashes.


                          • 10. Re: Frequent crashing in FMP 14

                            While you are at it, you might want to fix the bug that prevents fields from being pasted into portal rows.  That's been going on since FMP 13 (if not FMP 12).  Draw a portal.  Then take a field from outside the portal and cut-and-paste it into the portal.  Use the alignment tools to put it at the top of the portal, aligning with other fields that display correctly (positioned one pixel below the top of the portal).  When you flip into Browse mode, the field you cut-and-pasted displays only on the first row of the portal.  You must go back into Layout mode, select the cut-and-pasted field, and use the arrow keys to move it a few pixels down and/or over, then back again.  The field will then display correctly.  Why do I have to do the box step with arrow keys to get a field to display?  The box step belongs ONLY on the ballroom dance floor!

                            • 11. Re: Frequent crashing in FMP 14

                              It's not the copy/paste that's the problem. It's using the alignment tools to pull the field inside the boundaries of the of the portal row. If the paste (just tried this BTW), pastes the field such that it is fully inside of the borders of the portal row, you don't have to drag the field in order to get the portal to "own" the field.

                              Granted, given the typical narrow height of a portal row and the imprecision involved in pasting an object into a portal row, you are very likely not to succeed in getting that layout object fully inside the portal when you paste it, but technically, it's not the paste, it's the alignment tools.

                              This is something that has been previously reported.

                              For More Information see:     Portals and Tab Controls fail to "own" enclosed objects

                              This is one of many acknowledged bugs that can be found in the Known Bug List thread here in the Report an Issue section of the forum.

                              It can also be downloaded as a database file from:    https://www.dropbox.com/s/jt09b82i0xijbu3/FMP%20Bugs.zip

                              • 12. Re: Frequent crashing in FMP 14

                                Good to know.  Doesn't help a bit, though, since who ever allows extra distance above or below the fields in a portal row?  That's precision territory with a zero-pixel tolerance.  You'd think they would have fixed THAT bug several years ago.  Why don't the alignment tools to their job?  We shouldn't have to learn the myriad workarounds to get the software to do its job.  It should work as advertised in a consistent and logical manner.  Somebody doesn't write their software correctly.

                                • 13. Re: Frequent crashing in FMP 14

                                  The best solution now is to paste to a location away from the portal row and then use the mouse to drag it into position, only releasing the mouse button when you are sure that the object is fully inside the portal row borders. The alignment guides that popup can help you tell. Then use the alignment tools to "fine tune" it's position if necessary. And sometimes, resizing the pasted object to a smaller size before dragging then resizing it back after the portal row "owns" it, makes the drag into position action easier to do.

                                  And note the discussion in the other thread asking FileMaker to take care in how they "fix" this issue. There are times when you want to put a field on top of a portal row without it becoming part of it. Currently, the alignment tools are the only way to do that.

                                  And the whole process is very "finicky". In one of my layouts where I needed a field in the upper right corner of the first portal row only, I lost count of the number of times that I attempted to make a layout adjustment only to have the object "grabbed" by the portal row when I didn't want it to.