Some years ago, in the days of OOo1.0.x, I stumbled upon the different
sheet-separators in Excel and Calc. I created a named ref "shSep",
referring to string "!" and a VBA-macro that sets this ref to "." on
file close, so Calc can use the right separator with
INDIRECT(sheetName&shSep&"A1"). On open the VBA reset it to Excels "!".
This worked perfectly until I noticed that I don't need a macro at all:
shSep =MID(ADDRESS(1;1;1;"Foo");4;1) does the same job in both apps.
The lesson is: Calc keeps the VBA with REM in front of each line because
it is not usable in most cases. On save the original VBA is saved with
the document.
OK, next story: I tried the other way round. I recieved an
Excel-document with tons of VBA, protected through what MS calls
"password-protection". I opened the document, saw the VBA in the
StarBasic-IDE, added some lines (msgbox (varname)), copied the modules
into a text-editor, saved the document and loaded in Excel. The code did
not run and Excel crashed when I opened the VBA-IDE.
However, in Excel I could copy the document's content into a new
spreadsheet and copy the uncommented code into new VBA-modules in order
to get a new debuggable "Excel-project" (btw: it was horribly coded and
hardly used any spreadsheet-functionality).
The lesson is: MS can not handle edited (uncompiled) basic-code and most
likely MS will prevent that in future.
Saving StarBasic (uncompiled source) with MSFormats makes no sense.
If StarBasic gets real VBA-support some day, then it has to save the
pre-compiled macros in the same way as MSO does, otherwise it would be a
question of time until MS does something like:
If (Basic<>VBA){crash_App('File corruption due to bad macros')}
Sorry, this is going to be lenghty ;(
Well, the solution to your problem could be:
Save your code in container "My Macros", library "Standard" or in some
other library to be loaded automaticaly if the opened file belongs to a
certain project.
In the other thread you mentioned some spreadsheet-project,
demonstrating the capabilities of Calc. Go ahead! A clean design,
separating data from calculation and display of results, utilizing all
the bells and whistles of Calc can outperform many of those "Excel VBA
solutions". Avoid office-macros at any cost. They tend to be a trap.
They stop working when you change the application and they may stop
working when the application has changed. My first "VBA-project" did not
survive MSO95->MSO97. Same with some OOo1-stuff. If you need to add
functionality by macros, you either use the wrong application or you are
unaware of the application's builtin methods.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
