Using the "Screen" method

[Bill]

I have the following code in a general module. What
test can I make prior to the use of the "Screen"
method when I don't know what's on the screen?

For example, I get a runtime error if I execute the
statement for ActiveReport when there's a form
being displayed and visa versa.

Dim CtlCtxID As Long
Dim FrmCtxID As Long
Dim RptCtxID As Long
Dim ID As Long

RptCtxID = Screen.ActiveReport.HelpContextId
CtlCtxID = Screen.ActiveControl.HelpContextId
FrmCtxID = Screen.ActiveForm.HelpContextId

 

[Bill]

Douglas,
Thanks for your suggestion. My code now reads:

Option Compare Database

Public Function HTMLctxHelp()
'====================================================================================
' AutoKeys macro is coded to intercept the user's use of program function
key "F1".
' This function accesses the context ID for whatever is currently on the
screen and
' launches the HTML viewer that will "autosync" the topic with the current
display.
'====================================================================================
Dim CtlCtxID As Long
Dim FrmCtxID As Long
Dim RptCtxID As Long
Dim ID As Long
Dim strHelpPath As String

On Error GoTo ExpectedScreenError

'====================================================================================
' Only 1 of the 3 "Screen" statements will return a value. Other two will
each raise
' an error, leaving the target variables zero.
'====================================================================================
RptCtxID = Screen.ActiveReport.HelpContextId
CtlCtxID = Screen.ActiveControl.HelpContextId
FrmCtxID = Screen.ActiveControl.HelpContextId

ID = CtlCtxID + RptCtxID + FrmCtxID 'x+0+0, 0+x+0, 0+0+x or 0+0+0
If ID = 0 Then ID = 9999 'No ID specified, show TOC @
"Welcome"


strHelpPath = IPPath & "\TMS.chm"

Call HtmlHelpCtx(strHelpPath, ID)


End_HTMLctxHelp:
Exit Function

ExpectedScreenError:
'====================================================================================
' Two of the three "Screen" method statements will raise an error condition
because
' there will only be control elements for whatever type of screen is
currently open,
' be it a report, form or other control.
'====================================================================================
If Err.Number = 2474 Then 'In fact a screen error? (Steele thought it
was 2476?)
Resume Next 'Yes, we'll ignore it
Else
MsgBox Err.Number & ": " & Err.Description, vbOKOnly + vbCritical
Resume End_HTMLctxHelp
End If

End Function


With a "Report" in currently displayed in preview,
error 2474 is raised for the Screen.ActiveControl,
but the error routine DOES NOT get control.

With the same "Report" displayed AND the
Screen.ActiveControl commented out, error 2475
is raised when the Screen.ActiveControl statement
is reached. I didn't have any trace turned on so I
don't know if the error handler fired or not.

Did I not follow your suggestion correctly?

Bill

 

[Douglas J. Steele]

Afraid I don't know by "the error routine DOES NOT get control"

There are a few minor corrections you need to make, but they don't really
change the gist of what's going on.

I suspect you really mean

FrmCtxID = Screen.ActiveForm.HelpContextId

not the

FrmCtxID = Screen.ActiveControl.HelpContextId

you have.

If you refer to Screen.ActiveControl when there isn't an active control,
you'll get an error 2474 raised. If you refer to Screen.ActiveForm when
there isn't an active form, you'll get an error 2475 raised. If you refer to
Screen.ActiveReport when there isn't an active report, you'll get an error
2476 raised.

Changing your code to:

Public Function HTMLctxHelp()
Dim CtlCtxID As Long
Dim FrmCtxID As Long
Dim RptCtxID As Long
Dim ID As Long
Dim strError As String

On Error GoTo ExpectedScreenError

RptCtxID = Screen.ActiveReport.HelpContextId
CtlCtxID = Screen.ActiveControl.HelpContextId
FrmCtxID = Screen.ActiveForm.HelpContextId

ID = CtlCtxID + RptCtxID + FrmCtxID
If ID = 0 Then ID = 9999

MsgBox ID & vbCrLf & strError


End_HTMLctxHelp:
Exit Function

ExpectedScreenError:
Select Case Err.Number
Case 2474 ' No active control
CtlCtxID = 2474
strError = strError & _
"No active control" & vbCrLf
Resume Next
Case 2475 ' No active form
FrmCtxID = 2476
strError = strError & _
"No active form" & vbCrLf
Resume Next
Case 2476 ' No active report
RptCtxID = 2476
strError = strError & _
"No active report" & vbCrLf
Resume Next
Case Else
MsgBox Err.Number & ": " & _
Err.Description, vbOKOnly + vbCritical
Resume End_HTMLctxHelp
End Select

End Function

it works fine for me (tested in both Access 97 and Access 2003)

 

[Bill]

Douglas,
I don't know how the one assignment statement you
pointed out got that way, as it is correct in my actual
code???

Anyway, I implemented the Select as you suggested along
with the MsgBox debug statement so that I can see exactly
what got accumulated as the error routine's path was
followed.

However, no matter what I've tried, the error routine
does not receive control when the errors occur. I
thought it might have something to do with being invoked
by a macro rather than being called from the code in a
form or report, so I inserted a direct call from a "form's"
codesheet but the error routine still did not receive control
when the Screen.ActiveReport was referenced.

My environment is XP SP2 and Access 2000 SP3.

I know of no place in my application where error handling
has been disabled. I am executing my application from the
front-end mdb of a split database, as opposed to the normal
mde in a production configuration.

Bill

 

[Bill]

Douglas,
Just on a hunch, I created the fron-end mde and
tested from that. There, the error handler does in
fact run and the debug MsgBox statement reports
the errors encountered as expected.

Any explanation as to why the error routine runs
in a mde but not in a mdb?

Bill

 

[Douglas J. Steele]

Sorry, no idea. I only tested with MDBs, and, as I said, it worked fine for
me.

 

[Bill]

Doug,
I trust you saw Goldgar's post about the General Options
in the VBA Editor, wherein he pointed me to the
error handling options. I'm surprised that the product didn't
release with "Break on Unhandled Errors" as the default.
Oh well, time for another beer!
Thanks,
Bill