As soon as you stop using bound controls you get generic data-handling form class, which at the same time does not require DE (i mean private DS), because again it's unbound.

>Essentially, this is a mini-form with data entry fields and a key list to quickly select a record. This is why it's important that it's a class for generic data handling purposes.
>
>
>>Maybe I misunerstood. What controls (if not grid) you want to include to this container? Personally, I never bring up memo field directly to grid. If memo is not critical then 'View Memo' column.button is good solution, if critical then some editbox outside the grid may show current record memo content.
>>
>>>It's not a structural issue with a grid, it's the fact that a grid is awkward with the text heavy tables I'm working with....the grid...welll...to be frank, sucks for this type of table with memo fields, et al.
>>>
>>>>>
>>>>>>Hi, John! Sounds pretty familiar :). Did we discuss it before?
>>>>>
>>>>>Yes, I think I brought it up once before but the issue has reared its head again. I have a subtable that I want to browse through *without* a browse (there are memo fields) and I don't want a subform. So I was thinking of doing this container and I didn't want to reinvent the wheel.
>>>>
>>>>I don't think that separate container class is really needed. What prevents you from opening subtable with another alias and base grid on it?