[AccessD] Refreshing open forms when something changes

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




More information about the AccessD mailing list