As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only.
Join the TIBCO Community TIBCO Community is a collaborative space for users to share knowledge and support one another in making the best use of TIBCO products and services. There are several TIBCO WebFOCUS resources in the community.
From the Home page, select Predict: WebFOCUS to view articles, questions, and trending articles.
Select Products from the top navigation bar, scroll, and then select the TIBCO WebFOCUS product page to view product overview, articles, and discussions.
Request access to the private WebFOCUS User Group (login required) to network with fellow members.
Former myibi community members should have received an email on 8/3/22 to activate their user accounts to join the community. Check your Spam folder for the email. Please get in touch with us at community@tibco.com for further assistance. Reference the community FAQ to learn more about the community.
Do not do it for a couple of reasons: 1. Pure usability ... who in their right mind will want to scroll through 2800 options? 2. All the other problems this will cause ... there is a limit to the number of variables that you can pass to a request, and the size of a request. It is large, but you will open that door if you do this.
Think of a solution that doesn't require you to load such a large number of options.
"There is no limit to what you can achieve ... if you don’t care who gets the credit." Roger Abbott
dhagen is correct. This amount in a select can cause issues.
However there are times when these things become essential to do. If this is what you want to do then you need to examine where the hold up is. Where are the records coming from and how much data is involved.
I have a select with 27,000 items (ask the users not me!), which loads in less than 15 seconds, albeit the fields are only 4 characters.
The !IBI.FIL.ddname technique is not slow per se. WF builds a page and then sends it to the browser, not a big deal.
Questions are, how long does the request to get the records take to process? Can the record length be reduced at all? Perhaps there is no good answer.
Alan. WF 7.705/8.007
Posts: 1451 | Location: Portugal | Registered: February 07, 2007
Another way to approach the usage and possibly reduce the retreival time, is to have an 'onChange' event for the box so as the user starts to type in 1 or 2 characters you can use AJAX to retreive a much smaller record set and refresh the drop-down list.
Another approach would be to set up an 'A, B, C,...1,2,3...' set of links above the list box so the user could choose the first character of the item and then retreive just those items.
Either way you can still do a multi-select by holding whatever they select in a hidden field with the same name as the parm and just keep adding to it until the press submit.
I hope this helps.
Greg
Greg
current client: WF 8.1.05 & 8.2 - Windows 7 64bit - Tomcat 7 - MRE / BID - IE11
I just read this topic. I want to repopulate a list-box (filled with !IBI.FIL.). This is created by calling a fex with a Parameter. F.e. &C='A'. The is filled with all records which begins with 'A'. I think you have found a answer to this issue. Can you share your SECRET?
Here a quick fex I frequently use for user searches. It takes two parameters: &SEARCHTYPE is a user-selected operator of Begins, Contains, or Equals. &NAMSRCH is the search string.
-DEFAULT &NAMSRCH='AT'
-DEFAULT &SEARCHTYPE='Contains'
-SET &NAMSRCH=UPCASE(&NAMSRCH.LENGTH,&NAMSRCH,'A&NAMSRCH.LENGTH');
-SET &SNAM=IF &NAMSRCH GT ' ' THEN (&NAMSRCH || '%');
-*
JOIN CLEAR *
TABLE FILE CAR
PRINT CAR
BY COUNTRY
ON TABLE SUBHEAD
"Car Search Results"
" "
-IF &NAMSRCH EQ ' ' THEN GOTO SKIPNAMSRCH;
-IF &SEARCHTYPE NE 'Begins' GOTO SKIPBEGIN;
WHERE (CAR LIKE '&SNAM' );
-GOTO SKIPNAMSRCH
-SKIPBEGIN
-IF &SEARCHTYPE NE 'Equals' GOTO SKIPEQUAL;
WHERE (CAR EQ '&NAMSRCH' );
-GOTO SKIPNAMSRCH
-SKIPEQUAL
-IF &SEARCHTYPE NE 'Contains' GOTO SKIPNAMSRCH;
WHERE (CAR CONTAINS '&NAMSRCH' );
-SKIPNAMSRCH
END
you easily modify this to populate your list box.
Regards,
Darin
In FOCUS since 1991 WF Server: 7.7.04 on Linux and Z/OS, ReportCaster, Self-Service, MRE, Java, Flex Data: DB2/UDB, Adabas, SQL Server Output: HTML,PDF,EXL2K/07, PS, AHTML, Flex WF Client: 77 on Linux w/Tomcat
Posts: 2298 | Location: Salt Lake City, Utah | Registered: February 02, 2007