GTRR from portal not working

[beatryder]

I have two portals in the bottom of my layout, one to show "parents" and one to show "children". I want to put a button on each portal row that will allow me to go to that record.

The tricky part is that I have a different layout depending on the record type (Component, Sub-Assembly, or Part), and different variations depending on the users security level. I already have scripts written to choose a correct layout depending on security level that I can call on.

Now the script I wrote, displayed above, works sometimes and other times goes to a record that I can't figure out why it would choose that one.

Am I missing a crucial step? I've attached the entire db for people to see what I want.

--Dawn

PDS-MAFC250-V4-9-Stripped.zip

Edited September 26, 2006 by Guest

[John Mark Osborne]

What's the full access account and password for your attachment?

[beatryder]

Oh, sorry, I forgot the login info!

Login: Admin

Password: Admin

Thanks, and sorry!

--Dawn

[Fitch]

One thing that looks wrong in your screen shot is that you're setting the "ComponentID" into a variable $RecordID, but then later trying to go to record by calculation -- and your calc is ComponentID=$RecordID, which is going to return a value of 1 or 0 (true or false). So you're telling it to go to record 1 or 0, probably not what you intend.

Even just using $RecordID probably is not what you're after. "Go to record by calculation" is going to go to that record in the current found set, based on the current sort order. It has no relation to the record ID, it's just the position of that record in the active list.

You're already going to the related record (using current layout??). Why do you need any further "go to record" command?

[beatryder]

The further scripting is an attempt to get the right layout based on "Type" and security level.

If I'm in the components layout (there are three security levels with associated layout variations), and I want to go to a parent layout, I need to determine whether it's a Sub-Assembly or a Part, then go to the proper layout.

The problem I'm having is that since Components, Sub-Assemblies and Parts are all in the same table, and I seperate them by doing a find, when I go to the related record I want it to look like it's going to the Sub-Assembly registry (only sub-assemblies in found set) or to the Parts registry (only parts in found set).

So the reason I'm trying to store the RecordID is so that I can go to the correct layout, find all records of the proper type, and then go to the related record.

I'm used to programming in languages like Java, Assembly and C, so this Scripting in FileMaker is a bit different for me.

Would I need to store the record number in a field somewhere in order to be able to reference it at a later date?

Does what I want make any sense? It's more complicated than a simple GTRR, and that's where I'm having problems.

--Dawn

[beatryder]

Well I tried setting the buttons to do a very simple GTRR, and it still doesn't work.

It seems to still be going to random records, and not the record displayed in the portal row.

My relationships are rather complex as well. I've got a self join with a join table that the GTRR has to navigate. I've attached a picture of my Relationships diagram.

I really can't understand what the problem with the GTRR is, so I can't even begin to try to fix the problem. Someone sent me an example using the find feature, but I couldn't get that to work either.

--Dawn

[Fitch]

You could put the ID into a global rather than a variable. Make a relationship from globalID to ID. You could then do your Find, then GTRR to the original record without losing your found set.

[Fitch]

Don't forget that "context" is very important in FileMaker, i.e. GTRR is dependent on layouts.

[Inky Phil]

Sorry to hijack this thread but I am having a similiar problem and my heading would have been exactly the same.

I have a portal with two records in it and a button in the portal row to GTRR.

If I attach a GTRR straight to the button it goes to the record selected but if i put the same GTRR (same conditions/layout etc) in a script it goes to the first related record. I am sure this is a context thing but for the life of me I cannot work out what is different. Can anyone help please?

Phil

[Søren Dyhr]

If you place the cursor in a field in the portal before typing keycombination calling the GTRR script, will you land in the right record.

If you have buttons outside the portal, do they need a script parameter to jump to right one!

If [ IsEmpty ( Get ( ScriptParameter ) ) xor 1 ] 

     Go to Portal Row [ Get ( ScriptParameter ) ] [ Select; No dialog ] 

     Go to Related Record [ From table: “thePortal”; Using layout: “thePortal” (thePortal) ] [ Show only related records ] 

End If

