13 Replies Latest reply on Feb 6, 2017 11:51 AM by siplus

    Portal filtering of a virtual list

    jakebutt14

      Hey everyone -

       

      I have a contacts layout where the left side of my layout is a portal which shows a list of the contacts stored in the database, while the right side shows details for the selected contact. The portal is generated using the virtual list technique; in my virtual list table, I have a field I'm calling "display_full" which stores all of the info that I want to display for each contact (in this case, full name, company, and title).

       

      I want to be able to filter this portal based on a global find field using pattern count on the display_full field so that users can perform a find based on either the contact name, company name, or title. I'm using the following filter formula:

       

      Let ( [

        ~find = UTILITY::FIND ;

        ~display = VirtualList::display_full ;

        ~pattern = PatternCount ( ~display ; ~find )

        ] ;

       

      Case (

      not IsEmpty ( ~find ) ; ~pattern ; 1

      ) )

       

      I'm also using a script trigger to perform refreshing to keep the portal updated. It appears that my filter is only working on the first "record" in the virtual list table. Meaning, when I type into the global find field, if I enter criteria that matches something in the first record of the virtual list table, the filtering appears to work exactly as expected. However, if I enter criteria that I know should find for any other record, the portal filters down to no values.

       

      Is there something I don't know about using an unstored calc as the basis for this filtering? "display_full" is unstored since it's being used to extract the virtual list data. I have used a slight variation of the filter formula elsewhere in the database but trying to filter a "normal" portal (i.e., one based on a data table, not the virtual list table) and it works exactly as expected, so I'm pretty sure my formula is correct for my intent.

       

      Any one have any thoughts on why this may be happening? I'm trying to use the virtual list technique more these days, but maybe I have extended myself a little beyond what it is meant to be used for?

        • 1. Re: Portal filtering of a virtual list
          siplus

          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.

          • 2. Re: Portal filtering of a virtual list
            BruceRobertson

            "you are using 2 different relateds (nothing wrong there):"

             

            Not really. Utility::find is claimed to be a global field.

            • 3. Re: Portal filtering of a virtual list
              siplus

              I took that for granted, Bruce... jakebutt14seems to be more than a novice

              • 4. Re: Portal filtering of a virtual list
                jakebutt14

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

                • 5. Re: Portal filtering of a virtual list
                  BruceRobertson

                  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.

                  jake:

                  Layout mode screenshot please. What exactly is the TO for the layout?

                  What is the TO for the portal?

                  • 6. Re: Portal filtering of a virtual list
                    BruceRobertson

                    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?

                    • 7. Re: Portal filtering of a virtual list
                      jakebutt14

                      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.

                      Virtual list variable.png

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

                      Virtual list table.png

                      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.

                      layout.png

                      • 8. Re: Portal filtering of a virtual list
                        BruceRobertson

                        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.

                        • 9. Re: Portal filtering of a virtual list
                          jakebutt14

                          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:

                          Screen Shot 2017-02-06 at 1.00.38 PM.png

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

                          Screen Shot 2017-02-06 at 1.13.48 PM.png

                          • 10. Re: Portal filtering of a virtual list
                            BruceRobertson

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

                            • 11. Re: Portal filtering of a virtual list
                              BruceRobertson

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

                               

                              Virtual+list+corrected.png

                              • 12. Re: Portal filtering of a virtual list
                                jakebutt14

                                Changing the display_full field to use "serial" instead of the Get(RecordNumber) calc fixed the issue; thanks for the help.

                                • 13. Re: Portal filtering of a virtual list
                                  siplus

                                  Conclusion: don't mess with Bruce.