Hi Guys,

I'm sorry if this has been answered before, but I've search this forum as well as articles and tips, and havn't managed to come up with any answers.

I have a data entry screen (Form), with 7 records. When the user clicks on search button, it takes you to a modal window which is a search screen. The user can perform a Find, by entering data via a pop up list, or cancel the find (which shuts down the modal window).

My question is, it creates a foundset in the wrong layout, i'd like it to return the foundset back to the Form screen. Is this possible?

I've attached a very simple file, with one field and 3 basic scripts.

Any help would be much appreciated, i've been scartching my head with tjis once, trying to use GTRR command etc, but not had any luck.

Hi Guys,

I'm sorry if this has been answered before, but I've search this forum as well as articles and tips, and havn't managed to come up with any answers.

I have a data entry screen (Form), with 7 records. When the user clicks on search button, it takes you to a modal window which is a search screen. The user can perform a Find, by entering data via a pop up list, or cancel the find (which shuts down the modal window).

My question is, it creates a foundset in the wrong layout, i'd like it to return the foundset back to the Form screen. Is this possible?

I've attached a very simple file, with one field and 3 basic scripts.

Any help would be much appreciated, i've been scartching my head with tjis once, trying to use GTRR command etc, but not had any luck.

test_search.zip

I don't have FMP 7 with me so I cannot see your attachment, but have you tried the "Go to Layout [original layout]" step? As long as this Form screen layout is based on the same table occurranceas the Find screen, the found set should still be there.

I don't have FMP 7 with me so I cannot see your attachment, but have you tried the "Go to Layout [original layout]" step? As long as this Form screen layout is based on the same table occurranceas the Find screen, the found set should still be there.

I believe the rule is "one found set per window". IOW, a Find performed in one window doesn't affect the found set in another window - even when the two windows show the same layout based on the same TO.

I believe the rule is "one found set per window". IOW, a Find performed in one window doesn't affect the found set in another window - even when the two windows show the same layout based on the same TO.

Hi Guys, Thanks for both of your replies.

Vaughan I have indeed tried to use the Go To Layout[original layout] step, but as Comment has already pointed out, foundsets are window specific.

I guess logically speaking i can make the user enter the details in global fields and perform the find in the correct window....it just seems so cluncky to do it this way as i'll have to create so many unnecessary global fields in my application and Im trying to keep it nice and simple.

Not necessarily. You can either:

Enter Find mode []

Show Custom Dialog [some fields here ]

Perform Find []

Or, you can go to another layout in the same window, and manipulate the window parameters as if it were a pop-up (except that the background window "disappears").

Finally, you can always grab all the found IDs into a global, and do GTRR on that in the original window.

From an interface perspective, entering data into one window that modifies the found set in another is not straightforward. I'd prefer to never leave the window.

If another found set is required of the same data, let the user open another window to perform the find.

I don't think that's breaking the rules - provided it's presented as a dialog box (as I understand the poster intends). See attached picture.

Ahhhh... but the result of this MacOS X Find dialog is a new window... it does not change the contents of an existing Finder window.

I think that with FMP 7 this is the kind of multi-le-wuindoiw-think that we're going to have to adopt: be more respectful of the user's choices by being careful not to change anything they have set up unexpectedly.

I'm still getting my head around it, so please don't assume I know all of the answers. I still don't know what all of the questions are yet.

Yes, but if you start in Window1 by clicking 'Search...', then Window2 pops up with "Define search criteria.. [Find]' - I don't think it is surprising or confusing to land back in the originating window containing the search results.

In fact, I'd say it's LESS confusing then switching the SAME layout to Find mode, then coming back to Browse mode, with the search results.

Hi Guys,

Thanks for the info and tricks suggested, its quite interesting what others think. Comment, I've tried the GTRR trick, before my first post without much success, however I wasn't copying the found ID's to a global and then doing a GTRR. My question is, GTRR works from a relationship, how would I create a relationship between base table, and an occurance of the base table (hope that makes sense).

Cant wait to get home and try some of the suggestions....

To be precise, you'd be creating a relationship between one occurance of the base table, and another occurance of the same table - IOW, a self-join. Nothing to it. Just place another occurance of the same table on the graph, and make your relationship (see attached pic).

Hi Comment, I created a relationship, from table1 to table1 2.

I perform the find, in my modal window, pass the the found id's to a global field, and then use GTRR, with my new relationship. I guess the relationship is working(although it could be the find), as the GTRR is finding the record, however its not going back to the the table in the background, its just going to the Form screen on the TO 2.

Im now starting to look at purchasing a dialog plugin to do this, but really can't justify the huge developer licence fees, for something that FileMaker should have had in there custom dialog box (I want the user to choose from popup menus).

I meant something like this.

test.fp7.zip

Hi,

That is how my finds behave too, localized in a new Window.

Not only do I find this user-friendly, but also, if you happen to be using a tabbed interface where the tabs could come from related records into individual portals, these Tabs won't disappear anymore...

That's actually why I primarily used this method...then I found the users were less confused.

Nifty, Comment.

And I see you switched your TO placement. Your original picture showed the global ID on the right and your real ID on the left (in the graph). Your demo has them reversed. In 7, it doesn't matter where we put them, of course.

I know ... I know ... this is just anal (pre-7) thinking. My mind keeps saying the right 'pane' should be the indexed side. God, I need to get that out of my mind - totally FLUSH that thinking because 7 is not an entity-based relationship model. It's hard to break that head-set though! Thanks for the demo.

You are right. The picture was reversed on purpose. I was trying to explain the principle of capturing the IDs in the second window, and then going BACK to the original - so the direction of the relationship was reflecting this as well. When I actually made it, I made it right.

Superb!!!

Thats exactly what I wanted!

Thanks once again, hopefully someone else will find this thread useful!

Cheers

Jalz

Here is an improved version. No copy/paste nonsense, no need for special layouts - just one more field.

The technique could probably be used for other purposes as well.

searchWindow+.fp7.zip