R
Roger That
Hello,
I have a working VBA add-in for Excel that needs to support Excel versions
2000-2007. Since Excel 2007 makes use of a different menu system I will need
to create two different interfaces (one for Excel 2000-2003 and one for
2007). I would like to try to re-use as much code as possible and would like
to pack it into a VB6 DLL (for code security as well) and install that plus
the desired interface XLA/XLAM(?) based on which version of Excel the user
has.
I was wondering if there is anything that can't/shouldn't be moved from an
XLA to a DLL. Here is a list of some things the add-in currently performs:
- connects to a web service to get/send data
(strings/datasets/collections/etc)
- utilizes MSXML4 and Regular Expressions references
- displays user forms & performs various operations based on selections
- checks for the presence of 3rd-party add-ins
- populates cells with 3rd-party add-in automation calls
- makes use of the EventClassModule class and changes menu options
according to different events (greys out options when no worksheet open, etc)
- makes use of global CONSTS & some global variables
- writes data to log files
- stores user configurations in the XLA worksheets
I'm guessing at least that last list item will be reproduced in both XLA
and XLAM versions, but how much of the rest can be done in a VB6 DLL? I have
done some programming in VB6 but not in this manner. I have found some help
from this post:
http://www.microsoft.com/communitie...2c6ee77837e1&lang=en&cr=US&sloc=en-us&m=1&p=1
as well as browsing through "Professional Excel Development: The Definitive
Guide to Developing Applications Using Microsoft Excel and VBA" by Bullen,
Bovery, & Green
Thanks,
Roger
I have a working VBA add-in for Excel that needs to support Excel versions
2000-2007. Since Excel 2007 makes use of a different menu system I will need
to create two different interfaces (one for Excel 2000-2003 and one for
2007). I would like to try to re-use as much code as possible and would like
to pack it into a VB6 DLL (for code security as well) and install that plus
the desired interface XLA/XLAM(?) based on which version of Excel the user
has.
I was wondering if there is anything that can't/shouldn't be moved from an
XLA to a DLL. Here is a list of some things the add-in currently performs:
- connects to a web service to get/send data
(strings/datasets/collections/etc)
- utilizes MSXML4 and Regular Expressions references
- displays user forms & performs various operations based on selections
- checks for the presence of 3rd-party add-ins
- populates cells with 3rd-party add-in automation calls
- makes use of the EventClassModule class and changes menu options
according to different events (greys out options when no worksheet open, etc)
- makes use of global CONSTS & some global variables
- writes data to log files
- stores user configurations in the XLA worksheets
I'm guessing at least that last list item will be reproduced in both XLA
and XLAM versions, but how much of the rest can be done in a VB6 DLL? I have
done some programming in VB6 but not in this manner. I have found some help
from this post:
http://www.microsoft.com/communitie...2c6ee77837e1&lang=en&cr=US&sloc=en-us&m=1&p=1
as well as browsing through "Professional Excel Development: The Definitive
Guide to Developing Applications Using Microsoft Excel and VBA" by Bullen,
Bovery, & Green
Thanks,
Roger