test for events as they occur on a different form

  • Follow


Is there any way to have VBA code in one form test for events that are
occurring on another? Something like: 

public otheractiveform.form_keyup()
   do stuff
end sub

The idea is to have a form that's always open run a test generically on
whatever other form happens  to have the focus at that time, and to do it
without having to write any supporting code on the other form.

Here's the quick rundown on why I ask:
I already use a hidden form that tracks how long it's been since the focus
has been changed to a new active control and closes the db if it's been idle
for more than an hour (thanks Lebans). What I would like to do is use that
same code to close individual forms that have been open and idle for more
than a specified amount of time (like 40 seconds). That's easy enough--just
close the active form if the active control hasn't changed focus during that
time--but I don't want to close a form while someone is editing the active
control. I could test whether the control is dirty, but that would only tell
me that a change has been made, not that someone is still actively working on
the control. If I halt the shutdown for a dirty control and the user doesn't
update it, then the control stays dirty and the whole process gets stuck.
Another solution is to abandon the background timer and instead put a timer
event on each form that looks for the keyup event, but the problems there are
that 1) I have to code every form (there are many) and 2) I have to build in
a heirarchy so that if the second form opens a third, its own timer stops
while the third form is completed.

-- 
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/Forums.aspx/access-formscoding/201001/1

0
Reply vircalendar 1/1/2010 11:41:03 PM

"vircalendar via AccessMonster.com" <u4313@uwe> wrote in message 
news:a17b61380e44a@uwe...
> Is there any way to have VBA code in one form test for events that are
> occurring on another? Something like:
>
> public otheractiveform.form_keyup()
>   do stuff
> end sub
>
> The idea is to have a form that's always open run a test generically on
> whatever other form happens  to have the focus at that time, and to do it
> without having to write any supporting code on the other form.
>
> Here's the quick rundown on why I ask:
> I already use a hidden form that tracks how long it's been since the focus
> has been changed to a new active control and closes the db if it's been 
> idle
> for more than an hour (thanks Lebans). What I would like to do is use that
> same code to close individual forms that have been open and idle for more
> than a specified amount of time (like 40 seconds). That's easy 
> enough--just
> close the active form if the active control hasn't changed focus during 
> that
> time--but I don't want to close a form while someone is editing the active
> control. I could test whether the control is dirty, but that would only 
> tell
> me that a change has been made, not that someone is still actively working 
> on
> the control. If I halt the shutdown for a dirty control and the user 
> doesn't
> update it, then the control stays dirty and the whole process gets stuck.
> Another solution is to abandon the background timer and instead put a 
> timer
> event on each form that looks for the keyup event, but the problems there 
> are
> that 1) I have to code every form (there are many) and 2) I have to build 
> in
> a heirarchy so that if the second form opens a third, its own timer stops
> while the third form is completed.
>
> -- 
> Message posted via AccessMonster.com
> http://www.accessmonster.com/Uwe/Forums.aspx/access-formscoding/201001/1

You should be able to do this by tracking Screen.ActiveControl and/or 
Screen.ActiveForm using your background timer. (Untried)

HTH


0
Reply Stuart 1/2/2010 12:50:25 AM


I am doing that.  Problem is that screen.active control only tells me what's
in the control when it becomes active or is updated.  It doesn't give me real-
time feedback while the active control is being edited.  What I need to know
is whether or not there is active work being done on the field (ie keyup).
Again, what I'm specifically asking is whether or not I can track the keyup
event as it occurs on a different form.

Stuart McCall wrote:
>> Is there any way to have VBA code in one form test for events that are
>> occurring on another? Something like:
>[quoted text clipped - 33 lines]
>> a heirarchy so that if the second form opens a third, its own timer stops
>> while the third form is completed.
>
>You should be able to do this by tracking Screen.ActiveControl and/or 
>Screen.ActiveForm using your background timer. (Untried)
>
>HTH

-- 
Message posted via http://www.accessmonster.com

0
Reply vircalendar 1/2/2010 1:45:16 AM

"vircalendar via AccessMonster.com" <u4313@uwe> wrote in message 
news:a17c77133434c@uwe...
>I am doing that.  Problem is that screen.active control only tells me 
>what's
> in the control when it becomes active or is updated.  It doesn't give me 
> real-
> time feedback while the active control is being edited.  What I need to 
> know
> is whether or not there is active work being done on the field (ie keyup).
> Again, what I'm specifically asking is whether or not I can track the 
> keyup
> event as it occurs on a different form.
>
I can't see a way of catching keystrokes, but you could try examining the 
SelLength, SelStart, and SelText properties of the control, perhaps?

> Stuart McCall wrote:
>>> Is there any way to have VBA code in one form test for events that are
>>> occurring on another? Something like:
>>[quoted text clipped - 33 lines]
>>> a heirarchy so that if the second form opens a third, its own timer 
>>> stops
>>> while the third form is completed.
>>
>>You should be able to do this by tracking Screen.ActiveControl and/or
>>Screen.ActiveForm using your background timer. (Untried)
>>
>>HTH
>
> -- 
> Message posted via http://www.accessmonster.com
> 


0
Reply Stuart 1/2/2010 2:36:26 AM

I don't think that any of those will change until the control is updated.  As
far as I know, the only way to trap keystrokes is the keyup/keydown approach,
so I'm wondering whether those events can be captured by another form.

Stuart McCall wrote:
>>I am doing that.  Problem is that screen.active control only tells me 
>>what's
>[quoted text clipped - 6 lines]
>> keyup
>> event as it occurs on a different form.
>
>I can't see a way of catching keystrokes, but you could try examining the 
>SelLength, SelStart, and SelText properties of the control, perhaps?
>
>>>> Is there any way to have VBA code in one form test for events that are
>>>> occurring on another? Something like:
>[quoted text clipped - 7 lines]
>>>
>>>HTH

-- 
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/Forums.aspx/access-formscoding/201001/1

0
Reply vircalendar 1/2/2010 2:49:47 AM

"vircalendar via AccessMonster.com" <u4313@uwe> wrote in message 
news:a17d0721ba4d6@uwe...
>I don't think that any of those will change until the control is updated. 
>As

Try it. You'll find they update as editing takes place.

> far as I know, the only way to trap keystrokes is the keyup/keydown 
> approach,
> so I'm wondering whether those events can be captured by another form.

I don't see a solution to that which doesn't involve putting code in the 
form's KeyDown event.

>
> Stuart McCall wrote:
>>>I am doing that.  Problem is that screen.active control only tells me
>>>what's
>>[quoted text clipped - 6 lines]
>>> keyup
>>> event as it occurs on a different form.
>>
>>I can't see a way of catching keystrokes, but you could try examining the
>>SelLength, SelStart, and SelText properties of the control, perhaps?
>>
>>>>> Is there any way to have VBA code in one form test for events that are
>>>>> occurring on another? Something like:
>>[quoted text clipped - 7 lines]
>>>>
>>>>HTH
>
> -- 
> Message posted via AccessMonster.com
> http://www.accessmonster.com/Uwe/Forums.aspx/access-formscoding/201001/1
> 


0
Reply Stuart 1/2/2010 4:01:51 AM

5 Replies
204 Views

(page loaded in 0.087 seconds)

Similiar Articles:
















7/26/2012 11:47:58 AM


Reply: