http://thefmkb.com/10084 has a lengthy list of behavior changes in the new version from previous ones.

Steven

A couple of key behavior changes that are worth mentioning here...

Unstored calculation field evaluation changed

Some customer solutions assume that an unstored calculation field will be evaluated when a layout containing the field loads, even when that field is completely hidden by other layout objects.

To improve performance, FileMaker Pro 12 will generally NOT evaluate an unstored calculation field that is completely hidden on a layout. Similarly, if the unstored calculation field's result never needs to be drawn (e.g., due to field width or height of 1-2 pixels) or is never needed for conditional formatting or another calculation, the unstored calculation will never be evaluated.

An unstored calculation field is evaluated at least once if that field's text (or a calculation dependent on it) is displayed on a layout.

Show Custom Dialog changes

In FileMaker Pro 11 data was only set into the database if the default button was clicked. Data was not set into the database when clicking on buttons other than the default button i.e. button 2 and button 3. If the default button was not configured (no name), there was no way to commit data. If you renamed the default button to “Cancel” and button 2 to “OK” the result was unexpected as Cancel set data while OK did not.

In FileMaker Pro 12 you can now specify which buttons in the Specify Custom dialog box commit data to a database, and the priority for each button.

Three check boxes were added to the General panel of the Show Custom Dialog Options dialog that allows the user to decide which button(s) set data into the database (the Default button is selected by default):

Importing data from

FileMaker Pro no longer imports data from fields that were added or changed after field mapping was defined in the Field Mapping dialog box. Data is imported only from fields specified during the original import mapping.

The previous import mapping ( at runtime and design time ) automatically added fields to import into if they have been added after the import was defined, and the source has enough fields to pull data from. Also, there had been some reports that adding/removing fields from the SOURCE file (fmp format) "messed up" a pre-defined import ( at runtime and design time ).

In FileMaker Pro 12, if a field is added to the destination, it is not set to import into, just because there is a source field available. This avoids developers from updating all the imports in all their scripts in all their solution files, just because they added a field to the destination FileMaker file. Also, when importing from a FileMaker format file, the keys are stored along with the order. When resolving the mapping, if the key of the nth destination field doesn't match what's in the file, that entry is treated as no-import.

A side effect of this new behavior is the first time an import is performed for that file, the user has to explicitly turn on each field to import into, as opposed to the legacy behavior of the user having to clear out fields they don't.

Conversion: FileMaker Pro 12 is unable to detect what the keys were for existing imports from a FileMaker file since that information is only available when the order was last made/modified, but the first time the order is modified it is updated with the current field keys in the file.

When switching to a different source table when altering the import order in the UI, the stored import order is thrown away for the table. So re-selecting the original source table acts as normal/legacy. Also, when manually importing from FileMaker files in the same session, you may see "" entries if subsequent source files have less fields.

One BIG Undocumented change: object appearance effects no longer exist!

By this, I mean that Filemaker Pro 1-12 object appearance effects (embossed, engraved, drop shadow) have been killed off in Filemaker Pro 12. Object Appearance effects were replaced by Fill Solid, Gradient, and Image.

Bummer.

If you use these effects, your objects (fields, buttons) are now flat when converted. Interestingly, Filemaker Pro 12 does the conversion in some objects but not others - leaving you with an inconsistent appearance.

Can someone confirm this? ... that embossed and engraved are no longer available?

Huge impact here, if it's true.

In January, they announced that patterned lines were going away ... but there was no mention of field effects.

What a blindside swipe, if it's true. I'd hope there was an announcement somewhere. Did I miss it? And is there a "work around" setting or technique that doesn't involve moving the button definition and tooltip for every single button in the application?

Well on button objects, you still have the option of embossed. ( dont forget to remove theme application on the object ).

However, drop shadow and engraved are no longer available.

On other objects such as fields, rectangles, circles, etc, all 3 seem to have been removed.

A webinar that I attended spoke to this very thing. Haven't had a chance to check out the button situation yet, but what they said was, whatever buttons you have created in a previous versions and converted, will retain those patterns. However they are no longer available for new stuff.

... on button objects, you still have the option of embossed

That's good to hear! What a relief!

Now, will it let me take an embossed button (created in FM11), replicate it elsewhere on the layout and give it a new definition? That is the kind of workaround that I was talking about. That would allow me to keep the application moving forward while I design new layouts using the new features.

