c.grimsby@worldnet.att.net.invalid (Chuck Grimsby) wrote in
<8me4nvoanfp91m078654ilact1buo0ki1i@4ax.com>:
[color=blue]
>
>Comments in-line...
>
>On Wed, 24 Sep 2003 16:12:00 GMT,
dXXXfenton@bway.net.invalid
>(David W. Fenton) wrote:
>[color=green]
>>c.grimsby@worldnet.att.net.invalid (Chuck Grimsby) wrote in
>><nnl1nvk0hbqlbs25oj1q61nl2rk449ft2l@4ax.com>:
>>[color=darkred]
>>>I avoid the use the subforms, continuous forms, datasheets, etc.
>>>like the plague! But I should mention that I do that in all my
>>>apps, not just the SQL Server ones. (The last time I mentioned
>>>that I got blasted by other members of the group here. I
>>>remember the last discussions on it people, no need to repeat
>>>them.) Personally, I just don't like the "look and feel" of such
>>>things, but in "remote" databases such things lock more records
>>>then are really needed and tend to do nothing but slow things
>>>down. Users may want to *see* a bunch of records, but they are
>>>only going to work with 1 regardless of how many are on the
>>>screen. A unbound list box takes care of that, and won't lock
>>>the records.[/color][/color]
>[color=green]
>>I don't want to rehash the old discussion, but short lists (<100
>>records) are very much a needed feature in any application.[/color]
>
>Agreed, but so are long lists. . . .[/color]
I disagree with that in regard to UI implementation. You should
never present more than 100 or so items to a user, and any time
you're presenting more than 10 or so, you must have a clear
organizational principle for ordering them that is organic to the
kind of data you're presenting (e.g., invoices should be in invoice
number or date/reverse date order).
[color=blue]
> . . . What is optimal (for a list box)
>seems to depend on the application, so I'd rather not put a number
>on it.[/color]
Well, I think the issue is lists, not widget, and it doesn't really
make any difference whether it's a subform or a listbox or a combo
box -- more than 100 is something you should design around. I won't
go into the details of how to do that, as it's been discussed a
great deal in the newsgroup. But I will say that it's a pretty
important principle for designing not just user-friendly UIs, but
also helps you to be efficient with resources, since you won't be
dragging lots of unnecessary data across the wire.
[color=blue][color=green]
>>Single-attribute lists can be presented in an unbound form with
>>listboxes. But once you get to several attributes that can become
>>unwieldy.[/color]
>
>I can't say as I've had many problems working with multi-column
>list boxes myself, David. As I mentioned earlier, I often use code
>or a Stored Procedure to do most of the work for me so perhaps
>that's part of it? No idea.[/color]
It's not the data retrieval part of it that is problematic. It's
the presentation that I have problems with, and the updatability of
it once you've edited a record in a detail form and then need to
refresh the listbox that displays the same data in the list
version.
[color=blue][color=green]
>>Also, if you edit a record that has been presented in a
>>listbox, you still have to hit the server to update the unbound
>>list.[/color]
>
>That will rather depend upon *how* you populate the list box. If
>you use a "User-Defined Function" to populate the list box (or
>combobox for that matter, although I've never had a need to use a
>UDF on a combo box), there's no need to hit up the server at all
>once you're past the initial load. The UDF can update the list
>box without the need to link up at all. (Admittedly however, I
>usually do though. It gives me and the user some confidence that
>whatever they did actually happened.) There's a fairly good
>example of using a User-Defined Function in Access help if you
>want to give it a try. *Really* nice for long lists of
>information, like progress and error reports![/color]
But for multi-column lists of any number of rows, a UDF is far, far
slower than SQL. Yes, I've used UDFs because sometimes what you
need to display can't be done with SQL (or, not efficiently).
But I don't see how that's a fix -- the data still must be
retrieved, it still needs to be refreshed. It's a hit on the back
end, and that's what you were worrying about causing you to avoid
continuous forms.
[color=blue][color=green]
>>Have you looked into disconnected recordsets in ADO? I haven't
>>used them myself, but the whole point of them is to address
>>precisely the problem you are raising.[/color]
>
>I have, and I've used them, I just prefer the other methods. It
>isn't a problem however. I should also note that List Boxes are
>also rather nice for those cases where the user has to do updates
>to multiple records. They can select which records to update
>(including the whole screen) and just click on one button, rather
>then scrolling through multiple screens of records in a 'hit and
>miss' methodology. With a list box they only 'touch' the records
>they need to, and don't touch the records they don't need to at
>all, regardless if they've narrowed down the selection enough.[/color]
That would be a good justification for it, yes, I agree.
But I still don't see any reason to avoid continuous subforms, none
whatsoever.
--
David W. Fenton
http://www.bway.net/~dfenton
dfenton at bway dot net
http://www.bway.net/~dfassoc 
