Hi all,

hope my explanation makes sense:

my client wants to be able to be taken to a related table as soon as he's entered a date into a field in a portal - I thought of using zippScript_PerformScript and it works, but only when creating the first date. When trying to do the same on the second row, I get taken to the first post that was created.

What am I missing here?!

This could be an issue with your script and not ZippScript. Try attaching the script to a button on the portal row and see what happens.

Hard to say what's wrong without seeing the script, or knowing what version of Filemaker you using.

I'm sorry i didn't mention it, but the script works perfectly when attached to a button on the portal row.

I'm using FMP 9 Advanced.

And the script is ... ?

Oh, hold on... I'm using the

"Go to Related Post [From table:"Offert"; with layout:"Ek_Offert" (Offert)]

- the "Show only related posts" is not on, by the way.

That's it. Is there a limitation when working when ZippScript in portals, or what have I missed here?!

I think the problem here is that validation by calculation is performed only when the record is committed. At that time, you are no longer in any portal row - so GTRR goes to the first related record. I think you need to come up with a different UI model.

You might be able to drop the ZippScript call into the Auto-Enter calc box instead of the validation calc box.

The script might work if you had it act in the context of the record you created rather than the parent record. E.g.

Set variable( $id ; Offert ID )

Go to layout( Ek_Offert )

Enter Find mode

Set field( Offert ID ; $id )

Perform Find

// Not tested

You might be able to drop the ZippScript call into the Auto-Enter calc box instead of the validation calc box.

That might work slightly better - but only if you tab into another field on the same row. If you press enter, you are out of the portal - same as before. If you tab into the next row, the script will GTRR to the record on the next row (if there is one).

I don't see the point in starting data entry in the portal and being whisked off to continue it in a new window anyway.

I don't know the reasons the client has for wanting the interface this way, it could be poor design, but the OP can set the field to tab with the Enter and Return keys and control the tab order, or pass the id of the child record as a script parameter.

This design was decided upon after a lot of discussions with the client.

the OP can set the field to tab with the Enter and Return keys and control the tab order ...

That might help, but it's still rather clunky. For example, if user clicks outside the portal, they will again go to the first related record.

... or pass the id of the child record as a script parameter.

Huh? Who/what will do the passing, and when?

You can pass script parameters using zippScript.

Auto Enter calc for RelatedDateField =

Case(isEmpty(relatedDateField); "";

relatedDateField &

Left(zippScript_PerformScript(Get(FileName); "Script"; RelatedPrimaryKeyField); 0)

Surprisingly, that does evaluate before leaving the portal - but I cannot stop it from triggering twice when it's a new record.

I hadn't tried creating a new portal record directly in the field that's being triggered. If you create it by entering data into another field of the record, it doesn't trigger. I assumed by Case(IsEmpty()) test would get around that. But it's not.

I'm stumped there.

There's a Get(ScriptName) but no Get(AllActiveScriptNames) that gives a list of all running and paused scripts. That would be useful here and maybe in some other situations.

This ugly hack seems to work. And if not, I don't care - I don't like this method anyway.

zippTrig.fp7.zip

This ugly hack seems to work. And if not, I don't care - I don't like this method anyway.

That did it! I'm very grateful for the time you put into helping me with this! Thank you!

But every tiny modification makes the extra window pop up, and I would think it's against:

Users can accomplish their tasks quickly, because well-designed applications don’t get in the user’s way.

Take advantage of people’s knowledge of the world by using metaphors to convey concepts and features of your application. Metaphors are the building blocks in the user’s mental model of a task. Use metaphors that represent concrete, familiar ideas

Familiarity. The user’s mental model is based primarily on experience. When possible, enhance user interface components to reflect the model’s symbology and display labels that use the model’s terminology. Then, where appropriate, use familiar Mac OS X user interface components to offer standard functionality, such as searching and navigating hierarchical sets of data.

All plucked boldly from this:

http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGIntro/chapter_1_section_1.html

...and changing the autoenter to one-shot won't remedy this, because sometimes its needed at other times not, I vote for a dedicated button to lead the user by his own will to detailed layout.

IMHO is this approach that Stephen airs here:

http://fmforums.com/forum/showpost.php?post/276529/

....much more true to these concepts, if you are on an Adv. version could all buttons shown be assigned to shortcuts as well.

--sd

Surprisingly, that does evaluate before leaving the portal - but I cannot stop it from triggering twice when it's a new record.

FM wants to update the portal record twice when created in a portal, re-evaluating the auto-enter calcs and re-triggering scripts. To work around this, you need to temporarily disable the script triggers after the first update to prevent the second update from re-triggering the script.

Change your script trigger to something like:

Field & Left( zippScript_PerformScript( Get( FileName ); "MyScript"; "MyParams" ) & zippScript_DisableTriggers; 0 )

Add this to the end of the triggered script:

Set Variable[$Result; zippScript_EnableTriggers]

The first update to the portal record will now trigger the script and then turn off any further triggers. The second update will then re-evaluate the auto-enter calc but will not cause a second script to be triggered.

At the first opportunity (after the updates have been completed), FM will run the script and the triggers will be turned back on, awaiting the next change by the user.

John

Thanks, that works great. You can ignore my e-mail.

If we put the Set Variable at the beginning of the script, we can then use your great tool during the script for other purposes, without triggering twice.

Even though the anti-mac'ers might have a point here:

At the least, violating basic assumptions is a useful mental exercise, but a surprising number of the resulting concepts have ended up as useful descriptions of the real world

But when does it turn out to be annoying - Couldn't I help seeing this attention demanding interface element as an extra fatiguing element, which might seem like:

digital world of infinite distraction

As Tim Ferriss in his:

"Marijuana Trumps Blackberries for Productivity"

http://www.huffingtonpost.com/tim-ferriss/marijuana-trumps-blackber_b_46595.html

--sd