.NET Questions (CLOSED)

Questions and Answers on any aspect of .NET. Now closed.

This discussion group is now closed.

Have a question about .NET development? Try stackoverflow.com, a worldwide community of great developers asking and answering questions 24 hours a day.

The archives of .NET Questions contain years of Q&A. Even older .NET Questions are still online, too.

Two classes to talk to each other

This might be better in Design of Software, but I'm using .NET (C#), so here goes (and posting here will help David look a little less conspicuous).

I have a main form where you select a whole lot of options.  Upon clicking the Start button, an object of type DataAggregator is created.  The DataAggregator class fetches things from a web server, and this action is started by calling it's Run() mthod.  This method enters a loop of web retrievals, but I know how many there are going to be so I can measure progress and send a message each iteration regarding progress.  So what I want is another form to appear as the DataAggregator runs that shows the progress - this is easy enough.  However, the progress form also needs to show a Stop button that fires an event to stop the Run() loop.

So far I have tried several variations of the Observer pattern but nothing seems to fit.  I'll need to use threads I presume - one for the DataAggregator and one for the progress form, so that the form appears responsive, and so when Stop is pressed, I can abort the DA thread.  It's getting the data from each class to the other that I can't get my head around.

Any ideas?

Cheers.
Kyle M
Wednesday, June 29, 2005
 
 
Could you not maybe create an event handler and fire an event when the "Stop" button is clicked and then in the event handling code you could kill the "Run" loop?
s
Thursday, June 30, 2005
 
 
Frank "Grimey" Grimes
Thursday, June 30, 2005
 
 
The Observer pattern is implemented using events/delegates in .NET - IIRC there's an article about it in msdn, search for Observer pattern. Rolling your own seems like unnecessary pain.

Sounds like you need an Application.DoEvents() in your main loop as well.
el
Thursday, June 30, 2005
 
 
It's hard to tell exactly what your issue is without seeing your code. But...

If you can't get the observer pattern to work, try thinking of this as a simple model-view-controller.

Model = DataAggregator
View = Progress Dialog
Controller = Main Form

The model provides one simple variable that tells how far along the process is (just fire an event when this changes).

The view just reflects this information by monitoring the event.

The controller wires the two together and listens for the Stop event.
Jeff Mastry Send private email
Thursday, June 30, 2005
 
 
Thanks for the help guys.  The ideas make sense - it's obviously my understanding of delegates and events that is lacking.  I've been hacking with it for the last day on and off, but need to read some more so that I can put solid ideas into play.  I'll let you know.

From a .NET novice, thanks again.
Kyle M
Thursday, June 30, 2005
 
 
Hey Kyle,

Rather than looking at threads I'd steer towards the use of Asynchronous Delegates.  Here is a quick and _very_ dirty example:

In a form, throw in a button and a textbox.  Define a delegate for the method you want to call asynchronously. Create a class that will hold a static flag that you can toggle.  Add another form where you can toggle that flag.  Write some code to start it asynchronously - here is a short example of the interesting pieces:

        public delegate void Loop();
        private void button1_Click(object sender, System.EventArgs e)
        {
            new Form2().Show();
            Loop p = new Loop(this.Counter);
            p.BeginInvoke(new AsyncCallback(this.Callback), null);
        }

        private void Counter(){
            while(!Switch.STOP)
            {
                if(textBox1.Text.Length > 0)
                {
                    int tmp = Convert.ToInt32(textBox1.Text);
                    textBox1.Text = Convert.ToString(++tmp);
                }
                else
                {
                    textBox1.Text = "0";
                }
            }
        }

        public void Callback(IAsyncResult ar){
            this.Text = "FIN";
        }

In another form, Form2 in my case,

        private void button1_Click(object sender, System.EventArgs e)
        {
            Switch.STOP = true;
        }

The switch class:
    public class Switch
    {
        public static bool STOP;
    }

I also just zipped the project I used and uploaded it:

http://hobbitwerk.brinkster.net/metadeveloper/AsyQuick.zip
David Seruyange Send private email
Thursday, June 30, 2005
 
 
Joe Miller Send private email
Thursday, June 30, 2005
 
 
David: while your approach, using asynchronous delegates is basically fine, you or other readers should be aware that this uses threads in much the same way as described by other posters. BeginInvoke simply gets a thread from the thread-pool and uses that. It is just a convenient way to spin off a thread.

Thus, the same care must be taken when modifying properties of GUI elements. As we all know, you should never ever modify controls from any other thread than the one they are created on. In your example, the Callback-method violates this rule, and should be modified to use Control.Invoke. I realize it's a quick and simple example, but the code should look like this:

private void Callback(IAsyncResult ar) {
  this.Invoke( SetFinishedText );
}

private void SetFinishedText() {
  this.Text = "FIN";
}
Girb Send private email
Friday, July 01, 2005
 
 
Poing well taken Girb. 

A footnote on Asynchronous Delegates - the reason I like them is that they are an abstraction of threading and a little bit more flexible / universal. For example, asynchronous web service calls are implemented with the same approach.  But, as you say, multithreading is the underpinning of this approach.
David Seruyange Send private email
Friday, July 01, 2005
 
 
The BackgroundWorker object in VS 2005 works a treat - handles the seperate thread, and cancel and update events.

That said, I've learnt a whole lot more about events and delegates now.

Thanks all.
Kyle M
Sunday, July 03, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz