[AccessD] Refreshing open forms when something changes

IMO, what all this JC class stuff needs is a wizard, because there are too
many steps required to get it all right. I have followed JC's threads and
implemented them, but it is a lot of work, in several different modules. IMO
it ought to work similarly to MzTools, with an add-in that requests the form
in which to implement this stuff, and automatically adds the code to declare
the class references, etc.

Call me lazy, but I'm getting old.


On Wed, Jun 22, 2011 at 12:54 PM, jwcolby <jwcolby at colbyconsulting.com>wrote:

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