[AccessD] Refreshing open forms when something changes

Jim Dettman jimdettman at verizon.net
Thu Jun 23 08:16:55 CDT 2011


<<I was making an honest effort to demonstrate a method of handling a
problem.  Apparently that 
annoyed you?  Perhaps because you "rarely use classes" and so could not
accomplish this solution.>>

  Didn't annoy me in the slightest.  And I said "I don't use classes for the
most part with Access", not that I rarely use classes.

  You're the one that got his kickers in a twist, not me.

Jim. 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Wednesday, June 22, 2011 12:54 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Refreshing open forms when something changes

Jim,

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

To be honest I do not think it is inefficient at all.  It would be
inefficient if it made any damned 
difference at all.  It doesn't.  It would be inefficient if it were sucking
up processor cycles.  It 
isn't.  Is it the absolutely most efficient method of accomplishing the
objective?  No, but it makes 
no damned difference.  If I were to re-engineer it to be as efficient as
possible I would save 1 
trillionth of a percent of whatever metric you choose.

 > programmer takes the attitude of "it's just a few extra cycles", then
sooner or latter, you end 
up with a problem.

If every programmer in the world wasted a few trillionths of a percent of
whatever metric you 
choose, it would make no damned difference whatsoever.  This method, even
taken to the extreme, used 
in every single form in every Access program running on the planet is never
going to waste more than 
a few processor cycles.

The whole point of events is that processing only happens when an event
happens.  Events can only be 
raised and sunk in classes so if you don't use classes then you don't use
events.  If you aren't 
using events that you almost certainly doing some very inefficient
programming.

 >A. I don't use classes for the most part with Access.  Without full
inheritance, I don't think 
it's worth the effort.

That is just nonsense.  In the last year I have engineered a *major* system
in C# and I have used 
inheritance a handful of times.  If you can't find a use for classes without
inheritance then:

a) You aren't much of a programmer and
b) You obviously don't use Access forms (they are a class) or combos (they
are a class) or 
recordsets (they are a class) or reports (class), queries (class) or
anything else in Access. 
*Every single object* in Access is a class and you can't inherit any of
them.

Would you care to rethink your statement?  To say that Access' classes are
useless without 
inheritance is mind boggling nonsense.

I was making an honest effort to demonstrate a method of handling a problem.
Apparently that 
annoyed you?  Perhaps because you "rarely use classes" and so could not
accomplish this solution.

At any rate I have no idea what you are doing other than being
argumentative.

John W. Colby
www.ColbyConsulting.com

On 6/22/2011 11:26 AM, Jim Dettman wrote:
> John,
> Mind boggling nonsense after that...
-- 
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