Find parameters summary

[CDiez]

Hi,

I am looking for a way to display to users their search parameters as they enter them in a number of FIND layouts. In my solution, users will perform searches by entering a number of search criteria (on different layouts) and "extending" the found set possibly multiple times (as they switch layouts, and as they "extend" the find criteria within a layout). But they won't go to a browse layout to view the search results until they are done "building" their search. I have scripted buttons to let them "extend" their search or "complete" the search and go to a browse results layout. I would like to display to them the criteria they are searching on as they are building their find, in a window somewhere on the find layout. It would go away once they complete their search and go to a browse layout to see their found set.

Does what I describe seem feasible, or would it be way too complex to implement?

I would love some opinions from you experts, and appreciate any tips to point me in the right direction.

Thanks in advance...

Carlos

[bcooney]

My first thought was that if you want to capture the user's search criteria, you'd need to create a fake find layout. This layout would actually have global fields on it in place of the "real" fields and would be used in Browse mode. Then a button script would enter find mode, set the corresponding real fields to the globals and perform the find. Meanwhile, you have their search criteria still in the global fields, and so you can display what they entered by showing the global fields on your result layout.

It is a bit complex, and I wonder if it's worth the effort. I also don't know how you would easily allow for constrain and extends with this method.

I also question the multiple find layouts that you mention above. They would all need to be based on the same table occurrence. Are you building some sort of find wizard?

Creating such find interfaces sets a precedent and forces you, as the developer, to build a solution that accommodates any search combination. It might be best, in the long run, to stay with a simple find interface.

PS: Haven't studied up on using script triggers in find (FM10). Perhaps they offer another approach.

Edited July 15, 2009 by Guest

[CDiez]

Thanks! This builds on a method you suggested to me some months back when I was looking at this the first time (this is a part time project for me, so I work on it in pieces, and sometimes forget where I've been.. not ideal I know).

I will go back to that and integrate your suggestion here, and I will keep in mind your suggestion to keep things simple. I have begun to appreciate that that is very good advice.

Regards,

C

[CDiez]

By the way... I don't have much experience with global fields, so I have to ask:

In using global fields this way to collect users' search criteria, is there a problem with multiple users searching at the same time? I mean, how can I select one set of choices and someone else select a different set simultaneously, if it's a global field?

[mr_vodka]

When connecting to a file as a shared client, global fields will orig have the value of what it was on the server. Also each global will be session specific. Therefore, each user's globals values are independent to each session.

[bcooney]

John, globals will inherit the value that they had when the file was last used single-user...I never count on this, and set them in an Open Script.

[mr_vodka]

I set them as part of the opening script as well just in case...

However, I dont think I articulated myself very well in my last post. Globals in a client / host situation will inherit the values that the host last had, whether it was when the host was taken down to a single-user and the values were set OR when a server side script sets those globals with a value.

Perhaps this time I made more sense. :P