list a found set

[msadesign]

I was thinking that I could do this with a portal so I posted here. And I have not yet been able to do what I want.

Which is to have a list of the found set appear on the screen without leaving Browse Mode. My Browse Mode screen is a record about a single plant, and I search using various criteria to create a list; and then want to click the list so I can see more info about the plant. I hope this isn't so confusing.

I tried a portal based on a self relationship but this won't work. Am I trying to do something impossible? I also tried having a new window appear, with the found set in a list view, but was unsuccessful withat that as well.

Michael

[Raybaudi]

I tried a portal based on a self relationship but this won't work.

Hi Michael

the portal is the solution...

but you have to make the right relationship.

Wich records do you want to see ?

[msadesign]

Thanks! Here is more info, and I hope I don't include anything that is not needed!

My solution is called 'Plant Data Base '[pdb].

When a user opens the file, she sees a record for some [any] plant. I call this the 'base record' for convenience.

In this record, the user can search many ways, but the one of most interest is the ability to check any of more than 20 plant characteristics [tolerates wet feet, or fragrant flowers, for example].

Once this criteria is entered and the search returned, the user still sees a 'base record', but of course the found set has been restricted to the results of the search.

I want the user to be able to do this: to see a list of the found plants, and then click on any of them, and have the 'base layer' change to the clicked plant. In this way, she can quickly compare materials.

Is this clear? I hope so!

My most important key field is called 'symbol'; this is a unique 4-character text symbol. I tried making a relationship based on this field, then using this for a portal, and it didn't work.

Thanks for your help!

Michael Spencer

[Raybaudi]

Ok

I'll make a new table with only the "base record" format and a (some) global field, needed for the relationship ( s ).

For exemple a global field with a list coming from values of field pdb::plant characteristics.

Than a relationship from this global field and pdb::plant characteristics

The portal based on this relationship will show only some plant, those with the same characteristic

[msadesign]

Trying this now and will report.

We just returned from 5 weeks in India, where the time difference is 11.5 hours- not quite so bad to Italy.

Michael

[msadesign]

OK, did some work with this but don't have it [yet].

Everything as of now is in one table [file, as I haven't moved my files into one when I upgraded from v6].

I did this:

1. make a new global field

2. give the global a value of 1

3. make the portal based on the global

4. this resulted in the portal being populated by every record in the db, rather than only the records in the found set.

What am I doing wrong?

[comment]

I don't see why you need a portal or a relationship. It seems that all you need is another layout to view the selected record in detail.

Place a button in the body of your current layout, and define it to Go to Layout [Detail]. Or, if you prefer, have it run a script that opens a new window and switches to the detail layout.

[msadesign]

Maybe not. But what I am trying to do is show a list of the found set. I tried another layout but it's in another window [not wanted unless there's another way around], and it will not update and be populated with a changing found set.

I need the original layout to be visible because as the user goes through the found set, looking for the plant she wants, the data about each plant is in the original alyout.

Does this make sense?

'Go To Layout [detail] would work but would be awkward when, during the design process, we are looking at 50 plants or so.

Michael

[msadesign]

Maybe it is not even possible to have a list inside another layout? a list that is populated by the found set, and which automatically is updated?

Michael

[comment]

I got a bit lost in your explanation. If you have a found set, you can display it as a list in Browse mode. I don't know why you would need "a list inside another layout", when the layout itself can be a list.

It *is* possible to have a portal displaying the found set, but it is not a simple task.

[msadesign]

I got a bit lost in your explanation.

It wasn't a very good explanation! [if I could easily post images I would].

The user sees a master record that includes relevant information about a particular plant- picture, names, horticultural data, etc. I want her to search for a desired set of plants and have this list of plants appear on the master plant record. Then, I want to click on any of the found plants, initiating a record change, but retaining the list.

Example: say she is looking at the master record for coconut palms. And she wants to consider other palms. So, for example, she searches for palms, and for salt tolerance, and for disease tolerance.

This gives her a list of suitable palms that meet this criteria. She clicks on one of the palms, date palm, as an example, and then she sees the master record for date pal rather than the master record for coconut palm.

If you have a found set, you can display it as a list in Browse mode. I don't know why you would need "a list inside another layout", when the layout itself can be a list.

