I have a large data file and several interface files, each with no tables of their own, but many layouts which reference the external data tables.

I am having trouble navigating from a record in one interface file (Students) to a related record ("Advisor" in the Employees file) in a different interface file.

1) How can I apply GtRR if the interface file has no tables?

2) If I have a found set of say 10 records in the data file, how can I navigate to a layout in the interface file, maintaining the Sort Order, if possible?

Thanks for any push you can offer!

DSW

1) This seems like a quixotic struggel with metaphors, for each TO ushered into the interface file can you choose to tie a layout, which is manditory to make GTRR work as scriptstep, so if you have forgotten to make a destination layout....

2) Well you don't ....make the search in the interface file!!!

--sd

Thank you for the feedback.

I remain unclear how to do this:

Nav as follows:

Record(s) in Interface_file_A ->

related record(s) in Data file ->

Interface_file_B (with correct found set and sort order)

... or some equivalent which has the same result.

DSW

Why do you have several interface files, the approach is usually called SFI where the "s" stands for single?

--sd

Hi

I do the following: TO from Adresstable in GUI1, one Layout with only the PK of the Adresstable, now if you have your dataset selected, go to this layout and copy all rows, this gives you a collection of the selected PKs, seperated by CR, into the pasteboard, now go to GUI2, another TO of the adresstable, a globaly stored text field where you insert the pasteboard, establish a relation from this "multiline-PK-collection" to the PK of the table, perform GTRR and here you are

This works for me, if I want to print in a separated printing-file

Holger

Thanks much.

Yes, I came up with that approach too, but was hoping there might be a more "elegant" approach.

Also, you might try the following custom function (by JMO) which collects your found set of PK's automatically - instead of Copy All Records. Use it to define a field in your data file called IDs_collected:

cf_AppendNth (ID,1,get(foundcount)); make it unstored.

(You probably know this.)

----

/*

Name: cf_AppendNth

Params: field, start, number

Last Edit: 2006-06-01

*/

Case (

start < Number ;

GetNthRecord ( field ; start ) & ¶ & cf_AppendNth ( field ; start + 1 ; number ) ;

start = Number ;

GetNthRecord ( field ; start )

)

----

I appreciate your good thoughts on this.

DSW

PS: Multiple interface files due to conversion from .fp5 for files with hundreds of layouts ...

Thought about that to but it does not work on FM7, thus I will have to stay with the old one until the school is migrated to 8, 8.5, 9 or ....

Holger

Multiple interface files due to conversion from .fp5 for files with hundreds of layouts ...

I've guessed that, but a proper thorough migration will simplify the scripting considerably if all interfaces resides in just one single file, which BTW solves the initial problem with GTRR most elegantly. If you then choose to have the data in the same file as well depends on how often you tweak matters in the business logic. There can be some networking point in the separationmodel if you decide to have the interface file deployed on each workstation instead of the server!

--sd

"There can be some networking point in the separationmodel if you decide to have the interface file deployed on each workstation instead of the server!"

Hi Sören,

can you elaborate on that one? That is what I asked about in another thread.

Thanks

Holger

Edited July 21, 200619 yr by Guest

If say you have made a snazzy layout with all the bells and whistles you can cram out of photoshop, would the layout hardly be the native vectorized information the filemaker tcp/ip-protocol deals best with.

Just like banks wishes to convey a notion of being solid, although what they're dealing with is pure abstraction, could developers similar bolster appearences.

The idea is that users might need an opener file anyway to gain access to the shared database. What if all the graphic's resided on the users machine instead of burdening the network??

I do not, as would see subscripe to this model. But instead would I stess the importance of simplifying the rendered realestate in layouts and the restrain the use of interface elements that can't be vectorized.

A good read on this is:

http://www.smallco.net/RestrainYourself.pdf

--sd