[sc-dev] Re: [allsvn] r265030 - cws/ooxml02/offapi/com/sun/star/sheet

2008-12-08 Thread Niklas Nebel

On 12/08/08 19:34, [EMAIL PROTECTED] wrote:

Modified: cws/ooxml02/offapi/com/sun/star/sheet/FormulaLanguage.idl
==
--- cws/ooxml02/offapi/com/sun/star/sheet/FormulaLanguage.idl   Mon Dec  8 
18:33:06 2008(r265029)
+++ cws/ooxml02/offapi/com/sun/star/sheet/FormulaLanguage.idl   Mon Dec  8 
18:33:13 2008(r265030)
@@ -63,6 +63,11 @@
  */
 const long NATIVE   = 3;
 
+/** Function names and operators as used in the English version of 
+Excel.  This formula language is also used in VBA formulas and 
+OOXML import/export.

+ */
+const long XL_ENGLISH = 4;
 };


No, the map of Excel function names is supposed to be part of the Excel 
filter, and that's how the import already works.


Niklas

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [sc-dev] Re: [allsvn] r265030 - cws/ooxml02/offapi/com/sun/star/sheet

2008-12-08 Thread Niklas Nebel

On 12/08/08 20:17, Kohei Yoshida wrote:

On Mon, 2008-12-08 at 20:05 +0100, Niklas Nebel wrote:
No, the map of Excel function names is supposed to be part of the Excel 
filter, and that's how the import already works.


But what's the drawback?  Defining a formula language here makes it
easier to use in the filters as well as VBA formula parsing since it
fits nicely in the current grammar framework.  To me, not doing this
would be a kludge.


Again, modularization. We want to separate the Excel filter from the 
sc module, and opcode mapping is part of it.


Niklas

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [sc-dev] Re: [allsvn] r265030 - cws/ooxml02/offapi/com/sun/star/sheet

2008-12-08 Thread Kohei Yoshida
On Mon, 2008-12-08 at 20:43 +0100, Niklas Nebel wrote:
 On 12/08/08 20:17, Kohei Yoshida wrote:
  On Mon, 2008-12-08 at 20:05 +0100, Niklas Nebel wrote:
  No, the map of Excel function names is supposed to be part of the Excel 
  filter, and that's how the import already works.
  
  But what's the drawback?  Defining a formula language here makes it
  easier to use in the filters as well as VBA formula parsing since it
  fits nicely in the current grammar framework.  To me, not doing this
  would be a kludge.
 
 Again, modularization. We want to separate the Excel filter from the 
 sc module, and opcode mapping is part of it.

But VBA is not part of the filter, and we need that for VBA.  The filter
is merely re-using it.

There is a fine line between modularization and reusability.

Kohei



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[sc-dev] Copy/paste from Calc to writer

2008-12-08 Thread Alan Yaniger

Hi list-members,


Where is the code which creates the OLE object when I copy cells from a 
sheet and paste them into Writer?



Thanks,

Alan


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]