[AccessD] Refreshing open forms when something changes

jwcolby jwcolby at colbyconsulting.com
Tue Jun 21 13:44:18 CDT 2011


 >    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.



More information about the AccessD mailing list