One last thing. What will make this fail is if the server goes down. Singleton objects are kept in memory, so when the server goes down, you loose the object (the only way to loose the object if GC is set and working right and you don't kill it yourself). You see, unlike vb 6, you can create an object, tell GC not to dispose of it, and keep it in memory and processing without any object references to it. That is what makes it stand-alone.
-----Original Message----- From: franklin gray Sent: Friday, May 24, 2002 3:21 PM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] delegate\event\thread ? I have build an IM system with this type of approach. The only different between my IM system and your system is that the server object just passes messages in mine, but yours does some processing before passing on datarows. Plus, my singleton object is a true singleton object (one object for all users). Yours will have to be modified so that it is a singleton object for each user. It has to be a singleton object so you can create it, let it be stand-alone, and then get back to it later without a object reference, just a reference to the dll. -----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. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
