The only time I've seen the codename fail is when I'm adding a new sheet and the
VBE hasn't been opened. But in other cases, I don't remember seeing any
problem.

And if "can all work" means that your macro stops with a warning message that
things aren't right, then I see your point <vbg.

(I've used a hidden worksheet level name to make sure that I'm on a "correct"
type of worksheet, too.)

Jim Cone wrote:


There ain't no easy way. Am I the only one who has found the use of code
names unreliable? It would make life much easier to be able to use them.
Using object references, identifying sheets by a unique feature,
and using a VerifySheetExists function..."Can't find the Total Tally Sheet"
can all work.
--
Jim Cone
San Francisco, USA
http://www.realezsites.com/bus/primitivesoftware
(Excel Add-ins / Excel Programming)

"Dave Peterson"
wrote in message
Do you protect the structure of every workbook that you develop so that users
can't rename the worksheets?
Or do you find the correct worksheet some other way -- in case that worksheet is
renamed?

Jim Cone wrote:


Once bitten, twice shy...
I had difficulties using codenames a few years back and since then never
use them. I prefer to set an object reference to a sheet and use that
through out the code.
(the above ought to help this discussion really get going, maybe it will work as
well as recommending Database functions instead of SumProduct formulas) <g
--
Jim Cone
San Francisco, USA
http://www.realezsites.com/bus/primitivesoftware
(Excel Add-ins / Excel Programming)


"Dave Peterson"
wrote in message
You may find that using the codename makes your procedure much more robust than
using the worksheet name. I don't think I'd warn people to stay away from using
it.

JLGWhiz wrote:
<<snipped

Don't get into the code name, if you can help it.
--
Dave Peterson

--

Dave Peterson