Maximilian Odendahl wrote:
I really think a code rewrite inevitable if we want to keep OOo
competitive.
are you actually being serious? Certain parts definitely, but certainly
not everything.
He's just another spammer.
Frank Schoenheit, Sun Microsystems Germany wrote:
Ocke surely knows his ways around in the Base project, he joined the
Base team even 3 months earlier than I did, nearly 11 years ago. To me,
he is the canonical choice.
+1
-
R. Georgeson wrote:
Mind you I can't believe that wanting to stick a button on a spreadsheet which
is always accessible as you scroll around is so ideosyncratic.
Where have I seen this before? Oh, in OpenOffice.org. It's called toolbar.
ODF is the the only relevant free and open feature. Any of your
programs can generate perfectly valid office documents with a similar
feature set as in MS Office, usable with many different applications.
Translating a typical VBA solution to something equivalent in
Basic/Python/Java requires
Lance Phillips at Owl Software wrote:
To whom it may concern,
I build an application for the food industry that uses Microsoft Excel.
It is used by food companies all over the world. I'm really fed up with
Microsoft. I'm wondering if I could do the same with OpenOffice. My
application uses
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*?
* Menus and XML
All the menus (and toolbars) in OO.o are kept in XML files
Cassio Neri wrote:
One intention (among others) of my previous messages was to propose a
solution for our major problem. By doing so, OOo Calc will make one
step to become a viable option for very important applications we have
in financial markets. I'm very sorry to say that currently only
Björn Michaelsen wrote:
There is absolutely no reason for this ad-hominem. Financial markets
are generally a very conservative business: There are enough fake
arguments being thrown around to prevent adoption of open solutions.
This is why I find it really delightful that Cassio Neri takes his
Björn Michaelsen wrote:
Am Wed, 18 Nov 2009 23:12:43 +0100
schrieb Andreas Saeger saege...@onlinehome.de:
[...]
Nobody has ever been fired for using Microsoft (and the money remains
on the right side of the fence).
Thats totally offtopic here on d...@openoffice.org.
Best Regards,
Bjoern
Just like in Excel, when automatic calculation is off, F9 calculates all
dirty cells which would have been calculated if automatic calculation
had been on. A dirty cell has a formula which depends on a modified
input argument.
Ctrl+Shift+F9 recalculates all cells in the whole document. Same as
Eike Rathke wrote:
In a spreadsheet, all operations apply to the current cell if no cell is
selected, the selection returned in this case is the current cell, even
if it isn't visibly marked. The difference is only in rendering or for
user interaction such as starting dragdrop vs. extending
Ariel Constenla-Haile wrote:
According to
http://api.openoffice.org/servlets/ReadMsg?listName=devmsgNo=6496 (from
2003 but still applies)
the interface was designed for an OOo/SO
running on a server where the printers are connected at the client.
Thus. for printing the client is a print
Cor Nouws wrote:
Hmm, now I remember another thing I missed: finding the available
printers through API, as they can be found in File|PrintSetup.
I guess that another service is, or should be, involved.
Cor
Hi Cor,
Try c.s.s.awt.XPrinterServer.getPrinterNames()
Eike Rathke wrote:
Both return the same ISO date-string of a number in A1.
Can I take English format codes for granted with all locales?
Yes, for the TEXT function English date format codes do work with all
locales.
Sorry, I found an inconsistancy with this feature:
=TEXT(A1;-MM-DD)
Hi,
It's me again.
Andreas Saeger wrote:
Eike Rathke wrote:
Both return the same ISO date-string of a number in A1.
Can I take English format codes for granted with all locales?
Yes, for the TEXT function English date format codes do work with all
locales.
Sorry, I found an inconsistancy
Using a German user interface of OOo 2.3.1 by Sun under Linux I can get
a format string from German number format code
=TEXT($A$1;-MM-TT)
as well as from English number format code
=TEXT($A$1;-MM-DD)
Both return the same ISO date-string of a number in A1.
Can I take English format codes
Niklas Nebel wrote:
That third option is enabled if you have an implementation of the UNO
service com.sun.star.sheet.DataPilotSource, for example from an
extension. It's then up to that extension to provide the results. It
could use an OLAP server, but I'm not aware of an extension that
You definitively want this:
http://www.ooomacros.org/dev.php#101416
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Matthias B. wrote:
On 11/16/06, Andreas Saeger [EMAIL PROTECTED] wrote:
[...]
oDocLibs = oDoc.BasicLibraries
oLib = oDocLibs.createLibrary(testLib)
[...]
Does this help?
Thanks. I'm trying to do this from Java. I've checked the IDL docs and
it seems that createLibrary() is provided
Forgot:
If everything fails, you may consider a Basic-macro to be called from
your Java with appropriate parameters. Add some arguments,
error-handling and
If oDocLibs.hasByName(sLibName) then ...
If oLib.hasbyName(sModuleName) then ...
to my code.
Matthias B. wrote:
Hallo, I've checked the Dev Guide and the IDL docs but I can't seem to
find any services/interfaces that allow me to create/edit Basic
scripts included in a document via the UNO API. It would be nice if
someone could point me in the right direction.
Matthias
Hi, Matthias
21 matches
Mail list logo
