SiscoKid
asked on
DataCombo binding
I am using the VB6 DataCombo control. At runtime I want to bind it to a recorset. The recordset is the result of an ADO connection to SQL 7 stored proc. The recordset has the correct data in it. I used the code from the MSDN - "HOWTO: Bind a DataList or DataCombo to a Recordset at Run-Time" and all I get is an empty drop down. No errors. I do not want to use the datacontrol. Help!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I do not want to use the data contol or the data environment because I want a pure code solution. The MSDN help shows me how to do it but I can't get it to work. Is this a known bug? Is there a kb article on this? Thanks.
"pure code"?
What the hell does *that* mean?
Is the use of the control somehow "impure"? If it gets the job done, then why not use the tools?
Your original Q indicated that you were using the DataCombo, well the Data control is *part* of how to use a combo.
You can open the database, generate a record set and then populate a listbox or simple grid if you want. Basically you generate you record set and then iterate thru the records filling your grid/listbox as you go:
SET RS=db.OpenRecordset("selec
LIST1.CLEAR
DO WHILE NOT RS.EOF
LIST1.ADDITEM trim(RS!{field})
... you can also populate a grid with something similar to:
Grid.Rows = Grid.Rows + 1
Grid.Col = 1
Grid.Text = trim( RS!Field1 )
Grid.Col = Grid.Col + 1
Grid.Text = trim( RS!Field2 )
... etc, etc, etc ...
RS.MOVENEXT
LOOP
Once you've generated the record set it matters not what control you assign to handle the task. If you do it as shown above, you have to manage. If you use the data control then it manages.
M
What the hell does *that* mean?
Is the use of the control somehow "impure"? If it gets the job done, then why not use the tools?
Your original Q indicated that you were using the DataCombo, well the Data control is *part* of how to use a combo.
You can open the database, generate a record set and then populate a listbox or simple grid if you want. Basically you generate you record set and then iterate thru the records filling your grid/listbox as you go:
SET RS=db.OpenRecordset("selec
LIST1.CLEAR
DO WHILE NOT RS.EOF
LIST1.ADDITEM trim(RS!{field})
... you can also populate a grid with something similar to:
Grid.Rows = Grid.Rows + 1
Grid.Col = 1
Grid.Text = trim( RS!Field1 )
Grid.Col = Grid.Col + 1
Grid.Text = trim( RS!Field2 )
... etc, etc, etc ...
RS.MOVENEXT
LOOP
Once you've generated the record set it matters not what control you assign to handle the task. If you do it as shown above, you have to manage. If you use the data control then it manages.
M
ASKER
And that is exactly what I am doing, Thanks. The MSDN is sure misleading on this. I just don't like populating my form with a bunch of data controls even if invisible at run time. The pure code phrase is an attempt to convey the desire of NOT having to set properties but have the properties in code so I have more "control". Does that make any sense ? The data environment designer is another option that I have uses successfully in the past but again it seems that I loose control if a wayward property gets set during design/debug. Anyway, I think I'm good on this. You all deserve a better answer than "barely acceptable" so post your answer as an answer and I will gladly grade it.
As a general habit I try to *NOT* set properties at design time for "tough" controls. Like when I use the WinSock control I don't change *ANY* of the properties except at runtime explicitly. This helps me when I copy the code to another project with a fresh copy of the control.
The Data control is *required* even in a "pure code" situation. I've found that if you don't have one, the compiler won't recognize the stinking database commands! If you just start off coding (on a completely blank form) and write something like:
PUBLIC DB AS DATABASE
The !@#$%^ compiler will choke with a "Undefined User Type" error!
Placing an *invisible* Data control (with just the default properties) on the form eliminates the error. @#$%^ M$!
Anyway, I see your point, but there really is no clean work around.
Thanx for the offer on pts, but there is no way to re-answer the Q. Don't bother spending more points. I've got plenty! Instead, visit my web page and sign the guestbook. I've got a *lot* of good code online. Check it out!
www.cyberchute.com/rvbus/madmark
M
The Data control is *required* even in a "pure code" situation. I've found that if you don't have one, the compiler won't recognize the stinking database commands! If you just start off coding (on a completely blank form) and write something like:
PUBLIC DB AS DATABASE
The !@#$%^ compiler will choke with a "Undefined User Type" error!
Placing an *invisible* Data control (with just the default properties) on the form eliminates the error. @#$%^ M$!
Anyway, I see your point, but there really is no clean work around.
Thanx for the offer on pts, but there is no way to re-answer the Q. Don't bother spending more points. I've got plenty! Instead, visit my web page and sign the guestbook. I've got a *lot* of good code online. Check it out!
www.cyberchute.com/rvbus/madmark
M
If you know how to create ActiveX controls then you can add properties to it which will accept the datasource property at run time