I saw some weird stuff with Tab label formatting too. Formatting lost it's bold and conditional colours....
Sent from my iPad
11th Hour Group Pty Ltd
If you edit in 13 custom dialog lables created in 12 with any kind of formula, when you come back into 12 that label is blank.
Ouch. The ramifications are this are serious.
When then are no custom dialog labels present the system display an OK button as default, the users will not have the second or third option available. You only have to imagine a custom dialog to delete a record/portal row. If the default button was delete and the second option was cancel the user will be unable to cancel, they are forced to delete records.
Have you reported this as a bug?
The warning is well made and should be noted. FileMaker Inc., strongly recommends that if you choose to develop in a mixed environment with v12 and v13 clients, that you only develop in v12. This is not a bug but a compatibility issue between versions.
FileMaker Inc., strongly recommends that if you choose to develop in a mixed environment with v12 and v13 clients, that you only develop in v12. This is not a bug but a compatibility issue between versions.
Thanks for that info, David,
This really means that, for developers, v12 and v13 files are completely incompatible, doesn’t it? We will have to maintain very strict boundaries between fmp12 files that are only for use in fmp12. What’s more, we’ll have to maintain this vigilance from now on. All v12 systems are in danger of being inadvertently corrupted by developers.
The real danger that I can see is that a file is opened in v13 accidentally, not deliberately. On my Mac fmp12 files are now automatically opening FMP v13. I am already making the error of using v13 to edit files that will go back to a client running v12.
I know that there is a new flag which allows us to specify the minimum version which can open a file but to protect these systems we need an equivalent “max version” that will warn us not to proceed. Surely this is possible: if a file does not contain v13 objects it can be flagged internally as v12 only. If the developer makes changes which invoke v13 objects they can be warned and offered the chance to revoke the changes before they are saved.
Absolutely! I've made that mistake before with previous versions and if you get really carried away and use for eg the Append to PDF in v8 then realise down the track you needed v9 there is suddenly a big problem... (It helps if the client doesn't lie to you about the version they are using)
It would be great to have a dialog on opening that says "this file contains features not suited to versions 13 or below.... Do you want to quit?"
I was surprised to see another developer use his 13 to make mods in a master which for the foreseeable future will only be used in 12. I have never encountered problems doing this... but I would wait for some time until the v02 release before opening the master.
I've been thinking I might get a new mini just for 13 so there are not crosses wires....
should read "no crossed wires"...
sorry for the extra post but you can't edit on an iPad!
Absolutely! I've made that mistake before with previous versions and if you get really carried away and use for eg the Append to PDF in v8 then realise down the track you needed v9 there is suddenly a big problem…
There is a difference here. You could edit in v8, v9, v10, v11. People with earlier versions didn’t have access to new features. That made sense. Care had to be taken with newer functions like List() but it was still obviously a v9 thing and it could be flagged as such., you could write a less than 9 version to allow backward compatibility. What’s more, you didn’t lose data. You simply had to open the file with the correct version and you’d find all your code was there.
Custom Dialogs are core functionality that have been with us from day one. The change is destructive. When the file is opened in v12 the custom dialog labels are lost.
The change to the functionality of custom dialogs should have been implemented in v12 with the new file format.
Sure... I get the difference... Nothing used to break but rather just be unavailable in earlier versions.
The "Max version" flag you propose would cause an issue for Go clients - you can't get Go 12 in the App Store anymore.
One question about this behavior. I think people are freaking out a little bit.
I understand that if you use some specific v13 features like calculated button and tab labels, that they won't work in v12, which is unfortunate. But is there really so much cause for alarm "that a file is opened in v13 accidentally, not deliberately."? As long as you have the mindset that you are developing the solution for v12 clients, and avoid using the v13 specific features, merely opening your v12 file in v13 shouldn't break anything, should it?
I don't think you understand the issue. It doesn't happen when you open the file. It happens when you open the *actual* Show Custom Dialog script step. You even can edit the rest of the script just fine.
There are also other issues with Show Custom Dialog on the iPad. If you are using input fields in the dialog you can no longer tab between the fields. The Return key on the keyboard no longer changes to a Next button as it did in FM Go 12. If a user taps the Return button it will but a new line in the field which is a very undesirable behavior for a dialog box.
The issue is this: it will depend on the developer. We have to treat the files differently. And how do you differentiate? What if you aren't told, or you are given the wrong information accidentally?
I have already seen this occur. I had v12 and v13 open and the file opened in v13. The script I handled lost its custom dialog buttons when it was opened in v12. It was a script that handled user passwords, so an important script to have runnning properly. Instead of saying "Do you wish to reset the user password? OK Cancel" it only offered an OK button. Yikes.
When this "version incompatibility" arises (god forbid we should call it a bug) the internal code asserts an OK button and it is the default. That enables the user to get past the dialog box but they only have the default option and no label to guide them.
That's right, you have to open the show custom dialog script step.
Custom dialogs are typically used to offer the user choices, especially the chance to opt out, which is important when the code can be triggered by accident in the user interface. The bug leaves you with no choice. You don't need to think hard to see that this can be serious:
"Oedipus, to realise your desire for your mother you have opted to kill your father. Proceed? OK"
"God, All the precursors forecast in the book of revelations have been completed. Start Armageddon? OK"
Everyone from the Ancient Greeks to The Almighty use FileMaker Pro? Why isn't that in their marketing???
Sent from my iPhone