....Which could be a calculated value such as Count(relation:

This will always get you the last according to the portals sortorder.

--sd

[Inky Phil]

Please ignore that last post of mine.

Since I have come in this morning and started FM up again the scripted version is now working. Very odd but none the less working.

Moderators please feel free to delete both this and the previous post

Phil

Edited September 27, 2006 by Guest

[Inky Phil]

Sorry about that Soren. I didn't mean to appear rude but we both posted at the same time

Thanks as always

Phil

[beatryder]

Fitch: Could you elaborate on how I would set up the global method you described?

Would the global be in the same table, then add another TO or just more relationships into my existing relationship diagram? Then how would I go about passing and retrieving information from the global and still say in the correct found set (I've got three, and depending on what type the parent/child is will possibly change the found set during the script)?

Thanks,

--Dawn

[Fitch]

You might not need a global or any modifications to your graph.

- you're on a layout based on Material;

- then you go to a layout based on ComponentRegistry;

- do a Find;

- go back to the Material layout;

- GTRR (i.e. from Material to ComponentRegistry)

Now, if the MaterialID that you just used in the GTRR exists in the found set, the found set will be retained, and you'll also be on the related record within the found set.

Make sense?

[beatryder]

I'm looking for the script to work in my self join section, and you're describing it as needing two tables, will it still work?

My "ComponentRegistry" table is the main table, and it's self joined using a join table (BOM) to itself to give me a parent/child relationship structure.

I want to go from one record in the Component Registry to another record in Component Registry. Which should be easy, but since I'm sorting all the records in that table into three catagories (Part, Sub-Assembly, and Component), and the record I want to go to may be in any one of those catagories, it gets complicated.

In plain english, this is what I want the script (or global) to do:

Go to the related record (the one displayed in portal row)

Get the record ID

Choose layout based on "Type" and user security level (which will give me a found set using the correct layout)

go to record using Record ID and maitain the found set

So the method you just described, will it work with just one table? I'm not switching tables (well, I might be able to use the Join Table if I have to), so can I still find a record and then make a new find set and go back to that record?

I'm really new at this and this is my first database ever, so it's difficult for me to get my head around it. Are there any examples I can look at to get a better feel for this method?

Thanks,

--Dawn

[Søren Dyhr]

I think I get the problem here???

go to record using Record ID and maitain the found set

You need to add a little weight to you graphing:

http://www.sumware.net/robfm/savingfoundsets.php

--sd

[beatryder]

Okay, I'll play with that a little to see if I can make it work the way I want.

One problem I can see at a glance is that my found set depends on my gtrr, I have to get the related record before I know which layout and found set I want. In the example, you set the found set before you gtrr.

So hopefully I can get around that.

Thanks,

--Dawn

[Søren Dyhr]

Well if the found set is established by a GTRR or other measures is of no importance, it won't prevent you from issueing yet another GTRR (here a towards a disconnected TO) to save this set, for later!

--sd

[Genx]

I am confused about the obsession with GTRR here, wouldn't it just be easier to store the primary key, go to the appropriate layout based on a get(privelegeset) and simply do a search for an exact match?

While i do use GTRR often, in cases extremely similar to yours where you store what are effectively seperate things in the same table and i will simply do a find for the sake of simplicity.

[Genx]

Oh and listen to Soren about the method for preserving the found set, it will definitley be useful in your case.

[Søren Dyhr]

Oh and listen to Soren about the method for preserving the found set, it will definitley be useful in your case.

Interpreted how, sarcastic?? I've always found it less considered to sprinkle a solution with plenty of globals for all kinds of uses.

--sd

[Genx]

... I wasn't being sarcastic, I'm really not quite sure where you go that idea from Soren.

You made this suggestion in a previous thread that i started and i have used that suggestion extensively and with great satisfaction. There was nothing negative in my statement so i'm not sure why you interpreted it in that manner.

[Søren Dyhr]

Fair enough! Different discourses makes interpretations only approaching asymptotic - never meeting exactly.

--sd

[Fitch]

Genx, she doesn't want to just find an individual record or a group of records; she wants to find a group of records and then go to a specific record within that found set.

Søren's link is very good information, but again I don't think it addresses this particular problem.

Yes Dawn, the method I described will work with a self join.

- Set the global

- Do the Find

- GTRR

The only other method I can envision for doing this would be to set the ID into a $variable; then Find; then loop through the found set until ID = $variable. (You could use a global instead of a variable, but we don't need to in this method since we're not using it for a relationship.) This method will be slower than GTRR, but depending on the size of the found set may be acceptable.

[Genx]

Hmmmm, it's really a bit of a weird request...

So we want to retrieve all the records that are of a particular type, then navigate to a particular record in that set.

Nevertheless, i do think soren's suggestion may be valuable here because it can be used to preserve particular foundsets, namely preserving current record numbers, foundsets etc. of those records that are "parts" "sub-parts" etc. etc. which must behave as if they are in different tables, but which must also be easily retrieved.

The reason i am guessing that all the records of a particular type are required to be retrieved in this case is because the OP doesn't want the user browsing through ALL records but rather those of only a particular type, which seems to suggest that the user can't search for themselves i.e. that it's been disabled.

Anywho, i'm a bit lost but you guys look like you've got it settled.

Have Fun :D

[beatryder]

I got it working using a find, then a loop.

I wasn't able to use the global and gtrr method, it wouldn't work for me. I don't think I really understand it properly.

Are there any examples anywhere that use this technique? The loop method works for now, but if the other method is faster I would like to use it.

Thanks for all the help guys! You've been a big help.

--Dawn

PDS-MAFC250-V5-0-StrippedPlay.zip

[Fitch]

I bet the problem is that you're on the wrong layout. After you do the Find, you have to go to a different layout, based on a different Table Occurrence, the base table of which must contain the global field that is used in the relationship. This base table can be the same as the original layout's, it could be some existing table, or you could set up a new Globals table just for this purpose.

Start at layout A

Go to layout B (with the global)

GTRR from B to A