you are using 2 different relateds (nothing wrong there):
~find = UTILITY::FIND ;
~display = VirtualList::display_full ;
but we don't know on what TO your portal is based.
"you are using 2 different relateds (nothing wrong there):"
Not really. Utility::find is claimed to be a global field.
FIND is global, and the portal is based on the VirtualList TO... it's definitely showing all of the expected data/records without the filtering, so I'm sure I'm generating the virtual list properly. Is there any reason that the filter wouldn't work properly on an unstored calc? Or is it possible my window refreshes doing something to the calculations where it's trying to perform the filtering prior to the virtual list being generated, or something like that?
I appreciate the help in advance... this has been frustrating me for a few days, can't decide what I think the issue is here...
I really have no idea what that is supposed to mean in any way that can be acted on. You mention and show two relations and claim this is important; and then say you recognize that one doesn't matter; the field is a global.
Yes, knowing about the graph, the layout TO, and the portal TO would all be helpful in solving this problem.
Layout mode screenshot please. What exactly is the TO for the layout?
What is the TO for the portal?
I think we'll need to know much more detail about your virtual list approach.
A clone or close replica would help a lot.
There are no returns in your display_full calc, right?
Hi Bruce -
I have attached a few screen shots here, hoping this helps but let me know if more info is needed. I can provide a clone if necessary, so if this doesn't look like enough info please let me know.
Following image is how I'm generating my virtual list variable. In a nutshell, it's pulling the contact name, contact title, and company name, and separating each with a pipe character. As you can see, the only returns in my virtual list are to separate the records.
Next up is my virtual list table. The above calculation populates my "display_full" field, then display1, 2, and 3 simply parse out the characters for each "field" of data (in this case, contact name, title, and company name).
Last, here is my layout. The portal displays the parsed out information. FIND at the top is where I'm entering the find criteria. Just as an additional note, I tried modifying some of my contacts so that the portal sorted differently (i.e., so a different contact was listed first than when I started this thread). I can continue to confirm that the portal filtering based on the data entered into FIND continues to work for the first record listed in the portal, but none of the others. Note that I sorting the virtual list records through the ExecuteSQL statement when generating my virtual list; there is no actual sort on the portal itself.
Of course it doesn't work.
There is a basic problem with your virtual list.
display_full should be
getValue( $$virtual.list; Serial )
Serial should be setup as auto-enter get( recordNumber) and you should have a script that populates that field for the desired list size. When done correctly the value in the field should be 1 to N where N is the record count of the virtual list table.
I have it setup very similarly to how you're describing, and I believe should have the same functionality. Basically, I have "serial" pre-populated with the record number for a bunch of otherwise empty records. Then, in my script which populates my $$VIRTUAL.LIST, I set a field called LIMIT (global field) to the number of values in the virtual list. This LIMIT field is used in the relationship for the VirtualList TO, as shown below:
This effectively makes all portals showing records from my virtual list table only display records for the number of values in the virtual list. As for the actual population of the display_full field, I am definitely getting my expected number of values and the expected content for each value, which is why I don't believe it's the population of my virtual list is causing the issue.
Should have included this before, but here is my portal filter calc... guess it's certainly possible I'm overlooking something simple here...
"I have it setup very similarly to how you're describing, and I believe should have the same functionality."
Well; obviously; you're wrong. It isn't working.
Set it up EXACTLY as I am describing.
display_full MUST be getValue( $$virtual.list; Serial )
Your failure to use the indexed row number field (Serial in your case; I prefer to name mine N) cannot EVER work if you do anything except display the full unsorted list.
What happens if you sort the list? What happens if you perform Finds on the list? Now record 1 is - the first item in the original virtual list! No matter WHAT you do. The calc must point to a stored, indexed, unique number field, not "get(recordNumber)".
Changing the display_full field to use "serial" instead of the Get(RecordNumber) calc fixed the issue; thanks for the help.
Conclusion: don't mess with Bruce.