[AccessD] event identification

Access controls reuse a single floating window that can be accessed by
handle when the control receives the focus, using the GetFocus() API
call.  

Access forms are true windows (OForm window class), and have a built-in
hWnd property that is available at all times.


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Colby, John
Sent: Tuesday, November 09, 2004 1:17 PM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] event identification


Everything I've read says a control does NOT have a hwind.  Forms might.
Not exactly my area of expertise however.

John W. Colby
The DIS Database Guy


-----Original Message-----
From: Jim Dettman [mailto:jimdettman at earthlink.net]
Sent: Tuesday, November 09, 2004 2:02 PM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] event identification


John,

<<Objects inside of Access are not true windows to
windows, thus the mouse event has to be translated by Access using the
position in the Access window etc. >>

  I don't think that's quite right.  While Access objects are not true
Windows objects, they do get a hwnd when they are active.  I don't think
the
mouse clicks are translated based on position.

Jim


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Colby, John
Sent: Tuesday, November 09, 2004 12:46 PM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] event identification


Susan,

I have never found a single place to go, particularly for sequence.  The
order of events can get really strange, particularly if you throw in
form /
subform loads, subform enter / exit etc.  In the Access help somewhere
there
is a generic order of events for the form events, and the control
events,
but it definitely cannot tell the whole story.

As far as what's going on behind the scenes... you don't even want to
know.
Now you get into things like mouse clicks where Windows hands the mouse
event to Access which translates it into a form / control event.
Normally
Windows directly hands a mouse event to the window the mouse is inside
of -
Window meaning a window object, anything square.  That object has to
decide
how to handle the click.  Objects inside of Access are not true windows
to
windows, thus the mouse event has to be translated by Access using the
position in the Access window etc.

Similarly key down/up/press... is it handled by the form or by the
control?
What if the control should but doesn't? (it ripples up to the form
AFAIK).

Events are a rather deep subject.

I think I have a widget on my site that uses the control classes and
form
class to debug.print all the events that fire, in the order fired as you
do
anything in the form.  If you want to use it I will need to go look
around
and see what it is called.  It was part of the lecture series I think.

John W. Colby
The DIS Database Guy


-----Original Message-----
From: Susan Harkins [mailto:ssharkins at bellsouth.net]
Sent: Tuesday, November 09, 2004 12:21 PM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] event identification


BTW, does anyone have a good online resource for an explanation of the
Access event model -- sequence and what's going on behind the scenes? I
just
need to check things before I go on record and in my usual
search-challenged
way, I can't find anything worth squat. :(

Susan H.

That's what I thought. Thanks guys!

Susan H.


--------------------------------------------------------------------------------------------------------------------
The information in this email may contain confidential information that 
is legally privileged. The information is only for the use of the intended 
recipient(s) named above. If you are not the intended recipient(s), you 
are hereby notified that any disclosure, copying, distribution, or the taking 
of any action in regard to the content of this email is strictly prohibited.  If 
transmission is incorrect, unclear, or incomplete, please notify the sender 
immediately. The authorized recipient(s) of this information is/are prohibited 
from disclosing this information to any other party and is/are required to 
destroy the information after its stated need has been fulfilled.

Any views expressed in this message are those of the individual
sender, except where the sender specifies and with authority,
states them to be the views of Tappe Construction Co.

This footer also confirms that this email message has been scanned
for the presence of computer viruses.Scanning of this message and
addition of this footer is performed by SurfControl E-mail Filter software
in conjunction with virus detection software.