Continous form vs List Box. Which is faster/better?

[gringope24]

Hello Folks,
I am considering two options for design of my forms: continuous form vs listbox.
Form is the part of control tab and the whole database is a splatted to front and back end via server in my Company.

Have already somebody had any conclusions about using one or another?

1. Continous form
pros:
+ nice looking
+ action button in each row which allow to easily copy, delete the record
+ allow dynamic input of data

cons:
- action button in each row which multiplies objects to display
- probably slow performance on loading

2. List box
pros:
+ compact design
+ probably fast performance on loading

cons:
- necessary to open new form to edit or create new record
- no fency look

 

[arnelgp]

prefer continuous form over listbox.
can easly insert/edit/delete record. no need additional separate form.
you can filter it. you need additional code for the list.

but all is up to you.

 

[Ranman256]

You don't even need code for the filter,
Add a combo with queries.
User picks from the querylist,it filters the list.

 

[gemma-the-husky]

A list box is completely different to a continuous form.
A list box corresponds more to a combo box, in my opinion. A similar way of presenting data that takes up more screen space.

 

[gemma-the-husky]

+ action button in each row which allow to easily copy, delete the record

Why would you want to copy a record in a continuous form? I mean you might, but that wouldn't be common at all. You can delete records in any bound form. Just press the delete key. What we tend to do is remove that option, and add a button to manage deletes, to prevent injudicious deletes. Often it's much better to add a check box to indicate deleted items.

I just don't see how the one is a substitute for the other.

 

[MajP]

I do see how one can substitute for another because how I design my databases.
I normally always have a navigation form that is in continuous view. That form has features to sort or filter on any column to allow rapid finding of a record. From there you click on the record to edit or view a specific record. Sometimes that is a main form with a subform and sometimes that is a main form with a large listbox. In each case this is navigation so it is purposely not editable. For data integrity purposes I usually always seperate search, filter, navigate from add, edit, delete.

I do not think speed is an issue for form vs list. Design would be a bigger issue. If this is a very large split database, then in either case you would load the form empty and force the user to provide criteria to search and pull relevant records. If small you can load everything and filter out and not worry about it. In my case it is mostly aesthetics since they both serve only the purpose of data presentation for navigation purposes.

If I want a continuous list that is editable directly (which is rare) then that is a different issue. As I said, in my normal designs lists are for searching and navigating and single forms for add, edit, delete which gives a lot more options for data control/integrity.

 

[Isaac]

While I agree with the others that the implication one is a clear substitute for the others is a bit tenuous, I do understand (I think?) the comparison you are drawing.

All I will say is there is one technique I use A LOT, and I am very happy with its performance and simplicity. That is, a bound form which hosts a Listbox in its upper half. When an item is selected in the listbox, the Form's recordsource is set to that record, and detail items of the host form become visible.

I do this all the time. It's easy to understand, universally clear to the end user, etc. So I suppose you might say I might go for the Listbox in your comparison.

But there is a time for both/either.

 

[gringope24]

Thanks everybody for discussion.
Dear Isaac, thanks you for discription but can you share the some screenshot to visualize your approach?

Below I paste the same data presented in different ways.

Continous Form:

Listbox:

 

[Isaac]

I looked around for ones I have handy and they are just chock-full of content I'd have to redact for my company's and my own privacy - so much would be redacted you'd hardly be able to see anything useful. But basically just picture a large form (frmMain). On frmMain there are two main sections. A top section (covering maybe the top half of the form), is a wide listbox. At its top are a few gadgets for sorting and for filtering the listbox results. Every listbox record has, of course, the record's primary key ID. On the bottom half of the form are details - bound controls, textboxes, and the like.

When the user clicks a record in the listbox up top, one simple line of code runs:
Me.Recordsource="select * from table where ID=" & me.listbox.column(1)

Of course, this approach tends to work when there is NOT the need to be editing child records to a parent record.

 

[Pat Hartman]

You can also use a subform in DS view which looks much more like a listbox but gives all the functionality of any other form. You can even hide the borders of subforms and make them appear to be part of the main form if that makes sense. I've had a few cases where the contents of a subform would be fixed and limited so they never needed to scroll and records would never be added or deleted except when the parent record was created.
For example, you might have a process that required four signatures with dates. You could add the four rows in the AfterUpdate event of the parent record and make the subform look like just four date/signature boxes embedded on the main form.