Thanks for both responses.

... buttons you have created in a previous versions and converted, will retain those patterns...

BTW, as one workaround, you can copy and paste buttons created in other versions, but you can not change their names. So, I would not label them unless you have a name picked out.

Lee

Thanks, Lee.

That gives me an idea: keep FM11 handy as a Button Generator for legacy apps. I'm not saying I want to avoid using the new features, only that these things take time ... yet some things can't wait. (I hope that makes sense.)

Yep.

Will FM 12 stil use the *fp7 file extension? For example, will it open FM 11 files automatically without the need for file conversion?

Will FM 12 stil use the *fp7 file extension? For example, will it open FM 11 files automatically without the need for file conversion?

I've answered my own question:

http://www.filemaker.co.uk/products/filemaker-pro/conversion.html

Can someone confirm this? ... that embossed and engraved are no longer available?

Huge impact here, if it's true.

In January, they announced that patterned lines were going away ... but there was no mention of field effects.

What a blindside swipe, if it's true. I'd hope there was an announcement somewhere. Did I miss it? And is there a "work around" setting or technique that doesn't involve moving the button definition and tooltip for every single button in the application?

You can create new buttons in FM12 that have the embossed effect. All you have to do is create them in a layout that is using the "Classic" theme.

That said, there are much better options now. You can create much better looking buttons by using graphics in the buttons (and I am not talking about just placing a graphic over your button). In FM12 you can actually insert it into the button as a fill. You can also slice your graphic up (using the new slicing feature) so you can re-size the buttons without the image getting all distorted looking. I personally have not used this feature yet but it seems awesome.

That gives me an idea: keep FM11 handy as a Button Generator for legacy apps. I'm not saying I want to avoid using the new features, only that these things take time ... yet some things can't wait. (I hope that makes sense.)

No, let those fugly old embossed buttons go and embrace the new modern looking gradient buttons. :)

You can create new buttons in FM12 that have the embossed effect. All you have to do is create them in a layout that is using the "Classic" theme.

You dont have to do that extra step. All you have to do is remove the theme style on the button object. It is one button click on the Inspector.

HALBURN and Mr. Vodka: I'll have to see these things operate to understand exactly what you mean. I hope to have FM12 operating on a test machine next week. However, one of my applications has hundreds of buttons, so I've got to be careful what I change and what I keep the same ... at least for the near term. Long term, the graphic features sound great.

one of my applications has hundreds of buttons, so I've got to be careful what I change and what I keep the same ... at least for the near term. Long term, the graphic features sound great.

The themes in FM12 work a bit differently than in previous versions. In FM12 you can change the theme for your layout "after" the layout is created. If you have a solution with hundreds of buttons on a layout you can apply a theme to all them and change them all with a single click. The new buttons also support rollovers which (similar to designing buttons on a website) you can define how you want them to look.

One of the biggest pains in FM 12 is that selecting objects in Layout Mode selects anything that is touched. Previously, you have to totally encompass an object before it is selected. This allows one to be highly selective of what one selects. Now, I have to be really careful since background objects can inadvertently be selected. I have to do a lot of click selections now, instead of lasso'ing them. It take a lot more work now to select items than before.

One of the biggest pains in FM 12 is that selecting objects in Layout Mode selects anything that is touched. Previously, you have to totally encompass an object before it is selected. This allows one to be highly selective of what one selects. Now, I have to be really careful since background objects can inadvertently be selected. I have to do a lot of click selections now, instead of lasso'ing them. It take a lot more work now to select items than before.

You can get back the old behaviour by pressing the Cmd key (on Mac, don't remember what's it under Windows). This means that the toggle effect of this key has been reversed from the old behaviour, where pressing the Cmd key meant that a mere touch of an object was sufficient for it to be selected. Of course, this is going to be fun when you regularly switch between FMP 12 and older versions…

You can get back the old behaviour by pressing the Cmd key (on Mac, don't remember what's it under Windows). This means that the toggle effect of this key has been reversed from the old behaviour, where pressing the Cmd key meant that a mere touch of an object was sufficient for it to be selected. Of course, this is going to be fun when you regularly switch between FMP 12 and older versions…

Thanks. This was driving me nuts. It is a change that was entirely unnecessary.

"The new behavior is consistent with Apple's user interface guidelines -- it's how selection works in the OS X Finder, for example."

(Source: NZ PCWorld article)

FWIW.

