Searchable Virtual list

[Chris Scalzi]

I'm not sure if this has been answered before but I'm trying to figure out if there is any way of making a virtual list searchable. I can create buttons that will modify the eSQL search and add parameters to the search in a fairly complex way but I'm talking about just hitting the search button and searching within the table.

I know that calculation fields cannot be searched, I have also attempted to make a text field with a calculated result with full indexing and it seems to still not be working. Any thoughts?

[bruceR]

Why do you imagine they can't be searched? This was one of the first feature I demonstrated in early articles on the technique.

Perhaps you don't really mean search at all; you mean indexed. In that case - yes, unstored calcs cannot be indexed.

But as with any problem. What is the problem? What are you trying to do?

[bruceR]

"I can create buttons that will modify the eSQL search"

It would be helpful if you describe what you're doing here. There is no eSQL in a virtual list setup. Though you can collect your dataset in any number of ways. Not even sure what "eSQL" is, for that matter.

[Chris Scalzi]

When I wrote "eSQL" I was referring to the ExecuteSQL function which I am using to gather my data for the Virtual List.

Thinking about it further the biggest issue I am having is that my Virtual List is within a Portal and I need to be able to search the Portal. I am thinking this is more of a Portal searching issue than a Virtual List issue. Does that make sense?

Edited September 13, 2015 by Christopher Scalzi

[bruceR]

Please give more concrete examples or provide an example file.

Perhaps you mean a portal filter?

Even if you are using ExecuteSQL to gather the data there are still a lot of ways to generate a virtual list. Putting all the values in a single global field or single global variable is just one.

Vlist Search.fmp12.zip

Edited September 13, 2015 by BruceR

[Chris Scalzi]

Thanks for this example file Bruce! I must admit I'm still deconstructing it. I notice that you are using field repetitions instead of a variable array, is there a benefit to this method or is this just another way of doing it?

[bruceR]

If you look again, I am demonstrating many methods of displaying list data. The difference in esults is obvious when you try doing what you asked about- performing finds.

[Chris Scalzi]

There are some great examples in here, and yes they are all searchable.

If the data was in a portal the only way I can think of searching it would be to define a portal filter by a variable and then have it sort by that field.

[bruceR]

And what did you observe about the performance of the find operations, when comparing the methods?

There is a pretty substantial difference; near instant vs tens of seconds.

Define a portal filter by variable then sort by that field? Search? Sort? You seem to be mixing up your terms.

Please provide an example file.

[bruceR]

Can we see an example of what you are trying to do please?

And some clarification of the terminology?

[Chris Scalzi]

Sorry, i typed sort by accident , I meant search.

I think I've realized that the problem has nothing to do with Virtual Lists and is entirely a question on how to search for data that is within a portal. 

[bruceR]

Sort of. Since the contents of a virtual list usual are stored in some kind of user specific storage, such as a global field or global variable, you can manipulate the contents of the variable by script, then refresh the window or portal.
Say you're using $$list to hold the values; then you could:

Set $$holdList to $$List

set $$List to leftValues( $$List; 3)

Refresh the portal; and now you see the new list.

You can also restore the old list and refresh again.

You can do more sophisticated thing when "walking" the values of $$list to perform your "find" operation.

You don' t have to do anything to the portal itself, you do not need to add a filter.

Edited September 17, 2015 by BruceR