Problems with implementing inactivitycheck

[Lars Brownies]

I'm trying to implement the inactivity check on
http://support.microsoft.com/kb/128814. It works well, except for one thing:

In my app I capture the Ctrl-F by a macro which executes a function that
checks if a filter is active. User can choose if he wants to drop the filter
before searching. After that the find dialog is triggered. This all worked
well till I added the inactivity check. Now when I press Ctrl-F I get "error
2137 Find & Replace cannot be used."

When I change the inactivity timer interval from 1000 to 20000, the Ctr-F
dialog does pop up, also if I repeat it a couple of tiems. But after a while
I get the 2137 error again and when I keep trying Ctrl-F again, from then on
I get this 2137 error everytime.

Even if I drop all the code in the function and only leave the 'find'-code
in (see code below) , the behavior is the same and I get the error.

Does anyone know what might cause this? Any ideas to solve it?

Thanks,

Lars


Function fSearch()
On Error GoTo Err_Handler

[...]

DoCmd.DoMenuItem acFormBar, acEditMenu, 10, , acMenuVer70

Exit_this_function:
Exit Function
Err_Handler:
MsgBox "Error# " & Err.Number & ": " & Err.Description
Call ErrorLog("Generic", "fSearch")
Resume Exit_this_function
End Function

 

[Albert D. Kallal]

what happens is when the timer code fires..."internal" the focus moves to
that form...

so, : **right* before you execute the code, use code to "select" the current
form....

Try:


DoCmd.SelectObject acForm, Screen.ActiveForm.Name
call find code goes here.....

You might be able to put the select object code inside of the
sub/function...you have to try it both ways....


eg:

[...]

DoCmd.SelectObject acForm, Screen.ActiveForm.Name <-try here...

DoCmd.DoMenuItem acFormBar, acEditMenu, 10, , acMenuVer70

Exit_this_function:

[....]

The 2nd above suggest is better since then you don't have to modify the
calling code....

 

[Lars Brownies]

Thanks so much! It works. I was really afraid this couldn't be solved.

Since the code is firing from an autokeys macro, there is no other calling
code than fSearch().

Your 2nd suggestion does the job!

Lars

what happens is when the timer code fires..."internal" the focus moves to
that form...

so, : **right* before you execute the code, use code to "select" the
current form....

Try:


DoCmd.SelectObject acForm, Screen.ActiveForm.Name
call find code goes here.....

You might be able to put the select object code inside of the
sub/function...you have to try it both ways....


eg:

[...]

DoCmd.SelectObject acForm, Screen.ActiveForm.Name <-try here...

DoCmd.DoMenuItem acFormBar, acEditMenu, 10, , acMenuVer70

Exit_this_function:

[....]

The 2nd above suggest is better since then you don't have to modify the
calling code....

 

[Lars Brownies]

One additional question. The microsof inactivity example shows a timer
interval of 1000. Is it really necessary to run the timer code every second?
Wouldn't it put less pressure on the app to do the ceck every 5 seconds for
example? Or is it trivial?

Thanks.

Lars

what happens is when the timer code fires..."internal" the focus moves to
that form...

so, : **right* before you execute the code, use code to "select" the
current form....

Try:


DoCmd.SelectObject acForm, Screen.ActiveForm.Name
call find code goes here.....

You might be able to put the select object code inside of the
sub/function...you have to try it both ways....


eg:

[...]

DoCmd.SelectObject acForm, Screen.ActiveForm.Name <-try here...

DoCmd.DoMenuItem acFormBar, acEditMenu, 10, , acMenuVer70

Exit_this_function:

[....]

The 2nd above suggest is better since then you don't have to modify the
calling code....

 

[Albert D. Kallal]

One additional question. The microsof inactivity example shows a timer
interval of 1000. Is it really necessary to run the timer code every
second? Wouldn't it put less pressure on the app to do the ceck every 5
seconds for example? Or is it trivial?

I think 4 or 5 seconds would also be choice. It been a number of years since
I looked at that code...

I suppose it is possile tat a person could mdoify a form...move on to
somthing else, and thus in that 4.5 seconds the code might not miss a
change??? However, if the persons working that fast, I quite sure a "change"
would be triggerd...

So, I think 4-5 seconds is more then enought. I not by by other code, but I
recall using 10 seconds....

Also, keep in mind that while "focus" issues are quite rare, if you have
custom menus in in a report menu bar, then keep the following in mind:

For the code that pops up the printer dialog (so the user can change
printers etc).

You can use:

On Error Resume Next
DoCmd.SelectObject acReport, Screen.ActiveReport.Name
DoCmd.RunCommand acCmdPrint

As noted the select object command is needed to fix a "focus" bug if you
have a form
with a timer function.

The code to print right to the printer while in preview mode can be:

On Error Resume Next
Dim strReportName as string
strREportName = Screen.ActiveReport.Name
DoCmd.SelectObject acReport, strReportName
DoCmd.PrintOut acPrintAll

 

[Lars Brownies]

"Albert D. Kallal" <[email protected]> schreef in bericht
I think 4 or 5 seconds would also be choice. It been a number of
years since

I looked at that code...

I suppose it is possile tat a person could mdoify a form...move on to
somthing else, and thus in that 4.5 seconds the code might not miss a
change??? However, if the persons working that fast, I quite sure a
"change" would be triggerd...
So, I think 4-5 seconds is more then enought. I not by by other code, but
I recall using 10 seconds....

I've set it to 5 seconds and see how this goes. The user gets thrown out
after 45 minutes. First impression is, that this works well and that is
acceptable for the users.

Also, keep in mind that while "focus" issues are quite rare, if you have
custom menus in in a report menu bar, then keep the following in mind:

For the code that pops up the printer dialog (so the user can change
printers etc).

Thanks for the tip. I do use custom menubars but for printing no custom
men-items. But always good to know.


Lars