One of the biggest pains in FM 12 is that selecting objects in Layout Mode selects anything that is touched. Previously, you have to totally encompass an object before it is selected. This allows one to be highly selective of what one selects. Now, I have to be really careful since background objects can inadvertently be selected. I have to do a lot of click selections now, instead of lasso'ing them. It take a lot more work now to select items than before.

I was just coming in to mention this. Annoying

You can get back the old behaviour by pressing the Cmd key (on Mac, don't remember what's it under Windows). This means that the toggle effect of this key has been reversed from the old behaviour, where pressing the Cmd key meant that a mere touch of an object was sufficient for it to be selected. Of course, this is going to be fun when you regularly switch between FMP 12 and older versions…

It's Control in windows /last of the diehard windows users

You can get back the old behaviour by pressing the Cmd key (on Mac, don't remember what's it under Windows). This means that the toggle effect of this key has been reversed from the old behaviour, where pressing the Cmd key meant that a mere touch of an object was sufficient for it to be selected. Of course, this is going to be fun when you regularly switch between FMP 12 and older versions…

Whew, thanks for the tip. I wish there was a way to reverse the default behavior.

One BIG Undocumented change: object appearance effects no longer exist!

By this, I mean that Filemaker Pro 1-12 object appearance effects (embossed, engraved, drop shadow) have been killed off in Filemaker Pro 12. Object Appearance effects were replaced by Fill Solid, Gradient, and Image.

Bummer.

If you use these effects, your objects (fields, buttons) are now flat when converted. Interestingly, Filemaker Pro 12 does the conversion in some objects but not others - leaving you with an inconsistent appearance.

I just changed the Pen Width to 1pt on the fields, and it looks just like it did before...

Couple things... and this is in the first 30 minutes of use...

1. This may just sound like complaining, but WHY remove the engraved and embossed effects. In reality, FileMaker Pro 12 still actually knows what they are and what those effects are called. If you convert a file that has a field that uses the engraved effect, for example, the effect imports, AND the line style actually lists "engraved," but engraved is in grey. If you change it, you lose it... and, of course, you can't apply it to objects that don't already have it. FileMaker... if you're going to actually make FMP 12 understand the style, why not LET US USE IT! It makes no sense except for some paternal, "we don't want you to design layouts that way." My layouts have always been more professional than FM sample files and layouts... It's one thing to not give us features we've wanted as developers (I'm WAY used to that)... but to take something away that's so pervasive throughout our databases (even though the app COULD easily let us use it as it knows what it is and how to render the effect) makes NO sense. So... now I have to keep FMP11 open and copy in fields so I have the effect (or duplicate fields within the file). Thanks for really slowing my efficiency FM... thanks a lot.

2. Does anyone know why filling a field with a graphic leaves a one point border (or greater if the field has rounded corners) inside the field boundary? This has happened with previous versions before and had to be fixed. Is it something I'm missing? FMP 11 did NOT do this. I'm attaching an image with FMP 11 on the left and FMP 12 on the right showing what I mean. Note... in both files the image has been stretched to fit the size of the field.

Sigh... I'm sure I'll be posting more as it comes up.

Thanks all.

When View > Show > Sample Data is checked, FM11 would evaluate conditional formatting of a text object; FM12 does not.

I used to use the calculation Get( WindowMode ) = 4 in conditional formatting of a text object to make it visible in layout mode, but not anymore!

This still works as it used to for conditional formatting of fields.

Strictly speaking, the FMP Functions references says:

Get( WindowMode ) = 4 is (FileMaker Pro Advanced) if evaluating the function from the Data Viewer and the current window is in Layout mode

You can get back the old behaviour by pressing the Cmd key (on Mac, don't remember what's it under Windows). This means that the toggle effect of this key has been reversed from the old behaviour, where pressing the Cmd key meant that a mere touch of an object was sufficient for it to be selected. Of course, this is going to be fun when you regularly switch between FMP 12 and older versions…

Ctrl on Windows

In regards to the new Get(UUID) function... it's important to note that DUPLICATING a record does NOT generate a new, unique ID, whereas the serial number function would. I see this as a huge oversight that is bound to break a lot of old databases that have been updated to use the Get(UUID) function and for developers who are used to duplicating records and develop that way, the integrity of their databases will certainly be in jeopardy.

