Hi Erick,
Thanks immensely. This is what I'm looking for. I would be grateful for any
examples\links\experience you can pass my way. I want to make sure I handle
this correctly rather than incorrectly. I believe my best course will be to
execute on the same thread and have a disclaimer for the developers that use
the BO and to be careful about blocking the thread (give them enough rope,
even if they can hang themselves :-) ).
Thanks a bunch for your help.
Cheers!
dave
----- Original Message -----
From: "Erick Thompson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, May 24, 2002 3:22 PM
Subject: Re: [DOTNET] delegate\event\thread ?
> 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.
>
You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
