I am using Ron Debruin's menu system, which is working perfectly, to drive an
application I have developed and have a couple of questions from a
housekeeping perspective:

The forms and associated code I developed in my application to run the
various menu options must now reside in the add-in, is that correct?
The modules I developed in my application to run other components (not form
related) must now reside in the add-in, is that correct?
The sheets that hold the data must sit in the original worksheet, is that
correct?

If my assumptions are correct, then it means every time I do a system
update, I need to redistribute the add-in to all users and get them to copy
it to their local drive where their Addins are stored. If I could maintain
all the modules, forms, sheets and associated code in my original
spreadsheet, which is the one users access to run the system, it would be
much simpler to manage the updates as I store that file on a central server.

If all I had to do was manage Ron's QAT menu system, which will change very
infrequently, via the addin, updating the system would be a breeze.

Does anyone have any suggestions that might make things a bit simpler to
manage the updates?

Thanks in advance.

The thing to keep in mind that frankly speaking .xla and .xls aren't
that much different at all. The single biggest difference (some might
dissagree) is that tha add-ins aren't visible as Excel files in a
running Excel instance - but they all can be seen in the VBE.
But otherwise you can pretty much do the same things in either - you
can even have multiple sheets in the xla where the data are stored.
That wouldn't bee too convenient, though, as the data would be hidden
(as users can't see the xla tabs in the Excel - as per above) but the
data can be stored in the xla nevertheless.

Regarding your question on administering the updates - I do not think
there is any particular reason why the xla files need to be copied
onto the Users' local drives - whenver users add the add-in for the
first time - they don't need to copy it over - it can stay on the
central drive. Having added the xla from the central drive whenever
they start the Excel it will open also the xla file from the central
drive - for all but the first user it will be readonly. So, the only
thing that you'll need to manage will be the central file and making
sure you have edit access when you want to update it.


On Apr 26, 7:26*am, New2VB wrote:
I am using Ron Debruin's menu system, which is working perfectly, to drive an
application I have developed and have a couple of questions from a
housekeeping perspective:

The forms and associated code I developed in my application to run the
various menu options must now reside in the add-in, is that correct?
The modules I developed in my application to run other components (not form
related) must now reside in the add-in, is that correct?
The sheets that hold the data must sit in the original worksheet, is that
correct?

If my assumptions are correct, then it means every time I do a system
update, I need to redistribute the add-in to all users and get them to copy
it to their local drive where their Addins are stored. If I could maintain
all the modules, forms, sheets and associated code in my original
spreadsheet, which is the one users access to run the system, it would be
much simpler to manage the updates as I store that file on a central server.

If all I had to do was manage Ron's QAT menu system, which will change very
infrequently, via the addin, updating the system would be a breeze.

Does anyone have any suggestions that might make things a bit simpler to
manage the updates?

Thanks in advance.

"New2VB" wrote in message
...
I am using Ron Debruin's menu system, which is working perfectly, to drive
an
application I have developed and have a couple of questions from a
housekeeping perspective:

The forms and associated code I developed in my application to run the
various menu options must now reside in the add-in, is that correct?

Yes

The modules I developed in my application to run other components (not
form


Yes

related) must now reside in the add-in, is that correct?
The sheets that hold the data must sit in the original worksheet, is that
correct?


Yes

If my assumptions are correct, then it means every time I do a system
update, I need to redistribute the add-in to all users and get them to
copy
it to their local drive where their Addins are stored. If I could maintain
all the modules, forms, sheets and associated code in my original
spreadsheet, which is the one users access to run the system, it would be
much simpler to manage the updates as I store that file on a central
server.

If all I had to do was manage Ron's QAT menu system, which will change
very
infrequently, via the addin, updating the system would be a breeze.

Does anyone have any suggestions that might make things a bit simpler to
manage the updates?

The simplest way is to hold a master copy of the addin in a server location
that everyone can access. The addin would store the version number
somewhere, say in a worksheet cell. You would then have another (control)
file that could simply be a text file, and when your client addin starts it
reads that control file and checks the version number. If they are not the
same, advise the user to download the new version and install it - you can
give detailed instructions.

"AB" wrote in message
...

The thing to keep in mind that frankly speaking .xla and .xls aren't
that much different at all. The single biggest difference (some might
dissagree) is that tha add-ins aren't visible as Excel files in a
running Excel instance - but they all can be seen in the VBE.
But otherwise you can pretty much do the same things in either - you
can even have multiple sheets in the xla where the data are stored.
That wouldn't bee too convenient, though, as the data would be hidden
(as users can't see the xla tabs in the Excel - as per above) but the
data can be stored in the xla nevertheless.

Maybe, but holding the data in the same workbook as the code is not a good
design model, either xla or xls.