Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 5933 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

I'm an old hand at FMP6 and am still in the process of learning the very different world of FMP9 relationships. In FMP6 I could do a self-relationship with a global on the left side, a field on the right and then perform an IsValid(relationshipname) to evaluate whether there was an available match.

However in FMP9 I haven't yet been able to find a reliable technique. I've tried both IsEmpty and IsValid. I've also tried both TOs involved in the relationship, and in each TO have tried matches to the global and the target field.

In all instances I'm getting negative results both when there should be a match and when there shouldn't.

Obviously I'm misunderstanding something. Need some help.

Appreciated,

Posted

I think you best get the hang of the different concepts by making a tiny template in fm6 and then migrate it. It puzzels me slightly since it's business as usual IMHO ... perhaps you need to study this:

http://www.digfm.org/ref/FM7_key_concepts.pdf

--sd

Posted

I think you best get the hang of the different concepts by making a tiny template in fm6 and then migrate it. It puzzels me slightly since it's business as usual IMHO ... perhaps you need to study this:

http://www.digfm.org/ref/FM7_key_concepts.pdf

Appreciate the guidance. The FMP6 test file converted just fine and works perfectly under FMP9. However using the identical structure in my working solution doesn't.

Using the DataViewer I'm getting an error. Which leads me to suspect in FMP9 that scripts are also tied to a particular table. Although there's no tools to set the context of a script (I've discovered so far) and nothing to indicate the current context of a script.

Since context is so very important in FMP9 it seems odd that there's nothing in the status area of layouts to indicate the current context of a layout and nothing I've seen so far to indicate context of scripts (if my above surmise turns out to be the case).

Thanks for the help.

Posted

Before getting into your problem deeper, must this be cleared away as a wrong assumption:

Which leads me to suspect in FMP9 that scripts are also tied to a particular table.

...in short they're not!!! But yes they used to be though.

The matters seen in the dataviewer however is pretty dependent on the perspective relationally speaking. Unstored values have no value until living or triggered by a layouts rendering. The perspective or aspect is dependent on which TO's layout you have in front of you.

Perhaps you should start elsewhere to understand what is necessary to tunnel values, and similar what won't work.

http://www.filemakermagazine.com/videos/graph-rules-four-rules-to-remember.html

...take a look at the video, to get the gist of the indeed different aspect.

--sd

Posted

The context of a layout is given by the table occurrence to which the layout belongs. It does not change.

The context of a script is determined at runtime. The same script, say:

Set Field [ Child::Value ; 100 ]

will set the value of the current record if called from a layout of the Child TO, the value of the first related child record if called from a layout of Parent, and it will generate an error if called from a layout of an unrelated TO. You can force the context of a script (or any part of it) by going to a specific layout before the rest of the action.

Posted

Before getting into your problem deeper, must this be cleared away as a wrong assumption:

...in short they're not!!! But yes they used to be though.

The matters seen in the dataviewer however is pretty dependent on the perspective relationally speaking. Unstored values have no value until living or triggered by a layouts rendering. The perspective or aspect is dependent on which TO's layout you have in front of you.

Perhaps you should start elsewhere to understand what is necessary to tunnel values, and similar what won't work.

http://www.filemakermagazine.com/videos/graph-rules-four-rules-to-remember.html

...take a look at the video, to get the gist of the indeed different aspect.

I solved it by creating the global field used on the left side of the relationship into the table controlling the layout and revising the graph accordingly. Suddenly the relationship works and I have now a clearer sense of what's going on.

Meanwhile a colleague told me to run a Go to Layout step within the script to establish the relationship for the IsValid step. I can see how that would also work. But I prefer the way I actually did it because it's clearer, more regular.

I like the new structure because it appears to support tunnelling and much more complex relationships than FMP6 ever did. It also enforces more regularity, which is also a good thing.

Am still getting my sea legs on this pitching ship. ;-)

Kind regards,

This topic is 5933 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.