As I personally strictly follow rules for having a unique key on every record of every table, no matter WHAT I use the table for, this really means I can NEVER duplicate a record, and it kinda would be helpful to be able to disable the duplicate function. If it can't be done because of how auto-inserting calculations works, UUID functionality should be an optional part of the "Serial Number" function.

UPDATE: OK... as I thought about it I realized you have to UNCHECK "Do not replace existing value of field (if any)" which was NOT the suggested way to set your unique key field up. I guess there should be some discussion about how this affects the integrity of the unique key and if it's POSSIBLE that it could get unintentionally changed by leaving this unchecked.

Just my 2 cents on the object attributes 'embossed' 'engraved' 'drop shadow'.

Upon update all the objects will keep their attributes unless you decide to update the layout or each individually.

You can use the format painter to move these attributes to other fields and it works, and one new thing that I personally like is that

you can drop the line to ANY fraction of 1 and it will do it, even though they only give you .25 in the drop down. The corner radius still

works as well.

so even though they are technically not available to newly created objects, you can still paste objects with those attributes into your file and then

copy them over to new objects.

I personally like the dimensional effects these attributes give the interface and will still use them where I feel that subtle difference is more

appropriate than a color change. Some people react negatively when there are too many colors on the screen.

so...... while the new features give you many more options for object attributes, it doesn't necessarily mean better looking layouts.

Fonts convert but revert to default upon editing in FM12 DB layout

Fonts convert FM7 (file format) to FM12. (and the font characterists seem to be better followed, point sizing and similar characterists)

FM7 (file format) and prior the converted DB file would display the field's stored / programmed / set font if a filed was selected. I could configure / more fonts for a DB from the layout mode.

FM12 (file format) the converted DB coverts the field's font. The issue arrises when modifying a layout. If one modifies the field.AND the font is not configured (listed as an active font) for the specific DB (listed), the default font is immediatly assigned. (One personal file, I do backwards. I add / configure the fonts after I open the DB. I had to pull my font listing from 4 August 1996 to get the font list.)

Font names / a font stored but not available in FM12 DB layout

My August 1996 font list included Helvetica Narrow. Type 1 (windows .pfm) font is not available in FM12 configure / more fonts. I have this font in several FM7 (file format) layouts. Helvetica a Type 1 is listed and FM12 accepts but Helvetica Narrow a Type 1 font is not listed. (Windows 7 is not configured to hide fonts. All my hundreds of fonts a loaded.)

Just found something tonight that is kind of a pain and don't remember seeing it discussed. When I select multiple objects the Inspector no longer shows all of the coordinates of the selected objects. For instance if I select 4 buttons in FM11 the Inspector shows the Top, Bottom, Left and Right coordinates of the objects selected. In FM12 it puts a - in the area for Top, Bottom, etc. depending on what is selected. I can get around the issue by grouping the objects, but if I am copying elements from one layout to another and want them in the same position I would rather not have to Group/Ungroup every time.

Just found something tonight that is kind of a pain and don't remember seeing it discussed. When I select multiple objects the Inspector no longer shows all of the coordinates of the selected objects. For instance if I select 4 buttons in FM11 the Inspector shows the Top, Bottom, Left and Right coordinates of the objects selected. In FM12 it puts a - in the area for Top, Bottom, etc. depending on what is selected. I can get around the issue by grouping the objects, but if I am copying elements from one layout to another and want them in the same position I would rather not have to Group/Ungroup every time.

I did not like the new behavior at first either but after using FM12 for the past month I have found myself frequently using this new sizing option that we did not have in FM11.

Some graphics apps provide a facility whereby clicking and object with a designated key held down progressively selects objects 'down' through the layers - this would be a very useful feature in FM

I did not like the new behavior at first either but after using FM12 for the past month I have found myself frequently using this new sizing option that we did not have in FM11.

Sorry, what new sizing option are you referring to?

A change that is a KILLER for us: FM12 no longer has PHP Assistant... Example: http://catechinventory.capitolabs.com/

Also: Everything we do in FM12 is slower, whats up with that?

We spent weeks attempting to convert to FM12. Our Techs spent hours with on-line FM support, the program has a lot of new features we like but the downside is speed. We feel that FM12 is not ready for prim-time yet. We are waiting for fix updates.

Hi, here are few of my observations since upgrading to 12. Anyone have any fixes.

 

1. Holding down ALT (mac) to copy items does not give you all the guide help (all the blue arrows etc to help you place it.) You have to copy it, release the mouse then move it before you get the guides to help you.

