For wford - db class

All this allows alot of flexablity..I can add a field in any table and touch no code involved with database inputs or outputs..I can just modify it in the specific code..and in many cases I just add a text field to the form that edits that type of object and it is all done (I use the datafield property in a control much like it was a linked db)

as the objects are standard a lot of code like delete, save, update, cut copy, paste etc.. are also standard, as are many displaying controls like listview etc..

Adjusted points from 100 to 200

Answer accepted

Thanks, I think I understand better now.

>All this allows alot of flexablity..
>and in many cases I just add a text field to the form that edits that type of object and it is all done

Grrr... <envy>
New field to table means a lot of work for me, and often I generate complete table code again (I use code generator).
- in DB class:
I must change SQL statements in GetList() and GetData() functions

- in business class:
Add a pair of get/let properties, and a private variable

- in UI (form):
Add control, e.g. textbox, and add code in:
declarations, Form_Load(), Form_Unload(), UpdateRecord(), ClearControls(), then code to enable/disable editing, and code to show values (in ListView_ItemClick)

Well to take advantage of this I have a standard edit form template. EG the text fields are all arrays and the init form and clear forms simply use :

dim contx as control

for each contx in txt_field
contx.clear
next

as well as the code in the text fields themselves:
CurX is a public object for that form that is set on view function

fns_Change_Attr changes the any attribute with the proposed new text with checking and so forth.

fns_verify_Attr is needed for things like date formats that must be checked for the completed entry.

Private Sub txt_Field_Change(Index As Integer)
Dim stemp As String
If CurX Is Nothing Or bLoading Then Exit Sub
stemp = txt_Field(Index)
If Not fns_Change_Attr(CurX, txt_Field(Index).datafield, stemp) Then txt_Field(Index) = stemp
txt_Field(Index).DataChanged = False
End Sub

Private Sub txt_Field_GotFocus(Index As Integer)
txt_Field(Index).SelStart = 0
txt_Field(Index).SelLength = Len(txt_Field(Index).Text)
End Sub

Private Sub txt_Field_LostFocus(Index As Integer)
If txt_Field(Index).DataChanged Then Exit Sub
fns_verify_Attr CurX, txt_Field(Index).datafield
txt_Field(Index).DataChanged = True
End Sub

Control arrays are very 'light-weight' and should have very good performance.

I tried using user control instead of regular textbox, but this was very slow.
Now I use multicasting, i.e. classes that include code for misc. data entry controls:
cwSimpleText, cwLongText, cwDate, cwNumeric, cwCurrency, cwCheckBox, cwMemo, cwBinary, cwButtonLookup,...
so I don't have any code in the form controls' events. But there is code to initialize and manipulate that objects.

Thanks for the info, it's nice to hear what you are using. I would like to help with optimizing attribute collection if you want, or if you can pass some info on this - getattribute reads *field attributes* from database and setattribute saves this info to some ini file, or to some table?

I did it as we disscussed in the other Q..

a class with an internal array of UDTs which are referanced from a public type in a dll, its working fine and only took a day or so of tweaking to replace the full class/collection method

The item and add features are simple..you can still pass a key, but the key must be searched for in the type array if its not a number.

But it turns out my limiting facture in RAM memory was not the attributes and objects,(because mostly they are created on demand and attributes are only loaded as needed) but the GUI interface from Vb6 itself..I got a max 17 screens and I was out of memory or 15 with Word and Excel and VB6 runnung.

which is fine, no one could need that many open I thought..but then one of the people in the office came up to me and asked how to get rid of the screens as she couldnt look around the corner of the screen:)

I'm glad you optimized it.

Thanks for all the info.

I'm working on removing excessive code from my forms, e.g.:
    wOperator.Clear
    wSupplier.Clear
    wConstructionStart.Clear
    wGridConnection.Clear
into:
    Dim wCtl As ICtlWrapper
    For Each wCtl in colWrappers
        wCtl.Clear
    Next
I'll have to add one collection (colWrappers), one interface (ICtlWrapper), and all my classes will have to implement that interface.
Then it will be easier for maintenance, like your:
> for each contx in txt_field
>    contx.clear
> next

Happy coding!