Displaying Results in Varying Layouts

[Wickerman]

 I am working on an iPad interface for an existing database of an art Collection.  There is a table of Artists and a child table of Works, where each artists can have multiple works.

 

I have separate layouts for displaying Artists, with biographical information, and Works with an image of each piece, and various descriptive fields.  In both cases, I want to use merge fields for displaying the information, not Text fields - this is for browsing/viewing only, not data entry.

 

So, for Searches, I want to have a separate Layout including field boxes from both tables, so that the user can use criteria about artists and/or artworks to find what they want.

 

1) My quandary is that I would like to allow the user the option of searching for either Artists or Artworks from the same Search layout.   I've based the Search layout on the Works table, using an OnLayoutEnter script trigger to enter Find mode so the user isn't "on" a particular artwork record in browse mode.  Is there a mechanism I can use that will allow users to specify whether they are looking for Artists or Works -- and move them over to the appropriate Layout to view their results?

 

I imagine one way would be to create a layout based on a utility table of global fields, one for each of the desired search field, plus a field allowing the user to specify "Work" or "Artists" and then write a script to execute the Find on a non-displaying layout (I need a searchable  layout with all the fields on it, right?) and deliver the results in the appropriate display.

 

Is this more or less "the way to do it" -- or am I making more work for myself than necessary?

 

also,

 

2) I've tried presenting the results in a sub-summarizing List-View, with the search results displayed by Artist with Works grouped appropriately under them -- but in practice, I'm finding that the Sorting for the sub-summary is unacceptably slow when the resulting set is large -- even without including any image field on the layout.  I'm using this on a local network, not with Server.   Is there a reason this Sorting is so slow - and a likely way to speed it up?  If so, that might solve my problem. . . . but I'd still be interested in replies to (1).

 

Thanks!

[Matthew F]

 

 

 Is there a mechanism I can use that will allow users to specify whether they are looking for Artists or Works -- and move them over to the appropriate Layout to view their results?

Why not put two buttons on your layout that appear in find mode and are labeled: "Artist" or "Artwork"?   The buttons run a script that execute the appropriate Find (e.g. via script parameters) and navigate to the layout of your choice.  

 

 

 

Is there a reason this Sorting is so slow - and a likely way to speed it up?

Check the field definitions for the fields in your sort order to either allow or enforce Indexing.

[Wickerman]

Thanks Matthew -- I was totally overlooking the idea that you could click on a button while in Find mode!   I'm a little fuzzy though on how you mean 'script parameters' -- and what script steps/techniques I would use to channel the search terms onto the appropriate table? 

 

Say I build the Search layout in the Context of Artworks -- if I want the results to be Artists, how do I shift the context of the actual Find into this other context?  One thought is maybe performing the Find within Artworks and then use  a "Go To Related Records" step?  Is that the idea?

 

On the Indexing issue, I checked the Sort fields  -- one of them is a calculated field -- and they are both set to "Indexing: All" - - - is there another setting I'mk forgetting relevant to this?

 

Thanks so much for your help!

[Matthew F]

I'm a little fuzzy though on how you mean 'script parameters'

You could create two different scripts (one for each button), or you can create one script and link it to both buttons. For the latter case each button would include a script parameter in the button definition (e.g. "Artist" or "Artworks") that tells the script which button was used to invoke the script. Type in the parameter at the bottom of the window where you choose the script for each button where it asks for "Optional script parameter".

To check the script parameter in the script use the function Get(ScriptParameter). You can use this in an IF( ) script step to cause a fork in the program to run a search for Artist vs. Artworks.

There is a risk of performing the Artist search on the Artwork layout. It will turn up nothing is an Artist has nothing listed in the Artwork table. If you're not worried about this then, you can do the search in the Artworks layout, and then use the "Go to related records" script step to go to the corresponding Artist table.

Although it would require more programming, it might be safer to collect the search terms on a generic layout, store them in variables in the script, navigate to the correct layout (depending on the script parameter) and then use the terms to perform a Find.

For example:

Set Variable ($value; Text_global)

Set Variable ($layoutNum; Get (LayoutNumber))

IF( Get( ScriptParameter ) = "artist")

   Go to Layout ( Artist )

   Enter Find Mode

   Set Field (Artist; $value)

ELSE

   Go to Layout ( Artwork )

   Enter Find Mode

   Set Field (Artwork; $value)

END

Set Error Capture (ON)

Perform Find

IF ( Get(LastError))

   Go to Layout ($layoutNum)

   Show Custom Dialogue ("No records found")

END

 

On the Indexing issue...

I guess its not an indexing issue then. I didn't realize that you're doing this over a network without FM Server. Does the summary layout sort quickly when you view it on the host machine? If so, and it is only slow over the network, then I guess this is a limitation of your network speeds or inefficiencies of this setup as opposed to using FM Server.

[Wickerman]

Great Matthew -- once again, very helpful.  In this database, there is never an artist record without a child artwork because the solution is only intended to catalogue actual artworks in a physical collection.    I think I'll stick with using the actual Artwork context here because there are about 20-25 fields that need to be searchable (it's not just title or name fields -- its medium, nationality, year, dimensions, etc. etc.) so I'd think I'd have to have a Variable / step to check every one of the potential search fields.

 

Will continue to test the sorting thing....

 

Thanks again!