Andreas Saeger wrote:
T. J. Frazier wrote:
Andreas Saeger wrote:
You are using Excel as application development platform. ...
And why not? So do I. Stable, customizable, automatically
cross-platform, and free.
Excel is *what*?
My thought was incompletely expressed; /mea culpa/ :-(
I should have said, If you want to use Calc that way, why not?
Hopefully, the list of attributes would lead the reader to apply them to
the proper antecedent.
* Menus and XML
All the menus (and toolbars) in OO.o are kept in XML files. Interfaces
are available to customize these to any desired degree. Considerable
recent work has made this easier, for the benefit of extensions.
So you've got to rewrite every single line of VBA code.
Every line that deals with system interfaces? Most of them, yes.
* Extensions
You may want to investigate packaging your software as an extension.
That avoids license problems, and makes user installation very easy.
After your 2000 lines of VBA code changed to 3500 lines of StarBasic.
The quantity of new code required for a platform conversion is dependent
on the modularity of the system interface references. Very modular
(professional) code requires little expansion or rework.
* Incompatibilities
The OO.o Basic language is nearly 100% compatible with other Basic
variants. It is the Application Program Interface (API) elements that
are only partly compatible. The underlying models of OO.o are not, and
never were intended to be, compatible with Microsoft. To some extent,
the API tries to bridge this gap.
StarBasic is strictly procedural while talking to a 100% object oriented
API (and only that particular API). It has bugs, some of them severe. It
is slow. It comes with a tiny set of runtime functions.
/Seriatim:/
* Basic is a second-generation, procedural language. I classify VBA,
OO.o Basic, and (I presume) StarBasic alike, as procedural languages
with object-oriented features.
* A single, 100% object-oriented API is a major feature. The whole idea
is to let the programmer worry about only one interface -- UNO -- and
let UNO worry about the rest of the world. How well, and how
thoroughly, UNO does this are clearly matters of concern, and debatable.
* Bugs: Issuezilla lists 99 open issues for Basic, many of which are P4
and P5 enhancement requests; none are above P3. Personal priority
assessments of individual bugs may vary sharply from these official
assignments.
* Slow? It's an interpreted language. Slow as compared to what?
* Runtime functions: few programs, or programmers, use more than a small
subset of the available functions. Of course, they use /different/
subsets . . . One nice thing about OO.o is that there are a number of
routes to follow, to result in enhanced functionality, depending on the
time, effort, and skills one is willing to bring to bear on a particular
problem.
* Further reading
I commend to your attention the wiki page of the Documentation Project:
http://wiki.services.openoffice.org/wiki/Documentation
Small snippets of that documentation (corrections) are written by me.
And by me, and hundreds of others; all contributions greatly appreciated.
where you will find links to the Developer's Guide and the Basic
Programmer's Guide. You may wish to investigate Category:Extensions on
the wiki, as well.
HTH
I commend to your attention the big, old VBA solution linked in the top
post. It will run out some day or rewritten entirely but never converted
to some other spreadsheet application. Now it runs for every single
client. A rewrite for OOo gives how many additional clients?
That's a very good marketing question. How many potential clients run
(or would like to run) on other platforms? How many would be grateful
for the introduction to OO.o, and the reduced expenses that could follow?
--
/tj/
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
