Either I am not understanding you, or you are not understanding me. If you build the object to be a singleton (in this case, a single object per user - check archives on how to do this) that does the processing on a server and start the processing with a Web Service and check status with a web service, then the only requirement are:
The server has to be Win2k or XP with all clients able to connect to it (whether it's lan or internet). The clients has to be DotNet because you will be passing back a datarow and getting a datatable object (maybe be ways around this requirement also). The object is stand-alone. Your client environment doesn't matter as long as they have the framework or maybe just a soap toolkit, depending on how much work you want to put into this. -----Original Message----- From: dave wanta [mailto:[EMAIL PROTECTED]] Sent: Friday, May 24, 2002 3:06 PM To: [EMAIL PROTECTED] 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.
