backgroundworker with typed dataset binding

backgroundworker with typed dataset binding

Post by mmcd7 » Tue, 19 Jun 2007 15:20:04


I currently have a single threaded application that contains a
strongly typed dataset (called dsdataset1) with 3 tables, all bound to
comboboxes on my main form.

This works in its current form (the datasets are filled on the form
load event).

I noticed a problem whereas the form doesn't draw until the datasets
are filled, so I figured I'd use the background worker component to do
the dataset filling on a seperate thread.

For some reason, I cannot get this to work properly. My program
loads, and my dataset is filled, however my comboboxes are no longer
bound to the dataset. It's driving me nuts.

I've tried passing the dataset back out during the runworkercompleted
event (i.e. dsdataset1 = ctype(e.result, dataset)), but even that
doesn't work. I even tried resetting the bindingsource.datasource for
my combobox back to the dataset after passing the dataset out, but no
go. I'm at a loss.

Any suggestions?
 
 
 

backgroundworker with typed dataset binding

Post by Bryan Phil » Fri, 22 Jun 2007 12:51:51

Try setting the DataSource property to null/nothing before setting it to
the dataset after filling it.

Another approach might be to populate a separate dataset on the
background thread and then to populate the dataset you are binding to in
your runworkcompleted event handler.

Bryan Phillips
MCT, MCSD, MCDBA, MCSE
Blog: http://www.yqcomputer.com/
Web Site: http://www.yqcomputer.com/

 
 
 

backgroundworker with typed dataset binding

Post by mmcd7 » Sat, 23 Jun 2007 08:37:41

I tried suggestion one, and still same issue. What's odd is if I step
through the code, the watch window shows my bindingsource is fine, and
even shows there are 3 records in the table within the datasource.
Why can't the combobox display it? It's like the combobox loses the
binding information, although the watch window shows it's still there.

More odd.. I tried to reset the datasource on the combobox to point to
it's binding source (combo1.datasource = combo1BindingSource). When I
do this, I get "System.Data.DataViewManagerListItemTypeDescriptor" as
the text in the combobox. Then even further, when I select this from
the list, my other combobox (tied to this one) populates with it's
correct data.

(if the process is confusing.. it works like this. 3 comboboxes that
relate to each other: category1, 2, and 3. Based on the selected item
in combo1, combo2 filters it's bindingsource based on the valuemember
of combo1. Same thing between combo2 and 3.)

It seems the binding is there, just combobox1 isn't displaying its
members correctly. I'm so stumped!!!!

Oh, with regards to your second question, I'm not exactly sure I
follow what you suggest nor why it would help. Again when debugging,
my datasource is correctly populated. I can drill down in the watch
window and look at the data it contains. The problem is solely with
the combobox being able to bind to it.

On Jun 20, 11:51 pm, "Bryan Phillips"
 
 
 

backgroundworker with typed dataset binding

Post by mmcd7 » Tue, 26 Jun 2007 14:15:17

K. I decided to screw the population of the designer created
comboboxes/bindingsources. They are still there, but I created new
comboboxes (unbound) in the designer.

Then I proceeded with my previous background worker thread. I even
used the same dataset that was created with the designer. In the
DoWork procedure, I programmatically created 3 new tableadapters using
my connection string and populated the original dataset.

In the runworkercomplete procedure, I programmatically created binding
sources for each combobox, set their datasource to the pre-existing
dataset, and set their members to the necessary tables. I then bound
the comboboxes to these binding sources. THIS WORKS!!!

For the life of me I can't figure out why my designer created
components will not work. It must be a bug with the preexisting
bindings or something.

At any rate, I'm just going to stick with writing code for all of
these kinds of things. I've just had too many weird issues with
wizard/designer based doohickeys in VS.

Did I mention I also hate the fact that comboboxes have a bug whereas
you have to set the selected index to -1 TWO TIMES in order for it to
work all the time? MS has KB about it. How about fixing it MS? lol
sheesh.

On Jun 21, 7:37 pm, XXXX@XXXXX.COM wrote:


 
 
 

backgroundworker with typed dataset binding

Post by mmcd7 » Wed, 27 Jun 2007 10:50:44

think I'm a little obsessed :). I thought I could leave it alone,
but I can't. I did some more testing, and these are my results.. it
looks like most of the IDE/designer generated components (dataset,
tableadapter, bindingsources) are fine throughout the background
threading process. It's the comboboxes themselves that are having the
problems.

For some reason, even though at runtime the comboboxes have their 3
main databound attributes (datasource, displaymember, valuemember) set
to the correct datasource (combobox1bindingsource, column2, column1,
for example).. this is getting lost during the background thread even
though debugging shows they never lose this association. (I'm stumped
as to why this is).

In the RunWorkerCompleted method, if I re-tie the comboboxes 3 above
mentioned attributes back to the binding source, everything works as
intended.

Oh well, at least I now understand where the true problem is. I just
wish I knew why this problem exists when using the backgroundworker.



On Jun 25, 1:15 am, XXXX@XXXXX.COM wrote:


 
 
 

backgroundworker with typed dataset binding

Post by mmcd7 » Wed, 27 Jun 2007 12:35:34

ust yet another update. Apparently the previous solution that "was"
working, is still victim to the oddities of VS2005. I was just
cleaning up my code (moving some lines of code into a seperate SUB and
then just calling the SUB), and all of a sudden it stopped
working!!!!! GRRRR

I had to remove the bindings from the comboboxes in the IDE/Designer
and rely on setting the bindings later in code in order for this to
work. I swear!



On Jun 25, 9:50 pm, XXXX@XXXXX.COM wrote: