Charlotte Foust
cfoust at infostatsystems.com
Fri Jul 27 11:54:45 CDT 2007
We use custom exception handlers, for example, and other "helper" classes. In the catch of a try-catch pair, we call the exception handler and pass it the exception and pops up a message ... But only for unhandled exceptions. We handle data exceptions in the data entity classes we create and pass the exception with custom message back to the calling object. We let the calling object then call a validationhelper class to handle the exception result it got, and that's were we pop up the messagebox and allow the user the OK or cancel options. We've tried to keep the model as untangled as possible, and the results affect the UI, so we make one-step jumps rather than daisy chaining events. I'm not sure whether that equates to what you're describing or not. We may, in fact, raise an event from a usercontrol, sink it in the parent of that usercontrol and raise another event from the parent to broadcast the result, if that's what you're describing. As for interface, we have defined interface classes, for instance for iToolbars and iValidation, which when implemented insert their shells into the object implementing them. In that object, we build code appropriate to whatever the event should do in that particular object. iValidation includes an IsValid function that accepts a feedbackstyle argument. The code in the object that implements it calls into the data entity class to validate a record before trying to update it. The validate event of the dataentity accepts a datarow uses the business rules tests in the entity and returns a boolean value for whether all the tests pass on the row. The calling object gets the boolean value back and if the record is valid, it save it. If it is not valid, it calls the ValidationHelper class to handle the exception message. That keeps up from changing something in the "middle" that breaks a bunch of other things. I don't know if that helps or not, because you're coming from a slightly different direction. Charlotte -----Original Message----- From: dba-vb-bounces at databaseadvisors.com [mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Friday, July 27, 2007 9:32 AM To: dba-vb at databaseadvisors.com Subject: Re: [dba-VB] VB.Net - Proxy Class Charlotte, Thanks for that. In fact I am examining using back ground threads to handle the process class work, however not knowing as much as I need to about VB.Net and .Net in general I want to get the entire process running (so I can do work) and then go investigate and use threads and background workers. In the meantime, what I am think of is a "middle man" class. The form knows about the middle man and can sink its events. The middle man can sink events from any class that implements a certain interface (but I think that is the wrong terminology here). The middle man sinks events from any class that can raise those events, and just immediately raises its own event, identically named, passing the parameters on. I have something similar to in concept but not exactly the same in implementation already working in VBA. I call it a message class. A message class is instantiated. It has a method that is called to send a message. Anyone with a pointer to the message class instance can call a method of the class instance and send a message. The message class simply raises an event and passes on the message. Anyone with a pointer to the message class can sink its events and receive any message. The message class is a middleman. Each end has to know about and get a pointer to the a clsMessage instance but they do not have to know about each other specifically. clsProcess needs to send a message. It gets a pointer to a clsMessage instance, calls a method of that instance and sends the message. clsMonitor needs to monitor clsProcess. It gets a pointer to the clsMessage instance and sinks it's events. Whenever clsProcess sends a message, it is passed through clsMessage and received by clsMonitor. clsMonitor can receive messages from ANY clsProcess (or any other class that sends messages on that instance of clsMessage). clsProcess can send messages and not worry about whether anyone is listening. If some class wants to log clsProcess' messages they can, if some other class wants to display clsProcess' messages on a form, they can etc. Loosely coupled interface, implemented through a common class instance. In fact messages can be sent back and forth between two classes or 100 classes, all listening on the message channel. BTW, a demo of that is on my web site in the WithEvents demo section. So I am looking to implement a similar construct here. In .Net though I have more flexibility in implementation because there are more capabilities available. Real inheritance, casting of an object to a specific data type etc. I do not know whether I can do what I am struggling to conceptualize. I want a process class to raise events. This allows the loosely coupled interface on the sending end. I want a proxy class instance to sink those events and retransmit them I want a progress form to sink events from a specific proxy class instance and use them. This allows the loosely coupled interface in the receiving end. The proxy class in the middle is the issue. IF I could create a clsProxy instance, pass in clsProcess to that instance as an OBJECT, then cast that object to a class that can be used WithEvents in a dim statement I would be there. I do not know how to do this. I can use the message class concept, I have already implemented that in VBA. That has the disadvantage of having to set up the message class instance and passing it in to the process class and to the progress form, but it is a lot more straightforward, and I can do that right now. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: dba-vb-bounces at databaseadvisors.com [mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Friday, July 27, 2007 11:14 AM To: dba-vb at databaseadvisors.com Subject: Re: [dba-VB] VB.Net - Proxy Class John, We use a System.ComponentModel.backgroundworker for stuff like this--progress bars, etc. There is a System.ComponentModel delegate called DoWorkEventHandler that may be what you're looking for. Charlotte Foust -----Original Message----- From: dba-vb-bounces at databaseadvisors.com [mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Friday, July 27, 2007 7:49 AM To: dba-vb at databaseadvisors.com Subject: [dba-VB] VB.Net - Proxy Class I have a situation where I want to have a generic status form which updates progress information for some very similar processes. In all cases a process class needs to raise events and the events need to be sunk in the progress form. Each event then updates one specific control on the progress form. Events: Current file FileComplete FilesToProcess LinesComplete Status My problem is that AFAIK in order to sink events, an object has to be dimmed WithEvents and the type of object has to be specified. Thus the progress form would have to be told in its header that it was working with a specific class, and thus the progress form is no longer generic. I know that I can not use events and simply have the class open an instance of the progress form directly, and directly manipulate the controls but I would prefer to have a loosely coupled interface in the process class where it can just raise events and if there is anyone who cares, it can process those events. Can I use something like a proxy class where the proxy class knows about process class and retransmits its events. The progress form knows about the proxy class. Thus the progress form is loaded and passed in a proxy class. That proxy class has been defined and hard coded to dim a specific object which sources the events of interest? This seems like an inheritance thing for the proxy class. Design a ProgressProxy class which has code to source specific named events. Create a clsProcessProxy which inherits the ProgressProxy class. In this class hard code the object which is the original event source. Name this object a generic name so that the object itself can be changed, but the event sinks never change and simply then call up to the parent (inherited ProgressProxy) to retransmit the event. clsProcess > clsProcessProxy inherits ProgressProxy > frmProgress (dims a clsProcessProxy and is passed in an instance to set its local copy to) Does any of this make sense? John W. Colby Colby Consulting www.ColbyConsulting.com _______________________________________________ dba-VB mailing list dba-VB at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-vb http://www.databaseadvisors.com _______________________________________________ dba-VB mailing list dba-VB at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-vb http://www.databaseadvisors.com _______________________________________________ dba-VB mailing list dba-VB at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-vb http://www.databaseadvisors.com