Jump to content
Server Maintenance This Week. ×

Function Names have changed

JerrySalem

By JerrySalem
in FileMaker Pro 11

 Share

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

Recommended Posts

JerrySalem Proficient

JerrySalem

Posted
Posted

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

Link to comment
Share on other sites
bcooney Grand Master

bcooney

Posted
Posted

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!

Link to comment
Share on other sites
JerrySalem Proficient

JerrySalem

Posted
  • Author
Posted

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.

Link to comment
Share on other sites
  • 4 months later...
bcooney Grand Master

bcooney

Posted
Posted

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?

Link to comment
Share on other sites
comment Grand Master

comment

Posted
Posted

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).

Link to comment
Share on other sites
  • 8 months later...
HUIT Rookie

HUIT

Posted
Posted

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.

Link to comment
Share on other sites
comment Grand Master

comment

Posted
Posted 

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.

Link to comment
Share on other sites
HUIT Rookie

HUIT

Posted
Posted

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.

Link to comment
Share on other sites
comment Grand Master

comment

Posted
Posted

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.

Link to comment
Share on other sites
HUIT Rookie

HUIT

Posted
Posted

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.

Link to comment
Share on other sites
comment Grand Master

comment

Posted
Posted

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.

Link to comment
Share on other sites
HUIT Rookie

HUIT

Posted
Posted

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".

Link to comment
Share on other sites
bruceR Grand Master

bruceR

Posted
Posted

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.

Link to comment
Share on other sites
comment Grand Master

comment

Posted
Posted

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.

Link to comment
Share on other sites
HUIT Rookie

HUIT

Posted
Posted

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?

Link to comment
Share on other sites

This topic is 4754 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
 Share
Go to topic listing
×
×
  • Create New...

Important Information

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

  I accept