Well, I DO need / want this, because I am convinced it will make the process of choosing and comparing plants much faster.

It *is* possible to have a portal displaying the found set, but it is not a simple task.

Perhaps you are willing to describe the process for me? or, point me in the right direction?

Or, perhaps I am looking at this in the wrong way?

Michael

Edited January 4, 2007 by Guest

[Raybaudi]

What am I doing wrong?

I think your relationship.

Can you post a clone ?

[comment]

1. You CAN post images very easily - go to Full Reply and attach a image file.

2. Here's a link to a demo of found set in a portal.

3. Here's another possibility for you to explore, which is MUCH simpler to implement.

List_Details.fp7.zip

[dwins]

Comment posted ahead of me. So I'll say it this way.

I don't see anything in your plan that would not be solved by simply putting all your displayed fields on the header, and just have the name field(s) on a one-line body.

You'll have the expanded info of the selected record displayed at the top, and your found set listed below. No portals, no self-joins needed.

If you want a separate "start" page with the search fields, that's just another layout.

[comment]

I have to admit I see the attraction of a sidebar portal, similar to what is now practically a standard for OS X apps.

I have just remembered I did post a demo of a found-set portal, which I think is easier to implement than Ray's - Link

[Genx]

That's quite interesting example, but how do you grab related data (i.e. the data that relates to each of the id's held within the repeating field)?

[comment]

Sorry, can't figure out what your question is.

[Genx]

Don't worry, I had a dream about how dumb a question that was last night (not joking) lol!

So esentially, a repeating field will behave the same way in a relationship that a return delimited set of vales in a field will? i.e. as a multi-key?

[Genx]

Just a quick thought, but because a repeating calc is limited in size to whatever you set it... and each of the repititions has to calculate even if it's empty, couldn't you just use a standard calc and call a recursive cf? Only a question, and more relating to speed than anything else.

[comment]

Yes, but a repeating calculation field is really easy to set up here - easier than a custom function with a confusing dummy parameter, I think. And you don't need Dev/Adv for this.

I haven't tried it with high number of repetitions, but I don't think it should be a problem, since the calc exits at the first step. Of course, this is only a conjecture - you'd need to perform actual speed tests to make sure.

[Genx]

Cool, was just curious, I guess it's one more trick I can do with repeating fields now :D

[msadesign]

I am starting to understand why it is so hard to get help on this one. As one person said:

I don't understand your question

And of course this is true as it wasn't phrased very well. So, I attached a mark-up of how we want this to look when it is complete [it's rough, so don't be too hard on me!]. Notice on the attachment the lower right corner shows, first, a portal displaying information about plant material size availability as reported by local nurserymen. Above this we would have our Found Set of plants. I show it as a portal because this is what I have been playing with as I work through the ideas presented in this thread.

We are landscape architects and, from time to time, are required to prepare a planting plan. We have gathered data in a solution called PDB, and want to be able to narrow down the choices using one window. The design process goes like this:

1. first, search on any of the fields, according to the specific location; examples would be hydric/xeric, deciduous, wildlife value, etc.

2. then, have this Found Set appear as a list on the same layout we used for searching;

3. click on any of the found set to reveal more info, including pictures, and either accept the plant or omit it from the Found Set;

4. and finally resolve the list to one plant, and then specify this plant on our drawings.

Of course, we could simply browse through the found set in the normal way. I don't want to do that because I think the way I envision this working would just plain work better.

I'm working through some of the sample ideas that have been offered. I am not sure if the method of putting everything in the header would work but it seems to have promise; the major drawback of this method is that you cannot select fields in the header for further search refinement [at least I don't think so, as I write this, before I actually try it].

Thanks again to everyone, it's appreciated more than I can say.

Michael Spencer

msadesign.com

pdb.pdf

[comment]

Both Ray's demo and mine (the one I linked to, not the one I posted here) should fit your scheme.

Another option you should consider is using a relationship INSTEAD of a search. IOW, you'd enter the search criteria into some global fields, then use these to filter a relationship. The resulting set would be displayed in the "found set" portal.

[msadesign]

Problem is now solved, and thanks to all. I simply put everything in the header. I attached a screen shot. Lots of UI work to do but now the functionality is there.

Thanks again.

Michael

pdb2.pdf