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. Moving forward, myibi is our community platform to learn, share, and collaborate. We have the same Focal Point forum categories in myibi, so you can continue to have all new conversations there. If you need access to myibi, contact us at firstname.lastname@example.org and provide your corporate email address, company, and name.
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.
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.
-SET &SNAM=IF &NAMSRCH GT ' ' THEN (&NAMSRCH || '%');
JOIN CLEAR *
TABLE FILE CAR
ON TABLE SUBHEAD
"Car Search Results"
-IF &NAMSRCH EQ ' ' THEN GOTO SKIPNAMSRCH;
-IF &SEARCHTYPE NE 'Begins' GOTO SKIPBEGIN;
WHERE (CAR LIKE '&SNAM' );
-IF &SEARCHTYPE NE 'Equals' GOTO SKIPEQUAL;
WHERE (CAR EQ '&NAMSRCH' );
-IF &SEARCHTYPE NE 'Contains' GOTO SKIPNAMSRCH;
WHERE (CAR CONTAINS '&NAMSRCH' );
you easily modify this to populate your list box.
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