Function Names have changed

[JerrySalem]

Warning.

If you are developing a solution to be used by both FM10 and FM11 users, you will now have to take care to watch the GET functions.

The following get functions are have changed their names!

Get(PrivilegeSetName) function is now Get(CurrentPrivilegeSetName)

Get(ExtendedPrivileges) function is now Get(CurrentExtendedPrivileges)

Get(PortalRowNumber) function is now Get(ActivePortalRowNumber)

Open a file in FMP11, create a new script that uses these one of the new functions, then open it in FMP10. The 'new' functions are not recognized. (not forward compatible)

Even worse, open FMP11 now modify your new script to use either the old name or the new name. You can't use the old name in FMP11 since it is not a recognized function. (not backward compatible)

This is going to be a nightmare for those people who are using both 10 and 11. I know for me, get Priv set and get Portal row are two very used functions.

Any hints?

Jerry

[bcooney]

I can't tell you the sinking feeling I'm experiencing right now. OMG, I must have If [Get (PrivilegeSetName)..] everywhere!

[liltbrockie]

lol what on earth would be the reasoning behide this stupid name change other than to simply annoy users?!?

[hbrendel]

I just tried this out: the names are being converted between versions, so don't panic.

[bcooney]

Just ran a test. Thank God, it converts from FM10-FM11, and apparently from FM11 back to FM10.

What were you experiencing?

"Open a file in FMP11, create a new script that uses these one of the new functions, then open it in FMP10. The 'new' functions are not recognized. (not forward compatible)"

That, to me, would be backward compatibility--which apparently it IS!

[mr_vodka]

They changed it to make more sense with the way the evaluation has changed in the newer versions of 10 / 11.

[JerrySalem]

Doh!

get(PrivilegeSetName) function was replaced with Get(CURRENTPrivilegeSetName)

while I was testing this out I was inadvertently using get(ACCOUNTprivilegesetName)

when you substitute the correct get functions, everything works fine.

Nothing to see here. Please move on.

[Steven H. Blackwell]

All this and much more about changes in the Security Schema are discussed in the White Paper being distributed by FMPug and FM Forums. Click the Download PDF link at top of the page here.

Steven

[bcooney]

I'm resurrecting this post, because I just got bit. A script defined in FM11 using Get (AccountPrivilegeSetName) did NOT translate back to Get (PrivilegeSetName) in FM10! Instead, it had ""

Huh? Get (AccountPSN) does NOT translate back, only Get (CurrentPSN) does?

[comment]

Get (AccountPrivilegeSetName) did NOT translate back to Get (PrivilegeSetName)

Of course not: Get (AccountPrivilegeSetName) is a new function in version 11 and it doesn't exist in previous versions. The former Get (PrivilegeSetName) function is now named Get (CurrentPrivilegeSetName).

[HUIT]

For those who have a really mixed client version environment:

GetClientVersion(){

    GetAsNumber ( ( RightWords( Get(ApplicationVersion) ; 1 ) ) )

}



GetCurrentPrivilegeSetName(){

    If (

      GetClientVersion() < 11;

      Evaluate( "Get(PrivilegeSetName)" );

      Evaluate( "Get(CurrentPrivilegeSetName)" )

    )

}



GetCurrentExtendedPrivileges(){

    If (

      GetClientVersion() < 11;

      Evaluate( "Get(ExtendedPrivileges)" );

      Evaluate( "Get(CurrentExtendedPrivileges)" )

    )

}



GetActivePortalRowNumber(){

    If (

      GetClientVersion() < 11;

      Evaluate( "Get(PortalRowNumber)" );

      Evaluate( "Get(ActivePortalRowNumber)" )

    )

}

I wasn't sure how forwards compatibility would work with versions < 10, so I decided to write the custom functions listed above.

[comment]

GetCurrentPrivilegeSetName(){

    If (

      GetClientVersion() < 11;

      Evaluate( "Get(PrivilegeSetName)" );

      Evaluate( "Get(CurrentPrivilegeSetName)" )

    )

}

That's a rather dangerous proposition - because you will get different answers in different versions. Thus what's forbidden in version 11 may be allowed when the file is opened in version 10 or lower.

[HUIT]

That's a rather dangerous proposition - because you will get different answers in different versions. Thus what's forbidden in version 11 may be allowed when the file is opened in version 10 or lower.

I'm not sure I follow. Could you give me a scenario where one would get differing results in differing versions? The definitions of these functions in versions 10 and 11 seem to be almost identical, with no apparent difference (to me) in actuality.

[comment]

Sorry, I have misread your post. But then the function is entirely redundant: if you define a calculation using Get(PrivilegeSetName) in version 10 and open the file in version 11, you'll see that the formula is now using Get(CurrentPrivilegeSetName) - and vice versa. Likewise for the other two - all that work has already been done by Filemaker.

[HUIT]

if you define a calculation using Get(PrivilegeSetName) in version 10 and open the file in version 11, you'll see that the formula is now using Get(CurrentPrivilegeSetName) - and vice versa. Likewise for the other two - all that work has already been done by Filemaker.

You are absolutely correct. I just wasn't sure how FM10 knew to make the "translation" in a formula that originated in FM11. Was it an update to version 10?

We have a mixed environment of clients with versions going back to 8.5 in some rare cases. I figured that this forwards compatibility didn't extend back to versions prior to 10. I may be wrong in this assumption, and may have "recreated the wheel" as you have implied. I haven't had a chance to test my assumption. I guess I'll report back when I do.

[comment]

I just wasn't sure how FM10 knew to make the "translation" in a formula that originated in FM11.

LOL, now you're making the same mistake as I did before. There is no "forward compatibility" - the function that originated in version 11 doesn't play in this game. Get(PrivilegeSetName) and Get(CurrentPrivilegeSetName) are one function; only the name is different between the versions.

The new function is Get (AccountPrivilegeSetName) - and if you had used that in your formula, you would get different results depending on which version the file was opened in.

[HUIT]

LOL, now you're making the same mistake as I did before. There is no "forward compatibility"

Wait, so a file with a calculation using "Get(CurrentPrivilegeSetName)" in FM11 is not read as "Get(PrivilegeSetName)" when opened/used in FM10? That is what I meant when I said "forward compatibility".

[bruceR]

Wait, so a file with a calculation using "Get(CurrentPrivilegeSetName)" in FM11 is not read as "Get(PrivilegeSetName)" when opened/used in FM10? That is what I meant when I said "forward compatibility".

Read more carefully; that translation IS made automatically and this was already answered.

It is the NEW function get( AccountPrivilegeSetName) that has no matching function in FM10.

[comment]

Wait, so a file with a calculation using "Get(CurrentPrivilegeSetName)" in FM11 is not read as "Get(PrivilegeSetName)" when opened/used in FM10?

Yes, it is. But that's nothing extraordinary, since the function has an ID and the displayed name is retrieved from a table. It's the same thing as with fields - you can rename a field without breaking all calcs that reference it.

[HUIT]

Yes, it is. But that's nothing extraordinary, since the function has an ID and the displayed name is retrieved from a table. It's the same thing as with fields - you can rename a field without breaking all calcs that reference it.

Ahhh... OK. So what I wrote IS redundant, because all client versions (assuming at least 7 and up) will function correctly with a calc written in version 11 that is using the new names for the old functions (they get re-written/translated/digested/whatever automagically), and calcs written in versions prior to 11 will work fine in 11. This is a "built-in" compatibility of sorts based on the fact that calculation code is stored in terms of function IDs and not human readable code.

Do I understand this correctly?

[comment]

Yes.