Re: today's how-best-to question...

Question for you: How would you envision a user using a 9,999 line subfile? That is something on the order of 500 page-ups & page-downs. If you add a scroll bar they can easily zip through the subfile but its almost impossible to stop the scrolling on the page the user wants.

My answer to your question is to ask that you consider some sort of process that will divide your listing in some arbitrary way and keep the list at 2500 or so records.

Also, use the scroll bar! It really helps the paging problem when there are lots of pages and its only one word of coding, although it does use 3 columns of real estate.

(Here is a screen shot that shows what the scroll bar looks like.
http://www.martinvt.com/Code_Samples/2_subfiles/2_subfiles.html )

Bryan Dietz wrote:

I have a how-best-to question:

I have a utility program that gets a list of objects using the QUSLOBJ API then retrieves info about each object in the list and displays in a subfile.

The problem I ran into is that if the list has more than 9999 records it blows up the subfile.

As I see it I have two choices; "page at a time" subfile or a UIM panel.

I know that a UIM panel would not have the 9999 record limitation and I have used them.

I can see that a "page at a time" subfile works well for data from a file, or "file like" source. I am struggling to figure out how best do the same with the list api data in the user space.

I am thinking of cranking thru the list api and building a temp dtaq or file to store the data then read from there to populate the "page at a time" subfile. I worry about the performance having to essentially read the data twice to show the first page.

I am not inclined to use the initial user space as I would have to keep retrieving the object info for each page up/down request.

Bryan
--