That turned out to be the key: When I call RangeValues from a sheet module
the scope is different than when I call it from a standard module. And that
bit about wbo being a property of the calling sheet is seriously weird, but I
can use it, I think, to let the subroutine take calls from either type of
module. Thanks, Dave, I think I'm back on track now.

--- "Dave Peterson" wrote:
Next time you're stepping through your code with the watch window open, look
at the Context column in that watch window. I think you'll see that wbo is
local to that sheet module....the ThisWorkbook and Sheet modules are private
class (specially treated class) modules.

I put this procedure in a worksheet module:

Option Explicit
Public wbo As Workbook
Sub testme()
Dim Stns As Variant '???
Set wbo = Workbooks("MyWorkbook.xls")
Stns = RangeValues("Map", 2, 4)
End Sub

The sheet that I used had a codename (not name that you see in the tab in
excel) of Sheet1. That's why this line knew where to find wbo:

Set wso = Sheet1.wbo.Worksheets(SheetName)

If your sheet had a different codename, you'd have to change that line.
It has nothing to do with the parent of the workbook. It's qualifying the
variable--not the workbook. wbo.parent would be the excel application itself.

----- Original Message -----
From: Bob Bridges
Sent: Monday, October 26, 2009 23:10

The function in the general module doesn't know about wbo.

But wait, I said below that when I'm just about to execute the
"Set wso = wbo.Workbooks"-etc statement, I can see wbo in the
Watch window. If (while executing RangeValues) I can see wbo in
Watch, doesn't that prove that it does know about wbo?

And because I defined wbo Public in the declarations of the sheet module,
shouldn't wbo be "available to all procedures in the project", as the
documentation says?

You could use...
Set wso = Sheet1.wbo.Worksheets(SheetName)

I think you just made a typo or something there. What's Sheet1 and
why do you think it can be a parent of the workbook?