View Single Post
  #5   Report Post  
Posted to microsoft.public.excel.programming
GS[_2_] GS[_2_] is offline
external usenet poster
 
Posts: 3,514
Default forwards/backward compatibility Excel 2003-2007

cubbybear3 explained :
I don't know if this is stuff you already know or not, but the xl2007
extensions now have meaning.
*.xlsx=NO macros;
*.xlsm=Has macros.

One problem I had when going from 2003 to 2007 is I had made the
mistake of using the controls toolbar for buttons in 2003. After
converting them to the Forms toolbar in 2007, they worked fine.

Also, when in 2007 and saving as a 2003, make sure you do "Save as
xl97/xl2003".

HTH.

-pb


I rarely use worksheet controls but when I do it's usually Forms
controls. Mostly, I use custom menus/toolbars. Using early XLAs to run
VBA in either environment has no bearing on how my project workbooks
get saved. The point I was attempting to convey here is that if the VBA
is separate from the files the macros act on (termed 'project files' in
Excel developer land<g) then there's no compatibility issue at all!
The result of my suggestion produces workbooks with no VBA macros and
so the SaveAs process is much simpler because Excel processes how the
file gets saved in its normal fashion same as if you opened a new
workbook and saved it. It's when workbooks being saved include macros
that the issue arises! Ergo.., no code, no compatibility issues!!!

It's imperative that, as you say, we make sure our early files with VBA
get saved as early files if we want them to continue to work in early
versions. In cases where my projects use code in the same workbook that
code acts on, the project manages the save issue via the Auto-Close
procedure I use in place of the Workbook_BeforeClose event. This is a
more convenient way to handle changes to the file so shutdown is a
smooth and graceful process without any nagging prompts. That's made
possible by hooking all of Excel's shutdown/close events so they run my
code in place of the built-in processes.

Another concern with distributing workbooks with VBA is the macro
security. Most corporate clients of my run Group Policy over their
networks to prohibit their staff from opening any files with macros
that are not in the Trust list. Addins don't suffer this anoying
inconvenience because they are handled by the Addins Manager and so do
not fall under macro security scrutiny.

--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc