Is there any way to 'go to field <somefield>, repetition x', where x is a 'calculated' value instead of a constant??

Or to 'set field <somefield>, repetition x' again where x is a 'calculated value instead of a constant.

TIA

I think I found my own answer looking in the 'Enhancements' forum. There is no easy (nor I'll bet processing efficient means) to do this.

Let me try a variation on the problem/need:

If I'm pointing to repetition x in a repeating field and the do a 'go to portal row', reference to repetition x is lost. Is there any way to gracefully return to that repetition without 'counting over' from repetition 1??

The only fix I could see would be to set a global variable with the current repetition.

I am also trying to achieve similar things in FMP 5 . So far it doesn't look possible...it seems you can "getrepetition" but not "setrepetition"....at least not by a calculation....am I wrong(he said hopefully) is there some way of doing what you've proposed above?....that would be great and save hours of tedious programing...

....oh to clarify one thing....i am suggesting that the repetition that is changed is the result of a calculation involving a global field...i.e. if it says "1" then its sets rep 1 to value "x" etc.

thanks in advance to anyone who might be able to shed some light on this....

Why are you using repetitions in the first place? Why do you think you need to GO to a particular rep?

Why are you using repetitions in the first place? Why do you think you need to GO to a particular rep?

Hear hear!!!

--sd

thanks for the reply....I am using repetitions for a few reasons. To give a quick overwiew, the "table" that uses them, is mainly a graphic representation of an audio patchbay as used in recording studios, and as used to be used for telephone exchanges. So there is lots of repeated stuff. In places I have used seperate fields, or in some cases seperate instances of the same related field via a different relationship. However I have tried to keep the number of fields from getting astronmical.

I have considered doing one of the above methods instead, but the whole solution is quite well advanced now, and there are lots of scripts, auto enter calcs, & relationships integrated across multiple files, so making such a change might be quite an undertaking at this point.

However, I would be interested to know if there is some reason I should not be using repeating fields, and another approach that would be more efficient.

In order to more fully answer why i need to go to certain repetitions, this is what i want to achieve: a script that auto inputs data in repeating fields specified by a start and end number. I have already achieved similar things by using quite a few scripts which are then selectable, but i was hoping for a more flexible solution with less scripts having to be written.

I hope my rather long reply is inteligable....& thanks for any comments you may have...

In places I have used seperate fields, or in some cases seperate instances of the same related field via a different relationship. However I have tried to keep the number of fields from getting astronmical.

That is very precisely the reason why to bother picking up a relational structure in the first place. Since you're with 5.0 must some trickery be put into the solution a.k.a http://www.nightwing.com.au/FileMaker/demos/HorizontalPortal.zip

Then is there the purpose, where connections probably are half normalled, so a plug in upper row means sniff and one in lower means break ... This talks in favour of a dwindeled list system behind the curtain, and not as you state:

I have already achieved similar things by using quite a few scripts which are then selectable, but i was hoping for a more flexible solution with less scripts having to be written.

But one single script based on the invisible buttons in the portal, where a popup shows which of the holes are free to recieve a plug.

http://www.kevinfrank.com/download/dwindle.zip

Then there is the graphical approach to show an occupied hole, here might a Patterncount( backwards over the relation getting a if a value is stored in a pilcrowdelimited text field ...the Jeff Almquist method from an old Advisor.

Checkout the templates suggested, and see if they convey a method ... meanwhile will I see if I can get some ideas as well. But by and large can't I see any compulsory reasons for not expoiting the relational tools for you solution, since the structure in it self is a many2many???

--sd

Thanks for the very interesting suggestions. Obviously you have a degree of understanding of patchbays...the dwindle thing looks interesting...I wonder if there is a way to enable/dissable its functioning (other than doing similar layouts with slightly differing value lists)...because sometimes the dwindle thing would stop me using the same connection more than once where needed...

...anyway, will have a play with that....

....the horizontal portal also sounds great....but something for me to look into when I have more time, as i believe it could lead to quite a lot of re-programming as i said above.(& i am using the solution to do a studio wiring job at the moment)

....for that reason, i worked out a way of scripting my original plan....by using several (48 in this case) short scripts, which get chosen by an "if global field = " type scenario , and to my suprise it works quickly and without any glitches.

However as i said above, i can see a few potential advantages of using sideways portal rows....so i hope that will prove workable for a future "upgrade" of my solution.

....many thanks again....

and if anyone would find my work around useful to know more about, then just let me know...

One of my early thoughts was, a graphical view might look cool, but the purpose is that the engineer before a session, makes the patching quick and reliable. This means that repeaters are out of the question since reporting on them are next to imposible.

The issue I'm pointing at is that two layouts are required one for entry during the session and one for the teaboy/tapeop.

because sometimes the dwindle thing would stop me using the same connection more than once where needed...

I would have both the sniff and the break row as identifires in a dwindled list, which is the way to go with databases the thought of eyeballing occupied holes are ...sacrice. When such functionality can be done with an unstored calcfield.

and if anyone would find my work around useful to know more about, then just let me know..

Your approach is interresting, and I might harvest it and do some work at it and suggest it as a part of this solution, I've contributed to before:

http://www.rootsolutions.de/studioease/index.htm

--sd

...i must try to make time to share a bit more with you on this...it has a slightly different focus than you might expect...in that its purpose is mainly aimed at the initial design & wiring of a studio, rather than the patching whilst in use, although that is part of it thats under development...

...its currently about 11 files and about 11 meg by coincidence....so quite big for posting...

anyway, its good to share ideas in this area witho someone who understands a bit about the actual use. Do you have a link with the audio industry?

...anyway, i will probably be out of circulation for a few days now...

thanks again for the interesting input...

Do you have a link with the audio industry?

Been roadie since 1982 and later partner in a soundrental company ...today freelancer but mostly with filemaker.

--sd