Let's see who else had/has this issue and who has/can resolve it.

The Setup: I created a Parameter Page in App Studio intended for use in a collaborative portal.
* This has has two radio buttons (columns = number of items available), drop down lists, a 'Submit' button set to 'Refresh' / 'Refresh BI Portal' / 'Current page only', and a reset button. This seems to be fine.

I want it to span the top row (panel 1), say 10%, with the next three rows (panels 2-4) set to 30% each.

The Issue: The drop down lists are longer than the the height of the top row, 10%, thus they are useless.

Solution: TBD. How can I expose the complete contents of these drop down lists? Something like 'bring forward'.?

I know that I can make the Parameter Page 'vertical' rather than 'horizontal'. But that's 'not acceptable to the users'.

Thanks in advance, Doug

Extra credit: drop down lists that are set to multi-select appear differently than their single-select counterparts.

This message has been edited. Last edited by: Doug,

Doug

Not sure which version you are using for this.. But, there is a new feature in 8.2.02 to allow these drop down lists to Pop-Up. I don't know if they will display outside the boundaries though...

How did you go about creating your filtering within AppStudio? You'll want to make sure you create them via the Requests & Data Sources panel's New > Requests > Parameters > Filter Panel option. This way the controls aren't bound within the iFrame like in previous releases, insomuch that a long drop-down will float over it's parent container bounds.

FP Mod Chuck, WebFOCUS 8202M

I guess my signature is too busy...

CoolGuy, The parm page was created in the HTML composer. Then I added three panels, one for each row of outputs (fexes).

This message has been edited. Last edited by: Doug,

So, you are attempting to use AppStudio's HTMLComposter tool for the actual page as well as your filters then. Sorry, I didn't catch on to that. My suggestion: Don't. Our site only ever uses that tool for filters now. I would drop your filters made in AppStudio's HTMLComposter tool into a page template from within the WF Home screen's Page Designer tool (not the new WF Designer product, but the Portal Page designer). That's how we do it, and it works great.

That sounds great. I'll shoot for that. You going to Summit. I'm planning on it.

We were up till yesterday, when we found out we weren't approved to go. Enjoy your time there! Should be a great year from what I've heard thus far.

Another Ata Boy for CoolGuy. The filter panel just may workout for me.

Thanks CoolGuy, You Made my day.

The creation and use of a "Filter Page" works wonder.

BTW: Complete portal was done with No Need for Any JavaScript. Oh Happy Day.

Glad to help. This way of doing it is just way better than ever attempting to use the HTML Cantvas tool in AppStudio for it. It's good for filter creation, but past that? Nope.

... Just need to remember to add all variables and procedures to the Parameter Setting in the Filter Page.

Hi Doug and Cool Guy

We have a similar setup in that a filter panel was created in the App Studio HTML composer and is being used in an 8.2 responsive portal (not a collab portal). The issue we are facing is the time it takes to populate in the filter panel.

For the larger dropdown lists, we are pointing to a FOCUS table that is refreshed each night and contains the data needed to populate the dropdown.

The reports and charts within the portal respond quickly when the parameters are changed. It is the initial loading of the filter panel itself that is slow.

The filter panel is set to refresh the current page only but the same filter panel is used on multiple portal pages (Users want to filter each page independently). We also have a lag when switching between portal pages.

Do you have any tips or best practices we may have overlooked?

Appreciate any insights.

Thanks,
Barb

Barb, tips or best practices: It depends on where your source data resides. What I have found to be the best solution is to bring only the required fields from the remote source down to a FOCUS file in the associated App Folder and use that for the source of the drilldowns.

Others may have alternatives. I'm always eager to learn from them about their thoughts and alternatives.

Barb,

As Doug reiterated, and you said you were doing already, if you can hit a smaller subset of data specific to the drop-downs needing loading within a pre-loaded FOCUS data set, that sometimes helps. How large of a list is your drop-down? Can it be broken up somehow into smaller pieces? What's your queries/code look like that populate the drop-downs? Maybe there's something that can be optimized? Also, where is it being pulled from? A huge detail-level data set or something that has been cleaned up and optimized for fast retrieval? Like can you create another source data set that's rolled up somehow before bringing it into the BI environment?

Hello-

Thanks for the replies. For the larger dropdowns, I used the Requests and Datasouces tab to include the FOCUS datasouces that are limited to the specific fields. For the combo boxes, in the Settings tab, I pointed to the FOCUS data source as the default and referenced the specific column.

What impact, if any, does checking the 'Cache Runtime Data' on the Settings tab have for the comboboxes?

Never used it before, but always good to test it out and see what break...happens.

LOL.that's usually my approach, let's see what happens if... In this case, no noticeable difference with or without it checked

That's no fun. Best of luck!