Events, Threads and ISynchronizeInvoke

  • Thread starter Thread starter GM
  • Start date Start date
G

GM

Hi,

My application has a need to cache a number of shared reference lists
containing basic business objects. In order to improve performance these
lists are fetched and updated in the background.

When a UI is required to display one of these reference lists it requests it
by name from the cache. If the list already exists in the cache it is
returned to the caller otherwise a brand new empty one is created and
returned. This new empty list then initiates a background thread to fetch
the items from the database. On return the contents of the list are merged
with the empty list in the cache and the appropriate ListChanged events
raised to notify observing controls that the list has changed.

I use Joval Lowy's BackgroundWorker
(http://www.idesign.net/idesign/desktopdefault.aspx?tabindex=5&tabid=8) to
perform the background fetch.

My problem is that the merge/update to the cached list takes place on the
background thread. This results in a ListChanged event being raised on that
thread and the control that the list is bound to being updated on a thread
other than the one that created it. I would like to be able to return to the
main thread when the background thread has finished its work of fetching the
list. This would allow the main thread to perform the update of the cached
list and the raising of the ListChanged event. I have read about the
ISynchronizeInvoke interface and thought that that would be the way to go
but I cannot see how to marshall back to the main thread other than to use
PostMessage.

Am I missing something obvious?

Thanks in advance,

Graham
 
GM said:
My application has a need to cache a number of shared reference lists
containing basic business objects. In order to improve performance these
lists are fetched and updated in the background.

When a UI is required to display one of these reference lists it requests it
by name from the cache. If the list already exists in the cache it is
returned to the caller otherwise a brand new empty one is created and
returned. This new empty list then initiates a background thread to fetch
the items from the database. On return the contents of the list are merged
with the empty list in the cache and the appropriate ListChanged events
raised to notify observing controls that the list has changed.

I use Joval Lowy's BackgroundWorker
(http://www.idesign.net/idesign/desktopdefault.aspx?tabindex=5&tabid=8) to
perform the background fetch.

My problem is that the merge/update to the cached list takes place on the
background thread. This results in a ListChanged event being raised on that
thread and the control that the list is bound to being updated on a thread
other than the one that created it. I would like to be able to return to the
main thread when the background thread has finished its work of fetching the
list. This would allow the main thread to perform the update of the cached
list and the raising of the ListChanged event. I have read about the
ISynchronizeInvoke interface and thought that that would be the way to go
but I cannot see how to marshall back to the main thread other than to use
PostMessage.

Am I missing something obvious?
Click to expand...

I don't know how obvious it is, but Control.Invoke is what you're
after.

See http://www.pobox.com/~skeet/csharp/threads/winforms.shtml
 
Thanks for replying Jon,

I had written a reply that basically said that I couldn't call
Control.Invoke because the class where I want to return to the main thread
is not a control, its a container for my shared reference lists. But then I
got to thinking why couldn't it be a control? So I made my
ReferenceListCache class inherit from control and when the BackgroundWorker
completed, also in the ReferenceListCache, I attempted to invoke the
MergeList method, also in ReferenceListCache, through the MergeDelegate.
But the MergeList method is never called. So what am I doing wrong? I've
pasted some code below.



public delegate void MergeDelegate(ArrayList list);



public class ReferenceListCache

{

public void MergeList(ArrayList list)

{

mListRegistry.UpdateCachedList(list, true);

}



private void worker_RunWorkerCompleted(object sender,
RunWorkerCompletedEventArgs e)

{

ArrayList list = e.Result as ArrayList;


MergeDelegate merge = new MergeDelegate(MergeList);

object[] args = new object[]{list};

this.Invoke(merge, args);

}

}



Thanks,

Graham
 
GM said:
I had written a reply that basically said that I couldn't call
Control.Invoke because the class where I want to return to the main thread
is not a control, its a container for my shared reference lists.
Click to expand...

It doesn't need to *be* a control - it merely has to have a *reference*
to a control. If you're wanting to do something with the UI, you must
have a reference to a control of some description somewhere.

Note that you don't have to know that it's a control - Control
implements ISynchronizeInvoke, so you can pass a reference to a control
to something more general which accepts an ISynchronizeInvoke to use to
synchronize when it's finished.
 
Thanks Jon.

I had also tried that approach, by giving my ReferenceListCache class a
Label control as a private member. I then try to Invoke the delegate on
this Label control. But the delegate method is still not being called. In
order to test the delegate method I did a DynamicInvoke on the delegate
instead of a Control.Invoke and the method was called. So I think the
problem must be a misunderstanding on my part on the use of Control.Invoke.

Any thoughts?

Thanks,

Graham
 
GM said:
I had also tried that approach, by giving my ReferenceListCache class a
Label control as a private member. I then try to Invoke the delegate on
this Label control. But the delegate method is still not being called. In
order to test the delegate method I did a DynamicInvoke on the delegate
instead of a Control.Invoke and the method was called. So I think the
problem must be a misunderstanding on my part on the use of Control.Invoke.
Click to expand...

I don't think you can just create a control without displaying it or
adding it to something else which has a window associated with it. Use
one of your *real* controls from the UI as the synchronization object.
 
First of all thanks for all your help Jon.

I'm now passing a Control to my ReferenceListCache and using this Control to
Invoke the appropriate method. This is working great 99% of the time.
However, it is the 1% of the time thats driving me insane. On those
occassions the delegate method is not being called. Instead, as far as I
can make out, a callback method in the BackgroundWorker component is being
called instead (ReportCompletion). I cannot work it out and its behaviour
is not consistent.

If you can shed any light on why this is happening that would be great. If
not, thanks again for your help.

Cheers,

Graham
 
GM said:
First of all thanks for all your help Jon.

I'm now passing a Control to my ReferenceListCache and using this Control to
Invoke the appropriate method. This is working great 99% of the time.
However, it is the 1% of the time thats driving me insane. On those
occassions the delegate method is not being called. Instead, as far as I
can make out, a callback method in the BackgroundWorker component is being
called instead (ReportCompletion). I cannot work it out and its behaviour
is not consistent.

If you can shed any light on why this is happening that would be great. If
not, thanks again for your help.
Click to expand...

That sounds very odd... Could you post a short but complete program
which demonstrates the problem? (Even occasionally?)

See http://www.pobox.com/~skeet/csharp/complete.html for details of
what I mean by that.
 
Jon,

I tried to create a simple program and recreate the problem but I could not.
But I have managed to get it working although I'm not entirely sure how.
The prolem appears to be the fact that the creation of the custom control
(which fetches the 3 lists in its constructor) is done in the
InitializeComponent method of the form. When the creation of this custom
control is delayed (until another container control is expanded) the
delegate method is Invoked correctly each time and the lists are returned.
So I would hazard a guess that because the Window has not been created
completely, it is not receiving Windows messages correctly. But as I say,
thats only a guess.

Thanks for all your help,

Graham
 
GM said:
I tried to create a simple program and recreate the problem but I could not.
But I have managed to get it working although I'm not entirely sure how.
The prolem appears to be the fact that the creation of the custom control
(which fetches the 3 lists in its constructor) is done in the
InitializeComponent method of the form. When the creation of this custom
control is delayed (until another container control is expanded) the
delegate method is Invoked correctly each time and the lists are returned.
So I would hazard a guess that because the Window has not been created
completely, it is not receiving Windows messages correctly. But as I say,
thats only a guess.
Click to expand...

That would sound fairly reasonable to me, yes...
 
Back
Top