Rick's suggestion is the most obvious approach, but unfortunately
is not 100% reliable.
The Filter property of a form or report may contain an old filter,
even if the filter is not applied.
Can that possibly be a problem for a report that was opened with
DoCmd.Openform and criteria passed as an argument to that command? I
thought the command worked by taking the argument passed, putting in
the Filter property (overwriting anything that might have been there
already) and turning FilterOn to True. If I'm right, then there's no
way what you describe could happen.
Therefore you need to test the FilterOn property
to see if it's a real filter or an artifact:
If Me.FilterOn Then MsgBox Me.Filter
That works perfectly in forms, but in reports Access does not
always report the FilterOn property correctly in Report_Open.
(I haven't tested this in A2007, but it was a problem in previous
versions.)
I think I'd want to write anything like this to work regardless of
whether the report was opened with a filter argument or not, so I'd
probably be checking anyway.
On the other hand, an awful lot of my reports are driven by
filtering that draws its values from a class module used for storing
the filter values, so that the WHERE clause gets written in the Open
event and assigned there. In that case, I have full control and can
always know what's going on.