Can anyone advise on the correct syntax to set a token to the currentrecID? I've tried the following without success....

[FMP-SetCookie:CookieName=[FMP-CurrentRecID]]

[FMP-SetCookie:CookieName=FMP-CurrentRecID]

[FMP-SetCookie:CookieName=CurrentRecID]

Thanks

Hi, this is the same syntax as the second value in an "If" - so I don't know a way to pass an FMP-variable into there.

As a workaround, I use a record serial number, because you can pass a field into the cookie. The syntax for a field is: [FMP-SETCOOKIE:thecookie=Field:recordnumber]

........which might help

regards, jeff

"Set Cookie to CurrentRecID"

"...advise on the correct syntax to set a token to the currentrecID?"

Make up your mind.

Do you want to set a FMP-Cookie? Has one already been set? You are allowed but one cookie in FMP.

or

Do you want to use a -token. In FMP 5.x+ you are allowed up to ten tokens. The syntax for the -token tag is in the CDMLRdb.

Thanks Jeff but unfortunately I'm unable to use recordnumber as the current found set will have changed by the time the cookie is used and will subsequently return a different record.

I had previously been using a find button to view details of a record and thought that this was working OK however I've since noticed that even when using the equals operator that the portal within the record returns portal rows for similar records i.e. record number 150 shows portal details of related data from records 150, 1500 & 1505. This was the reason I was looking to capture the recid and use this to uniquely identify only the desired record's portal rows. Has anyone else encountered this problem and knows of a workaround?

Unable

Apologies typed token in error but does FM6 not allow for multiple cookies?

Iain

Iain, my knowledge is pre-6.x. It was something I believe I read at FMI > Support > TechInfo Knowledge Base. You might want to check there.

The -token tag is very reliable and useful. Many prefer tokens to cookies for reliablilty.

The Sample File demos of "CDML Linking to the next record" and "CDML to Track browser hits on per record basis" do not deal with portals, but may offer some value toward your solution.

Bon chance.

Hi,

"current found set will have changed by the time the cookie is used and will subsequently return a different record."

the cookie value will be stored when it's set, so RecID and a record number would refer to the same record.

The cookie gets set as the page the "setcookie" is on loads rather than when the next action is posted.

regards, jeff

RE: The -token tag is very reliable and useful. Many prefer tokens to cookies for reliablilty.

Like me I was never ever 100% successful with cookies.

IMHO -- WC can set only single cookie per single HTML page.

Also there are limitations for expiration time, it can be up to 9999! No good.

Kick cookies and go for tokens!

Here is the Syntax from the "CDML Reference" db:

First parameter: The name and value for the cookie

CookieName - The name of the cookie. Must be fewer than 1024 characters. Can either be the contents of a field specified by "field: fieldname" or a text constant.

CookieValue - The data value of the cookie. Must be fewer than 1024 characters. Can either be the contents of field specified by "field: fieldname" , the reserved word CurrentRecID, or a text constant.

Hence:

[FMP-SetCookie: myCookie=CurrentRecID]

All the best.

Garry

side note:

cookies CAN

be dissabled by ANY suser

be deleted by ANY user

be copied by ANY user

be stopped by "pop-up stopper like software"

----------------------------------------------

perhaps tokens w inline is a better way?

The big difference between cookies and tokens is that cookies are persistent between sessions; tokens only last the current session then they disappear. This makes them non-interchangeable for some purposes.

nice

thank you Vaughan !

Hi, I've found Filemaker cookies to be unreliable when they're not just session cookies.

timed ones tend not to work on all of the platform/browser combinations. ( seem to remember one I used: Mac Explorer, OK, Windows Explorer, No)

If you need a cookie that doesn't expire at the end of the session, set it with your webserver or JavaScript.

regrads, jeff

RE: If you need a cookie that doesn't expire at the end of the session, set it with your webserver or JavaScript.

regrads, jeff

Absolutely. FM cookies never properly worked in all conditions in all browsers. Never ever!

We're starting to work w/tokens and find them reliable but I did find "re-newing" the token from page to page kind of hard to track sometimes (lazy + discorganized + forgetful = trouble & frustration) whereas a cookie just sits there. We're sticking w/the tokens, though!

Small hint: I have in text file all Tokens and the "carry-over" code with them.

When I've got functionality OK, then I just copy/paste the 5-10 tokens bit.

I think Lasso will pay back in week, because you don't have to use tokens, just sessions, which is just single statement on top of the page.

I agree about FMP-set cookies not always working. I posted a questions ages ago about this, where the cookies could only last 3 months or something. But cookies are still the only game in town for persistent storage.

RE: But cookies are still the only game in town for persistent storage.

Agreed, but not the one WebCompanion produces. Better JavaScript ones or others.

Anatoli:

"I have in text file all Tokens and the "carry-over" code with them."

- ...like a code snip or did u figure out how to temp_store the value of the token into text file?

is this possible? I am much like Steve....who wants to remember to pass the token...have u been keeping a secret mr. Ana_toli

All the best!

No secrets here

I was referring to Steve T. remark, that tokens are difficult to program. Agreed.

So I have all the used links from HTML/CDML solution in textfile and I can copy/paste anything when I am building or reprogramming solution.

ah I see....it was worth to ask

thanx