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?

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?

"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.

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, 201510 yr by Christopher Scalzi

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, 201510 yr by BruceR

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?

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.

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.

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.

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

And some clarification of the terminology?

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. 

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, 201510 yr by BruceR