>=20
> How can I make thread safe calls to the form controls? I can't really fin=
d
> this information anywhere. Well I can, but I had trouble getting it to wo=
rk.
> Specifically setting the data source, etc. A nice little example would be=
 much
> appreciated.
>=20

You can always make a form/control function thread safe by testing the=20
InvokeRequired property. This checks if the calling thread is the same as t=
he=20
thread that created the control (the GUI thread where the control lives). I=
n=20
addition you also need a delegate for the signature of your control functio=
n:

delegate void UpdateMyControlDelegate(DataForMyControl d);
// This is a function signature that is later used to
// create a delegate that can be used to invoke a function
// with this signature.

void UpdateMyControl(object sender,DataForMyControl d)
// This is the function that manipulates the control and is
// part of the Form or Control class for this control
{
  if (InvokeRequired){ // Caller on the control thread?
    Invoke(new UpdateMyControlDelegate(UpdateMyControl),new object[] {d});
    return;
  }
  // Do the actual control update here...
}

However, I consider this to be bad practice. Instead you could use some sor=
t of=20
client/server approach where the control is the client and the function/thr=
ead=20
that does the actual work for your control is the server. In this case the=
=20
server has a public event or callback function that the client subscribes t=
o=20
before telling the server to do the work. The server then does it's work=20
(possibly in a background worker therad) and informs the client, either onc=
e=20
when done or at regular intervalls by simply raising the event or calling t=
he=20
callback function. This is all done with delegates (an event is just a type=
 of=20
delegate) so they are type- and thread safe.

This also has the great advantage that the server knows nothing of its clie=
nts=20
and can be used for any type of client that adheres to its public interface=
s.

The Control.Invoke above is executed syncronously (the call doesn't return=
=20
until the GUI thread has done the update). If you want to do the update=20
asyncronously you can use Control.BeginInvoke instead. You can compare this=
=20
with SendMessage and PostMessage for unmanaged Windows programs.

In your case you can perhaps do the db querry on a background worker thread=
 and=20
not bind the data to the control until the work is finished. Since this tak=
es a=20
long time you could perhaps break up the querrying in smaller parts. If you=
 use=20
a BackgroundWorker to do the actual work, the partial updating of your cont=
rol=20
can be done using the ReportProgress method/ProgressChanged event. Or use t=
his=20
event to update a cancelable form with a progressbar that is showed during =
the=20
updating to give feedback to the user.

Hope this helps
/Ruben



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
Ruben J=F6nsson
AB Liros Electronic
Box 9124, 200 39 Malm=F6, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
ruben@pp.sbbs.se
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.