Store Controls in Array...

[QuaffAPint]

I need to know when various controls (text boxes/check boxes/etc) have been edited, so when they save the information later only the changed information gets updated.

So, I was planning on storing the "object" in an array keyed off by the change event. Then when they go to save the information I can just use "object".text or "object".value, as it runs through the array.

How can I store an "object" in an array and read it out later?

Thanks for any assistance...
QuaffAPint

[jim mcnamara]

Collections are designed just for this purpose.

There is a default collection of all the controls on a form. TO get the text from all textboxes into a listbox

Dim ctl as Control
For each ctl in Form1.Controls
     if Typeof ctl is Textbox then
            List1.AddItem ctl.Text  ' put the text in a listbox
     end if
Next

[IROY55]

If you have you Texboxes in the control array then you may do something like the following:

Option Explicit
 
Dim Modified() As String
 
Private Sub Command1_Click()
Dim i%
 
    For i = LBound(Modified) To UBound(Modified)
        If Modified(i) = "yes" Then
            'do something
        End If
    Next i
 
End Sub
 
Private Sub Form_Load()
    ReDim Preserve Modified(Text1.UBound)
End Sub
 
Private Sub Text1_Change(Index As Integer)
    Modified(Index) = "yes"
End Sub

[techgnome]

Don't think either solution is what was begin saught..... Jim, he only wants the CHANGED controls to be saved, not all.... IROY, I don't think a control array is being used......

I think this is basically the way it's supposed to work.

1) User changes something in a text box.
2) an array of objects is expanded by one, the text box gets assigned to the new array element...
3) User changes option button
4) an array of objects is expanded by one, the option button gets assigned to the new array element...
5) App saves the .text or .value of each object in the array to a file.

.....
The way I'd do it is somewhere in between..... You didn't specify if you want to save the name of the source (like txtFirstName) or not.....
Assuming you don't create a Collection... then add either the .Text or .Value to the collection.
When ready, run through the collection and write the values out to the file.

Now, if you DO want the source names... create a UDF with two elements, Name and Value.... then in each change event, set the Name to the .neame of the control, and the Value to the .text or .value.
Add it to the collection.
When ready, run through the collection and write the names values out to the file.

[QuaffAPint]

Thanks for the thoughts thus far - but, here's a new twist (and techgnome, this may be where you're going and I don't see it)...

Instead of wanting to actually store my non-collection objects in an array, I determined what I really need is to store a property in an array...

Here's what I mean..

This app is a User Mangement app for a Win2K AD structure.

I only want to update the particular user attributes that the client has changed, so for example.

txtPassword.Text = "NewPassword"
chkMustResetPassword.Value = 1

Then to set those I use an LDAP query to the IADsUser object, such as for example...

User.Password = NewPassword
User.MustReset = CStr(CBool(1))

What I would like to do is store in the array the User properties that have changed and their values. So again I figure I could key off the object's change event.

The question now is, can I store the changed "properties" in an array to be looped through when saving the changes, w/o having to resort to a large CaseSelect statement or something of that sort?

Thanks again for the help...
QuaffAPint

[IROY55]

I don't think a control array is being used......

Tooo bad for him.

[IROY55]

QuaffAPint,
you don't have to overcomplicate your program's logic as it may become difficult to maintain. Down the road your program may grow according to some new ideas and/or your end user requests. What initially seemed to be quite logical may become irrational and abusive. So try to keep it as simple as possible and always think maintenance first. Control arrays is a very good feature that VB offers so use it. if you looading your form with mutiple fields that require user input then all you need is 1 Textbox wich you can mutiply at runtime. That sample code I've posted has very simple logic and I believe that is all you need. I am not promoting myself by anyhow - just trying to let you understand how important simplicity is. There is no need to create objects all over the place and have a headach where and how to manage them if you can use something already given instead.

Cheers

[QuaffAPint]

Maybe I'm missing something here - but I don't see how a collection of text boxes and check boxes is going to help me...

For example,

Text1(0) = "johnny"
Text1(1) = "john"

...when it comes to saving the changes how do I know which one is a password and which one is a username? Yes, I could try to say, 0 will be the password and 1 will be the userid, but what if I have over a dozen or so textboxes scattered throughout, with new ones being created regularly - I would think that would be higher maintenance.

Thanks...
QuaffAPint

[IROY55]

Textbox and most of the others controls have a property Tag. You may write into it anything wish: field name for instance is the simplest in your case. So using this property and technic that I showed you can do anything you want, but it's your call as I have no intention to force you to follow anything.

[QuaffAPint]

Now I see where you're going with this IRoy - I've never noticed the 'tag' property before.

So, if I store the fact that a change was made into an array based on the change event, I could cycle through that array. Now I'll just have to test that and convert my app to use Collections by Tuesday...

But, this still leaves one question, how can I easily assign the 'tag' to the property of a User object, such as,

oUser.Text1(0).Tag

...obviously that wouldn't work. Is there a way to "convert" the Tag string into a Property?

Thanks again for the use of your brains...
QuaffAPint

[IROY55]

Attached is a working sample of how to dynamically update records based on "what was changed".

[IROY55]

It' quite rusty, so you will need to "polish" it.

[QuaffAPint]

So, it looks like in your example you had to use a Case statement to tell your program what to do with each control.

I would like to avoid that if possible and directly convert the stored string into the property of the User object - if at all possible

I just have so many controls in various PictureBoxes that it would make for an ugly Case statement.

Thanks...
QuaffAPint

[IROY55]

... you had to use a Case statement to tell your program what to do with each control. ... I would like to avoid that if possible ...

QuaffAPint,
don't get me wrong but now I see what the problem is: you must be a very beginner to say that. Select Case structure is the fastest way in VB to access a specific member of control array. Man, you have a loooooooooong way of learning yet.

I just have so many controls in various PictureBoxes that it would make for an ugly Case statement

This explains you techical level (no offence please).

[QuaffAPint]

I don't take offense - I don't agree, but still don't take offense.

I understand Case statements are efficient for what they do, as in comparison to a series of If...ElseIf statements.

In your example you had only three items in your control array, at last count I have 18, with more on the way - and that's just the text boxes. While, yes, I could still use a Case statement for up to 1000+ items - I believe there is still a more efficient way. I'm trying to think of future maintenance of the app, as I know more and more text boxes/check boxes are on the way.

I might just be hitting the wall with VB6, and have to succumb to doing it the Case statement way.

As for the Picture boxes, you would have to see the app to understand. I'm designing it in an MMC/Outlook manner, so instead of using multiple forms and placing them over a center form, I'm using a single form and multiple Picture boxes as the containers.

-QuaffAPint

[IROY55]

Whatever, you are the boss of your code, but don't get lost in it one day.