It sounds like what you want is an event. Here is how I would do it, but
read my disclaimer after the description.
First, decide what information you want passed back in the event. If you
don't need to pass anything back, just declare an event in your BO.
In BO:
public event EventHandler RowProcessed;
protected OnRowProcessed() {
if (IndexStarted != null) {
IndexStarted(this, null);
}
}
Then, in the client, use
myBO.RowProcessed += new EventHandler(RowProcessedHandler);
private void RowProcessedHandler(object sender, EventArgs e) {
// do stuff
}
If you do want to pass stuff back, like the row just processed, or info
about the progress (x of 123 done), just create a new class for the
argument, derived from EventArg, and new delegate to handle the event. If
you need an example, let me know, but MSDN has some very good examples.
Now for the disclaimer. The event will be raised on the same thread that is
running in your BO. This means that if the people who use your BO decide use
your thread for something else, you're blocked until they are finished. So,
if in the event handler they start a method call to another object (perhaps
even in your BO), then you are stuck in OnRowProcessed until the other
method call is done. If all they do is update the display, it's not a
problem. If you want to make sure that your processing continues no matter
what, you need to create a new thread and do your work on that. But, be
aware that you should not raise any events on that new thread! The events
should be raised on the thread that created the BO object (usually the
Winform thread).
This is a common problem that I and others have faced. Namely, how to raise
an event across threads. If you need to do this, let us know, and perhaps
someone could come up with a good suggestion.
Erick
----- Original Message -----
From: "dave wanta" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, May 24, 2002 1:05 PM
Subject: Re: [DOTNET] delegate\event\thread ?
> unfortunately, i can't do a webservice... this has to be a stand-alone
> object. I have no idea what environment this will be used in, once I
> release the object for production. This is a utility object that will be
> used to perform some algorithms on a datatable. All that's required, is
> that the client has pass in a datatable to the object, set a couple of
other
> properties, and the object will process each row...
>
> But I want to somehow notify the client every time a single row is
> processed, so a client has to opportunity to work with that individual
row.
>
> thanks,
> dave
>
>
> ----- Original Message -----
> From: "franklin gray" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, May 24, 2002 2:46 PM
> Subject: Re: [DOTNET] delegate\event\thread ?
>
>
> ah....then your stuck with using a web service and no events. What you
> could do is this...
>
> Create a singleton object that doesn't get GCed. Create a web service
that
> excepts a datatable and pass that to the object in another thread for
> processing. As the processing finishes a row, add it to a collection of
> DoneRows. Create another Web service to ping that DoneRows for new rows
and
> remove the ones it grabs.
>
> So, you have a WS that starts the process and another one that checks for
> updates.
>
> -----Original Message-----
> From: dave wanta [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 24, 2002 2:42 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [DOTNET] delegate\event\thread ?
>
>
> Thanks, but can't do this in remoting..
>
> this is an utility object that will be used across different departments,
> for different purposes across the organization ( which will also be
> geographically dispersed).
>
> --dave
> ----- Original Message -----
> From: "franklin gray" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, May 24, 2002 2:30 PM
> Subject: Re: [DOTNET] delegate\event\thread ?
>
>
> oh yeah....and you will want to do this in another thread.
>
> -----Original Message-----
> From: franklin gray
> Sent: Friday, May 24, 2002 2:25 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [DOTNET] delegate\event\thread ?
>
>
> Maybe what you want is a remoting BO. A regular object that runs on the
> server by remoting. This can fire events but can't work through
firewalls,
> and of course, the clients will have to be DotNet clients. Other then
that,
> I don't think anything else will work. Web services can't fire events so
> they are out.
>
> -----Original Message-----
> From: dave wanta [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 24, 2002 2:12 PM
> To: [EMAIL PROTECTED]
> Subject: [DOTNET] delegate\event\thread ?
>
>
> Ok... ever in one of those situations where you don't even know enough to
> ask the right question? Well, that's what i feel like with this one. If I
> should move this to a more appropriate list... let me know which list.
>
> ok here goes..
>
> I have an application that is basically 2 parts. A winform app and a
ADO.NET
> business object (BO), that the winform app uses and has a reference set to
> the BO dll.
>
> Many different winforms will be written to use this same Business Object.
> The winform applications can be written by anyone in the client's IT
> department, and I'll be responsible for writing the BO dll. The BO will
be
> doing some processing on employee records. The BO accepts a datatable, and
> loops through each row of the datatable, and performs some processing on
> each row. It's possible for the datatable to contain 10, 50, or even
> 500,000 rows (which could relate to hrs of processing). Consequently, as
> soon as you pass the DataTable to the BO, all winform processing is locked
> up, until the BO is done with the data. Now I realize the winform could
> execute this on another thread, so that the user could continue using the
> winform, but what I really want to do is raise an event back to the
winform
> (or calling application), from inside the BO, every time a row is
processed
> (for example, for reporting and tracking purposes). This way the winform
can
> then take that individual datarow, and do some more processing with the
> primary key, and employee ID of that row.... A few questions:
>
> What do I need to look at to do this? Delegates? Events? Where do I start?
> Urls? Links anyone?
> Does anyone have any code snippets of something similar in concept?
> I'm assuming I'll be raising an event back to the winform that accepts a
> DataRow, correct? I don't know.. looking for examples...
> Does this make any sense?
> Also, it's possible the ADO.NET BO will be used from Console apps, and
just
> about anything else.
>
> You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
> subscribe to other DevelopMentor lists at http://discuss.develop.com.
>
> You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
> subscribe to other DevelopMentor lists at http://discuss.develop.com.
>
> You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
> subscribe to other DevelopMentor lists at http://discuss.develop.com.
>
> You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
> subscribe to other DevelopMentor lists at http://discuss.develop.com.
>
> You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
> subscribe to other DevelopMentor lists at http://discuss.develop.com.
>
> You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
> subscribe to other DevelopMentor lists at http://discuss.develop.com.
You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
