[AccessD] Off the wall Events question...

Rather than passing in form and control names you'd be better off to pass in 
a reference to the actual control or controls.  The calendar can then use 
the reference as a local variable regardless of any form -sub -sub-sub form 
nesting.  Any changes to the properties of the control can be made directly 
by the calendar.

Should you change the value of a date display control in this fashion, any 
code in the control's before or after update will not be triggered.  If you 
need to call an event on the control's container from the calendar, you may 
provide a public procedure on the control container code behind the form and 
reference it from the calendar through the reference's parent.  Although the 
procedure is public and may be on multiple different forms or even instances 
of a single form, by calling the procdure through the reference parent, 
there is no danger in calling the wrong public sub provided it is only 
called by the calendar and the broad scope of a public procedure is safe.  
All the public procedure needs is a single line of code that calls the 
private after update.

If you make the calendar modal and pass a control reference, it is a simple 
matter to first cache the value of the passed in control before opening the 
modal form and in the line after the calendar is opened, call the private 
after update should the value of the control be different from the cached 
value.  As one wouldn't ordinarily expect the after update to run 
asynchronously, this method would also work in the vast majority of 
situations.

Hen



>From: Drew Wutka <DWUTKA at marlow.com>
>Reply-To: accessd at databaseadvisors.com
>To: "'AccessD at databaseadvisors.com'" <AccessD at databaseadvisors.com>
>Subject: [AccessD] Off the wall Events question...
>Date: Wed, 12 Feb 2003 22:49:13 -0600
>
>With all of the posts about events recently, something just dawned on me.
>Actually, it came crashing down on me.
>
>I have been rewriting my MiniCalendar form lately.  My original works, but
>is far from elegant, or even slick.  I had visualized a lot of changes I
>wanted to incorporate, and just starting wacking at them all.
>
>So far I have gotten some neat 'features', such as a rounded form, extended
>dropdown capability, etc.  However, one of the new features that I had
>planned on, I now know I can't do directly.  The old form accepted a form
>name and control name, and would return a date to that control.  What I
>wanted to use in this version was raiseevent, to fire an event on the
>calling form.  Thinking in VB 6 mode, I didn't even realize this would be a
>problem with Access 97, since I can do this easily in VB 6.  But with all 
>of
>the recent posts, I realized that event and raiseevent are reserved 
>keywords
>in Access 97 (VBA 5.0), but do nothing.
>
>ARG!!!!
>
>So, does anyone know how to accomplish the same thing in Access 97.  I will
>be making a 2000 version of my calendar, so obviously I can use event and
>raiseevent there, but I am developing the new version in 97 first, so I 
>need
>a work around.  I am thinking about using one of the form's current events,
>and triggering it.  (Probably AfterUpdate).  I wanted my own event, but 
>that
>doesn't look possible.  I even tried hunting through the VBA .dll's, to see
>if I could fudge an API or two, but no luck there.
>
>Any thoughts?
>
>Drew
>_______________________________________________
>AccessD mailing list
>AccessD at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/accessd
>Website: http://www.databaseadvisors.com


_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.  
http://join.msn.com/?page=features/virus