Any one experts can give tips (sample code) on how to add data with my array textbox? let say we have lname,fname,mname,age fields in the table and with 4 textbox in a form having same name.
If you are binding these fields to a recordset then, at design time, set the name of each textbox to the same, set the index property to one more than the previous text box (0,1,2,3 etc) and set the datafield property to lname for the first, fname for second etc.
You can set the datasource to the same value for each control (a database table, data control or recordset perhaps) at design time or at run time.
Yes, you can use a for loop to loop through the database items. Just loop through the data, and do a with statement for the textbox array (to add data to it).
For creating the array of textboxes, similar to what Glasgow said, you can either name the item the same and change the index, or you can do the easier way and copy/paste the text box directly onto the form. It will ask if you'd like to create the array, click yes. copy and paste as many as you need.
You can either add new textbox sets within the loop using a Load statement, or use a For..Next loop for a fixed number of records
rst.Open "SELECT * FROM tblClients", cn, adOpenStatic, adLockOptimistic
If Not rst.EOF
Do While not rst.EOF
Text1(a) = rst.Fields(1)
Text2(a) = rst.Fields(2)
Text3(a) = rst.Fields(3)
Text4(a) = rst.Fields(4)
rst.MoveNext
a = a + 1
Loop
rst.Close
Set rst = Nothing
________________________________________________________________
If you want to get the best response to a question, please check out FAQ222-2244 first
'People who live in windowed environments shouldn't cast pointers.'
You can also use the textbox array, and set the DataField property, but do NOT need to set the DataSource.
Then you are using the DataField property like a free extra Tag property.
Now you only need to loop through the array:
[blue]
Sub LoadTxtBoxes()
Dim txt As TextBox
For Each txt In myTextBoxArry
txt.Text = rs.Collect(txt.DataField)
'Or: txt.Text = rs.Fields(txt.DataField).Value[blue]
Next txt
End Sub
And, you can also do this:
[blue]
Sub LoadTxtBoxes()
Dim txt As TextBox
For Each txt In myTextBoxArry
txt.Text = rs.Collect(txt.Index)
Next txt
End Sub
Is there not an issue here as to whether the textboxes are just loaded for viewing purposes or whether thay are going to be used as a mechanism for updating the corresponding data in the database? If the latter would it not make sense to bind with DataSource property?
>If the latter would it not make sense to bind with DataSource property?
You still can, and just lock the edit control.
Or open the recordset as read only.
I was just showing how to take advantage of the DataField property, but for non-bound controls (not binding the controls to a recordset).
If you want the controls bound, then you can do this too, and the looping is then not needed.
1. DataMember is used to identify which recordset, or Datamember is used in a datasource CLASS consisting of one or more recordsets/datamembers.
When the edit box is bound to a field, and the datasource is a Data CLASS, the DataMember identifies which recordset to use, if there are more than one.
2.
>why would you need to disable editing or open read only when using the DataSource property?
IF the source shouldn't be updated BUT then control is Bound to a datasource.
You could use instead a read only recordset, but would need to capture the error returned by ADO when the user changes the value in the edit control and moves on to the next control. Also, you would need to explain to the users why they can change the values in the edit controls, when it is not to be updated.
You would do this if you still want the convenience of having the edit controls update with new data automatically when moving to a new record.
Again, as I've said before, I like DataBound controls when working with Client side cursors; dis-like them when working with server side cursors; and think the data control is something horrible to work with - all concerning ADO.
Under DAO, I dis-like bound controls all together and think they are only wet logs.
1. Understood - thanks. As yet I've never had cause to use it so I /babBbuse it instead!
2. Thanks for clarification - it obviously makes sense if indeed the source should not be updated. I'm so used to dealing with updateable scenarios that I didn't really consider the possibility that this might be something anyone might want to do!
Agreed on bound controls, client-side cursors and the anti-social data control (I have also found DataCombo control something to avoid) but have had only limited exposure to DAO.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.