RE: [WDSCI-L] Performance - perception is King

["Booth Martin" <Booth@xxxxxxxxxxxx>]

Buck, the 5250 scrollbar fatness is determined by the number you set.  There
is no reason I can think of why you couldn't set the size of the subfile at
any size you desire, even if you are doing page-at-a-time loading of the
subfile.  Personally, I usually get the file size in the INFDS at the
opening of the job, even if I am using filters.  That seems to work ok for
setting the scroll bar's fatness
 
 
 
---------------------------------------------------------
Booth Martin   http://www.MartinVT.com
Booth@xxxxxxxxxxxx
---------------------------------------------------------
 
-------Original Message-------
 
From: Websphere Development Studio Client for iSeries
Date: Monday, June 02, 2003 7:27:59 AM
To: Websphere Development Studio Client for iSeries
Subject: RE: [WDSCI-L] Performance - perception is King
 
>Is it possible that you (Toronto) are 
>populating the entire list before returning 
>control to the user? Is it possible to return 
>the first visible entity ASAP (first 
>screenful, e.g.)? 
 
This is one of those places the 5250 world differs from the GUI world. If
one doesn't load the entire list, how big should I make the scroll bar
'cursor'? Normally, GUI apps have a big fat cursor when there are only a
few items scrollable, and a teeny-tiny one when there are many items in the
list. Sure seems like a pain, but the time it takes to load that list is
one reason the GUI people use progress bars for 'long running' processes. 
 
I think it's just something I need to get used to. In Code, I create a
project which has fairly tight filters. Also, I have a strong tendency to
check members out into a very small 'development' library, where the time to
load every member is negligible. So now I have several small libraries,
each containing work in progress. I have no idea if the concept is
reasonable to keep editor/workbench performance high, or just another case
of me having low standards and being willing to work with... less than
optimum conditions.
--buck (at Code V5R1M0 for now...)