Now that most of my users have upgraded to XP, I've
started using some XP code in my procedures. Some of the
users are still using Excel 2000. To get around that, I
put the procedures that use XP code in a separate module.
Then I do this:

'Where separate module is called XP_Procs
If Application.Version = "10.0" then
Call XP_Procs.MyProcedureWithXPCode
Else
'Version for Excel 2000
End if

This works fine. However, it does not work for events. For
example, I'd like to use the Worsheet_PivotTableUpdate
event. If I as much as put the empty event on a sheet and
an Excel 2000 user pivots the table on that sheet, it will
display an error when it does not recognize the event. I
can't put the worksheet event in a separate module. So...
does anyone know how I can take advantage of XP events in
such a way that Excel 2000 users do not get errors?

tod

"Tod" wrote...
Now that most of my users have upgraded to XP, I've
started using some XP code in my procedures. Some of the
users are still using Excel 2000. To get around that, I
put the procedures that use XP code in a separate module.
....
does anyone know how I can take advantage of XP events in
such a way that Excel 2000 users do not get errors?

No. And thank you for an absolutely classic example of why any and all
developers in any and all companies need to be given the *OLDEST* and
*SLOWEST* hardware and software that's in use *BY* *ANYONE* in their company
in order to prevent backward compatibility snafus such as this.

Until *ALL* of your users are upgraded, you should *AVOID* using *ANY* Excel
XP-specific functionality of any kind. Other stuff aside from event handlers
may seem to work most of the time, but there's no way you've tested all the
possible combinations of circunstances your users can throw at your models
in a single week. Meaning there's no way you can be certain 2K and XP users
get the same results from the same inputs unless they use exactly the same
formulas and VBA code (modulo known changes in some worksheet functions).