Blocking GUI despite Observer Pattern (or just because that?)

  • Thread starter Thread starter Chris
  • Start date Start date
C

Chris

Hello,
I encountered a severe Problem with a Compact Framework Program I wrote in
C#.

I have a Form with an ListBox Object on it. On Button-Click, a Method
Object.GetData() is called which takes a relatively long time to return. The
result is then given to the Listbox by:

ListBox.Datasource = Object.GetData();

Additionally I have a Threading.Timer Object that issues frequent events. I
have a TimerCallback-Delegate and an appropriate OnTimer Delegate Function
implementation which is called each time the timer expires. A State is
maintained in a special object which I want to be observed by the GUI.

The timer expiry is communicated to the GUI by applying the Observer
Pattern.
(The GUI first registers with the State Object, and each time the State
Object gets updated, it calls the Notification-Method of its' obsever (via
registration information, which is a simple object-reference). The observer
(the GUI) then updates a Label with the according State.

So far so good. Everything works fine. But as I press the update button of
the listbox around the time when the timer gets updated (the label), the
application seems to hang and never return from the long call to
Object.GetDate();

So what is the issue? May there be a race condition?
Do I need to have my Object.GetDate() called asynchronously????
How can I get a clean separation from the GUI?

I'd appreciate any help!
regards
Chris
In my opinion, there can be no problem with that because
 
Thank you very much, Daniel,
I will check this out! But as far as I know, there is NO Forms.Timer in CF!
(So I used the Threading.Timer to do that)

Do you mean I should apply Control.Invoke to EVERY kind of update of the
GUI? Or just to the OnTimer-Method?

My problem is I have two different mechanisms of control flow:

1)A pull-mechanism by clicking a button which causes a (lengthy) function
call.

2)A push-mechanism originating from the expiting timer.

So how does your solution take this into account?

regards
Chris
 
Thank you very much, Daniel,
I will check this out! But as far as I know, there is NO Forms.Timer in CF!
(So I used the Threading.Timer to do that)

Do you mean I should apply Control.Invoke to EVERY kind of update of the
GUI? Or just to the OnTimer-Method?

My problem is I have two different mechanisms of control flow:

1)A pull-mechanism by clicking a button which causes a (lengthy) function
call.

2)A push-mechanism originating from the expiting timer.

So how does your solution take this into account?

regards
Chris
 
There is a System.Windows.Forms.Timer in CF.

Your OnTimer method or any other method running on non-UI thread must use
Control.Invoke. Methods running on the UI thread (e.g. button_click) do not
need to use ControlInvoke. Details are on the link I posted (and links from
it).

As for your lengthy call, I would put that on a thread rather than block the
UI. That could be a thread created by you, a threading.timer thread or one
from the ThreadPool. An alternative is the BackgroundWorker:
http://www.danielmoth.com/Blog/2004/12/backgroundworker-for-cf-10.html

Cheers
Daniel
--
http://www.danielmoth.com/Blog/


Chris said:
Thank you very much, Daniel,
I will check this out! But as far as I know, there is NO Forms.Timer in
CF! (So I used the Threading.Timer to do that)

Do you mean I should apply Control.Invoke to EVERY kind of update of the
GUI? Or just to the OnTimer-Method?

My problem is I have two different mechanisms of control flow:

1)A pull-mechanism by clicking a button which causes a (lengthy) function
call.

2)A push-mechanism originating from the expiting timer.

So how does your solution take this into account?

regards
Chris
Click to expand...
 
Back
Top