Jim Dettman
jimdettman at verizon.net
Wed Jun 22 10:26:40 CDT 2011
John, <<Jim, you are getting waaaaayyyy too bogged down in micromanaging things. >> I'm not sure what it is I'm micromanaging<g>; all I pointed out was that if you implemented a message class as you outlined in your first post, it would be inefficient. That was, and I think you would have to agree given your responses since then, a legitimate point. You and Drew came back and said there are ways around that. Great. But for some, it might not be obvious that there were or that it might even lead to a problem. But all I did was raise a valid point. <<Uh yea I guess you are right. I will definitely see if I can reduce the expected 1.2 milliseconds / month of message traffic so that my app doesn't experience bloat / slowness.>> Well like you, I can say "In this specific example it's meaningless because I can do it another way if I want", but the point is, if every programmer takes the attitude of "it's just a few extra cycles", then sooner or latter, you end up with a problem. How often do you hear people complain that they always need a faster PC with more memory when they buy new software? A lot. What about Vista, that Microsoft said up front *required* more hardware and software to run, and it still fell flat in the performance area. So much so that Windows 7 was pretty much nothing but a fine tuned Vista? So again, I believe this is a valid point. In any case call me old school if you want, perfectionist, or what ever, but I always write to be as efficient as possible. Some people may think that's a waste of time given that we always get faster and faster hardware, but I don't believe it is. <<Did you even bother to run the demo classes I included before you started raising objections? >> First, I only raised one and I'm not sure I'd call it an "objection". I didn't say don't use the class. In fact I even pointed out that for the majority of applications, it would not be a real problem. Second, no because: A. I don't use classes for the most part with Access. Without full inheritance, I don't think it's worth the effort. I can (for the most part) achieve the functionality of classes without the overhead of dealing with them. B. I didn't need to use the class to see the problem. C. It's not the way I'd implement the messaging functionality. << Do you have any idea how it works? If so then you already know how to modify it to be more like how you personally would like it to work. Perhaps use the .SendSimple method and a different class instance for each process in your application? That's what I would do if I got too much traffic on a channel.>> Certainly I do. While I don't use classes with Access, apps I've written with VFP are nothing but classes (everything in VFP is a class). So I see the need for the functionality it provides, but I don't implement it in that way. The way I have implemented that is through a specific class and middle tier business objects. It goes back to the comment I made about objects registering/unregistering for services. What I would have is a customer combo class, which in turn would be registered with a customer business object, because it's a consumer of customer data. That BO would provide a .List method to fill the combo. It would also take care of messaging the object(s) when a requery is required, because they registered themselves with the class when they were instantiated. The net result of that setup is that only objects that depend on customer data would get messaged to requery when it changed. It would not be a "If anyone is out there listening that uses customer data, you need to requery" Granted you could achieve the same affect with multiple message classes, but that is not what you said (or showed) in your first post. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Tuesday, June 21, 2011 02:44 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Refreshing open forms when something changes > Then why did your intial post contain this sample code: Because that is how it works *in this case*. The message class is a hammer. It can hammer finishing tacks or railroad spikes. *In this case* I have a grand total of 27 forms including the switchboard stuff and the login form. This is a tiny database for a very specific purpose, filling out one specific piece of paper for the prison system on North Carolina. I have a single form that the user (volunteer) uses to select cities that (s)he wants to see locations and meetings in. There are lists up on the main form that need to requery (to show the locations / meetings in the selected cities) and combos in two different subforms that need to requery when the user adds or deletes a city (to allow the user to select from the locations / meetings in the selected cities). IOW there is exactly one form raising events on the message class and three forms (potentially) sinking the events and examining the message. Jim, you are getting waaaaayyyy too bogged down in micromanaging things. All this is (as I have specifically stated in a dozen responses) is a way for any process that wants to to wave its hand and say "I did something". It is a way for any process that wants to to listen to processes wave their hand. It is absolutely 100% the same technology and the same process as a combo raising its hand and saying "I changed" (afterupdate) or a form to wave its hand and say "I deleted a record" (on delete). > It implies that it may receive events that don't pertain to it. It might receive events that don't pertain to it if: 1) It sinks events for the message class 2) It sinks events for the *SAME* message class. Jim, in *this* case a user *MIGHT* open a form to add / delete cities. Once they do that they *might* open that form and add / delete cities again in a few months. Does that sound like the kind of message traffic that is going to bog down the application? Assuming that each message takes 100 nano seconds to process and the user modifies ... 12 cities a month... that is a *total* of 1.2 milliseconds per month of computer time spent processing these messages. > Sorry, but to me, it's that type of thinking that has lead to bloated/slow software. Uh yea I guess you are right. I will definitely see if I can reduce the expected 1.2 milliseconds / month of message traffic so that my app doesn't experience bloat / slowness. I can see you are resisting a message class Jim. ;) Did you even bother to run the demo classes I included before you started raising objections? Do you have any idea how it works? If so then you already know how to modify it to be more like how you personally would like it to work. Perhaps use the .SendSimple method and a different class instance for each process in your application? That's what I would do if I got too much traffic on a channel. John W. Colby www.ColbyConsulting.com On 6/21/2011 1:53 PM, Jim Dettman wrote: > John, > > <<2) I can if I wish create 1 to N (hundreds if I wish) different instances > of clsMsg and each > "functional set" can grab a pointer to the clsMsg instance that it needs to > watch messages on.>> > > Then why did your intial post contain this sample code: > > private sub mcMsg_Message(varFrom as variant, varTo as variant, varSubject > as variant, varMsg as > variant) > > if VarFrom = "MyName" then > if VarTo = "WhoThisIsGoingTo" then > if VarSubject = "MySubject" then > 'Requery the combo > MyCombo.requery > endif > endif > endif > end sub > > It implies that it may receive events that don't pertain to it. Other > wise, there would be no need for the first two If checks. And if you > implemented a BO class as Drew outlined, there'd be no need for the third > either. > > <<3) Most forms just "sit there" anyway. The user is looking at the screen, > yaking on the phone, > smoking a cigarette and oh yea, entering stuff. > > Processing a message is going to take about... under a millisecond. > Probably a few hundred > microseconds in fact. So even if I have a dozen forms open at once, and all > of them use the message > channel, how much machine time is actually used to process the message in > all the forms?>> > > Sorry, but to me, it's that type of thinking that has lead to bloated/slow > software. > > Jim. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com