How doe these global variables get values?
What value or expression are you passing as a script parameter to the script?
PS. since 2010, when this post was made, methods have been worked out for setting up filtered portals that do not need a script with the Refresh Window [flush cached join results] step--a step that can greatly slow down screen updates in some situations.
$$Dept and $$count are set when you click on a button that takes you to the horizontal portal, $$group is being set when you click the scroll button, and the parameter passed to the scroll script is 1 or -1 dependent of you scroll up or down.
Should have asked this question last time: What is the relationship used for this portal?
I keep coming up against the fact that you are filtering your portal by the value in $$Dept, but this expression:
indexValues = List ( PF OITM Items 2::ItemCode ) ;
index = ValueCount ( Left ( indexValues ; Position ( ¶ & indexValues & ¶ ; ¶ & PF OITM Items 2::ItemCode & ¶ ; 1 ; 1 ) ) )
works off the list of ALL related records--not just those that match by the value in $$Dept.
Without actually downloading and decompressing Comment's example file to check to be sure, I suspect that this is where the problem lies. You may need to modify your relationship to include a match by Department instead of including it as part of the filter.
The parent for the portal is invoice, and invoice does not have a field for Department. The relationship is set to PF OITM Items 2::id X Invoice::id. This is the difference from Comment's example, in his example the relationship is parent::id = child::parentid
Yes, the expression used for the portal filtering works off the list of all the related records, so I was hoping that adding "PF OITM Items 2::U_Dept = $$Dept and Let..." would limit the list to just a subset of records that equals the Department.
I was hoping that adding "PF OITM Items 2::U_Dept = $$Dept and Let..." would limit the list to just a subset of records that equals the Department
It does not. Calculations that refer to related records bypass any filtering specified for the portal. The filtering has to take place at the relationship level before they will evaluate correctly.
You can define a field in Invoice for department and your script can update the field like you currently do with the variable. It can be a field with global storage so that setting this global field need be done only once and all records in Invoices will be able to use this value in the relationship. (Match fields on the Parent side of a relationship may be global or unstored calculations and they'll still work for matching to records in the child table.)
This is how you filter a relationship at the data level so that calculations such as List will return a value that is controlled by the value set in the field. (It's also how we did all this stuff before we had the option of specifying a portal filter.)
Thanks PhilModJunk, that solved my issue with the scrolling!