Differnce between FM Dev 5.5 and FM Dev 6?

[gwmbox]

Hi all

Can anyone tell me what the difference is between FM Dev 5.5 and FM Dev 6? Is there any real benefit in going to v6?

Thanks

Greg

[CobaltSky]

Hi Greg,

The features which differentiate FMP and FMD did not change in any significant way between 5.5 and 6.0, so the advantages that FMDv6 has over FMDv5.5 are much the same as the advantages that FMPv6 has over FMPv5.5. The main additions were:

- The ability to import a folder of image or text files

- XML Import and Export capablities

- A 'Format Painter' option in Layout mode

- A new 'Find and Replace' feature

- Custom Dialog Boxes

- New Find commands to Constrain and Extend the found set

- Multimedia and Digital Image Import options

Essentially, FMDv6 can produce runtimes that have all of the above capabilities in addition to the capabilities provided by FMPv5.5. However if you don't happen to need any of the features added with version 6, then you won't see a lot of difference.

[gwmbox]

Thanks for that - nice additional features - but probably not enough to move to - guess I'll just wait to see what v7 will have to offer?

[BobWeaver]

Also, some of the complex layouts you created in 5.5 will no longer work in 6. Ugh, I just discovered that one today.

[Anatoli]

Bob, could you be more specific? Please

[BobWeaver]

I had some list view layouts that I developed in 5.0 and 5.5 where the bottom of the some fields extended from the body down into the subsummary or footer part. On 5.0 and 5.5, the field would simply overlap into the following record which is what I wanted. In version 6, it expands the body part so that there is no overlap. Yuck!

Admittedly, this was an undocumented characteristic, but then again, 90% of Filemaker's behaviour is undocumented.

Since I just discovered this problem, I haven't had time to fully investigate all the consequences. Maybe there is some workaround.

[Anatoli]

I wouldn't dream of pushing FM in undocumented "gray" area even if it works in current version I am not adventurous type

[BobWeaver]

Unfortunately, Filemaker rarely specifies how a lot of functions behave even under normal circumstances unless you are lucky enough to find a technical note on it. That's why I said 90% of Filemaker's features are undocumented.

[Anatoli]

Apart of calculated portal, which I've never used I don't know any I am very simple person and I love quiet life.

[CobaltSky]

Methinks that Anatoli doth tease.

He knoweth more than he doth confess.

[BobWeaver]

I think so too.

[Anatoli]

I am dead serious!

OK, I am not so serious, but I am always the "worrying type". What if... and if they will... and so on

[BobWeaver]

I worry too. I always worry about every different way that a solution could possibly break. So, I don't go using undocumented features if there is any other way of accomplishing what I need to do, but sometimes there is no other choice.

This one particular database has existed since version 2.0. I had to redesign it when version 3 came out because v3.0 wouldn't allow you to set the stacking order to have containers in front of regular fields. Then, I redesigned it again when version 5 came out for other reasons that I can't remember anymore. Admittedly, this is one extremely complicated layout. So, I accept the fact that it will require redesign with each new release of FM.

[Anatoli]

One sin of mine exists since version 1.

Other since v. 3 and I didn't change a bit

[CobaltSky]

Many things broke with the release of version 3.0 - which is no doubt partly because it was such a significant change - including modifications to the underlying organising principles of the file format. Many things were re-engineered at that time.

The next version, if it entails a thorough overhaul (as is mooted) may bring a similar range of issues to the surface.

But notwithstanding that, I take a slightly different view to the one being expressed here.

Many features work with some versions and not others. Custom dialogs will not work with any version earlier than 6.0, for instance, but that is not a reason not to use them in some instances. If their implementation changes with subsequent releases, some of the code may have to be revised. The same is true of 'undocumented' features.

As Bob says, if you only ever do things that are described in detail in the manual, you are limiting yourself to something like 10% of the scope of the application. Many things that are described on this forum on a daily basis would then be off limits.

Let me give an example. The API which is used by plug-ins was originally designed only to support calculations (so third party vendors could add extra calculation functions to the base repertoire). Almost all the functionality provided by plug-ins (including some of those the FMI themselves bundle with the program) constitutes 'undocumented behaviour'.

I *know*, for instance, that Anatoli uses and recommends the DialogMagic and SimpleDialog plug-ins and *every single function* provided by each of them is exploiting undocumented behaviour of the FileMaker application (undocumented by FMI, that is).

All up, there is so much that has been documented by others - but does not rate a mention in the official manuals that come with the application, that it is quite a job at times at times to keep track of exactly what is 'officially sanctioned' use of the application and what isn't...

[BobWeaver]

Ray, fortunately, enough of these undocumented features end up being documented by others, as you say, and become so well used that FMI would have a difficult time altering their behaviour. Some of the other undocumented things that have been around for a while:

Hidden portal trick;

Global field validation trick;

Self updating field trick (as used by the various audit trail routines)

and on and on...

And it seems to me that even multi-keys are undocumented. I could be wrong here, but I don't ever remember seeing them mentioned in the manual.

[CobaltSky]

Hi Bob,

Actually, multi-keys do rate a mention in the official documentation in recent versions (at least as far back as 5.0), but I beleive you may be correct that in earlier versions they didn't.

Broadly, though, I agree with you and I believe it's true that folks at FMI are at pains to provide 'forward compatibility' for as much functionality as they can - including much which is 'out there' but may not form part of the core 'documented' feature set.

Despite this, I would not be at all surprised if it turns out that many (or even most) plug-ins need to be re-issued in revised form before they will work with the next version. And I fully expect to see a few casualties in the form of some plug-ins that can no longer be made to do all the same things they have done in the past. There may even be a few that become largely redundant.

The same may well be true of functionality which is internal to the application - including a proportion of 'documented features'. Any significant new directions for the application will carry a cost of this type.

Irrespective of that, I take the view that whatever works is worth using. On past experience, when something no longer works as intended with a new release, it's rare that there isn't an alternative way to deliver the same (or sometimes improved) functionality in the new version. It's all part of the 'adventure', as I see it.

[BobWeaver]

And what an adventure.

[Anatoli]

True. You are absolutely right... I love the plug-ins analysis