2. When selecting all, you dont get to see all the items and where they are, you just get a big box around the whole selection. Useful when you have lost a little shape or text box on the layout somewhere.

3. Nudging items, you used to be able to nudge very small increments by holding down the CMD key and then use the keyboard arrows. It now will only nudge to the grid lines.

4. Aligning Text in fields to middle. I can get it to left right center but top middle bottom seems to just ignore what you tell it and goes to the top regardless.

 

Anyone found any solutions to these?

Just found something tonight that is kind of a pain and don't remember seeing it discussed. When I select multiple objects the Inspector no longer shows all of the coordinates of the selected objects. For instance if I select 4 buttons in FM11 the Inspector shows the Top, Bottom, Left and Right coordinates of the objects selected. In FM12 it puts a - in the area for Top, Bottom, etc. depending on what is selected. I can get around the issue by grouping the objects, but if I am copying elements from one layout to another and want them in the same position I would rather not have to Group/Ungroup every time.

 

I recently built my first solution in FM12 after using FM since version 3. I hate that you no longer see the coordinates for the group of selected objects. I use that all the time to set things exacly where I want them. Sure, you can group and ungroup but why? Why add clicks? What exactly did we gain by taking away those coordinates???

I agree ... it is major pain. I read someone said that once they are selected just nudge them 1 px and the coordinates will display but that was in v12.0v2 ; it doesn't help me on XP anyway (in v3). There are so many incredible improvements in 12 with these new design elements and I am very impressed with 12 but they need to fix this issue. Currently I group/ungroup as well.

Hi,

I am getting very strange behavior of FM 12.On 1 of my portal 1 put delete button right side of portal and wheni am clicking ..button not working ...screen movesto left side of portal.

 

 

Please sort out if any one knows?

 

Thanks in Advance.

Hi Genelia,

I have not heard of this oddity mentioned before. 12 portals and tabs ( as well as other 'parts', I suspect ) now identify whether objects are within their realm. Objects properly within portals move and resize if portal moves and objects within tabs can disappear if you resize tab to smaller than its objects instead of objects simply popping outside the tab like prior versions. You can sometimes feel the 'drag' on your cursor when moving an object in or out of portal.

This new stickibility means that portals are sensitive when near portal border and sometimes objects completely within portal can be mis-identified as outside. This can happen when you have grouped objects and you paste and some objects are outside and some in ... when you ungroup, those objects inside can still be seen as outside. Most times, moving the object a few pt then back ( or cut re-paste ) fixes the issue or making object smaller to ensure it is completely within the lines on all sides, but I assume you've tried those things so this may not be your issue.

Next step would be providing screenshot in layout mode and then providing file itself if all else fails.

Well, I am moving us from 11 to 12 this weekend.  It seems way too good to be true...too easy.  I have found a couple problems, but nothing serious, yet.  Would have been nice if the conversion would just comment out Update Link.  Would it have been that hard?  I can live with it though.

 

I found one check box that "did not work".  It needed a change of line color, to see the X.  Odd but not a big deal.

 

Our Imports are slower.  Appears that Matching Field Names resynchs each time the import runs. That is actually good, just slower.

 

Something has to break, just because.

 

Will know on Monday & Tuesday.

Check your layouts, especially if they use sections of PDF files copied into them.check lines and borders. These were issues for me on complex layouts.

Thanks Rick.  I have checked most of them.  We do not have any PDF Docs embedded, that I know about.  We did have Word Docs embedded, but those got really, really ugly as Word advanced & the docs did not.  I replaced all that I could with Merge Fields.  Much cleaner.

 

We are built more on business functionality than appearance.  Will catch the rendering issues as they come.

 

Funny thing is that Management loves the new Gradients.  Break up those solid colors.  The People will love that.  Give their eyes a break. 

 

Only I.T. cares about 2 Gig of RAM Cache & Progressive Backups.  Geek Cool.

We are up & running.  Really smooth so far.  A few checkboxes needed a different pen color.  It appears to be a little slower on general navigation.  Users were not happy about the Paste function now bringing in original formatting, but Control-Z clears it.  Not a big deal.

 

Our bigger processes are really slow, twice as slow.  The Importing takes a lot longer now.  Not a big hit for us though.

 

Overall, A++ for the conversion.  We might have problems closing tonight, but everybody is working like nothing changed.