Re: [sc-dev] WIKI: Extended description about Excel import/export of spreadsheet functions
Am 14.12.2010 16:31, schrieb Marina Plakalovic: Tnx, Daniel. I needed that one. :) If there are questions, if you find mistakes, etc... please just write here. Daniel - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] DEV300m84 hangs when saving from Calc
Hi Regina, Am 08.08.2010 19:12, schrieb Regina Henschel: I have build DEV300m84 on WinXP. That works so far, but saving a spreadsheet document from Calc gives always the Debug Output: Error: wrong NameAccess From File C:/DEV300m84my/xmloff/source/core/SettingsExportHelper.cxx at Line 406 If I ignore it, the file is saved, but OOo does not react on mouse or key. I have to kill it with task manager. Is this a special problem of my build? Is there something to avoid the problem? It is very annoying when testing my changes. I'll have a look. Daniel - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Include file error
rashi dhing schrieb: This is probably a very basic question but I am getting a compile error while trying to include the interpre.hxx in my module which happens to be located in a new directory in the sc/source/ui path. How can I resolve this ? There are several existing locations for header files: sc/inc for usage in entire sc sc/source/core/inc for headers local to core sc/source/ui/inc for headers local to ui sc/source/filter/inc for headers local to filter Also, headers will be searched in the current directory, so, if you have abc.hxx and abc.cxx files in the same directory, and in abc.cxx there is code like #include abc.hxx the header file should be found too. How do you include the header file? Regards Daniel - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] character set is not UTF-8 in analysis_deffuncnames.src
Regina Henschel schrieb: Hi all, I see ANSI character set and not UTF-8 in scaddins/source/analysis/analysis_deffuncnames.src. Is that an error or purpose? I see. I have no idea how to tell rsc which encoding to use, or if that is fixed to ANSI (which would be a bug of course). Will try if german umlauts still work. Anyway, the really best fix would be to generate these string lists from the translated resources, so we would have all available languages in the lists, not just en and de. Daniel - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hi,
Regina Henschel schrieb:
I have now used in analysis_deffuncnames.src an entry:
StringArray ANALYSIS_DEFFUNCNAME_Imcot
{
ItemList =
{
_xlfnodf.IMCOT; ;
_xlfnodf.IMCOT; ;
};
};
And for comparison an entry
StringArray ANALYSIS_DEFFUNCNAME_Imcsc
{
ItemList =
{
IMCSC; ;
IMCSC; ;
};
};
This are the results, all in setting ODF 1.2 and always saving to xls
format:
As far as I can see in the binary of the file, the function name is
stored as _xlfnodf.IMCOT and IMCSC respectively. The order of that
function names is: addin functions, named references, core functions.
(1) Opening and saving in Excel, then reopening in my build: All
functions are recognized correctly. It makes no difference using prefix
_xlfnodf. or not.
Good, I expected that :)
(2) Opening and saving in OOo2.4.3, then reopening in my build: In
OOo2.4.3 the unknown core functions are marked as #MACRO?, the unknown
addin functions as #ADDIN? Reopening in my build the core functions are
recognized, the addin functions are not recognizes and marked as #MACRO?
Here too, it makes no difference using prefix _xlfnodf. or not.
As the add-in implementation of OOo 2.4.3 does not know about these
functions, the Excel filter cannot handle them (e.g. it does not get
them from GetExcelName()).
(3) Opening and saving in Gnumeric, then reopening in my build: All
functions with prefix _xlfnodf are not recognized, the addin functions
without prefix are recognized. Reopening in my build all core functions
are recognized, the addin functions without prefix are recognized, the
addin functions with prefix are not recognized.
Would be interesting how Gnumeric saves the _xlfnodf functions.
I have introduced the _xlfnodf prefix for Calc-internal functions
unknown to Excel to prevent name clashes with e.g. Basic macros that
have the same name. Excel keeps the function names (but cannot work with
them of course) and writes them out exactly as it has read them, so the
import filter can convert back the name _xlfnodf.XYZ to the internal
function XYZ.
I think, in this case you can remove the prefix, because we have add-in
functions, and not core functions. In the XLS format, the add-in
functions are written into their own namespace and therefore cannot be
mixed up with Basic macro calls.
Regards
Daniel
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hi Regina, Regina Henschel schrieb: If I use ocExternal the prefix is set, but the functions are not distinct, only one name is written and on import the whole function name is stripped, so only =(z) remains from =_xlfnodf.IMSECH(z). I see no way to add the imaginary functions to list saFuncTable_Odf, because they have no op-code. Do I understand you right, that I should try to add the prefix in function GetExcelName in /sc/.../addincol.cxx? Yes, that was the idea, sort of. Sorry, I was not clear enough about this. In my eyes, the solution is to not touch the _Odf table, but to add the functions into the resource files in scaddins that are used for the XCompatibilityNames implementation. This would be in scaddins/source/analysis/analysis_deffuncnames.src. These strings are returned by the GetExcelName() functions of the addin collection. Regards Daniel - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hello,
Regina Henschel schrieb:
Daniel Rentz schrieb:
Right, fix has been integrated into m77
http://qa.openoffice.org/issues/show_bug.cgi?id=79854
Now I have a build based on m78. I made some import/export tests.
Excel2003 xml is totally broken (issue 94261) and not mentioned below.
Yes, that filter is not in a good state.
== A ==
I have added SEC, CSC, SECH, and CSCH, to saFuncTable_Odf. All four new
functions have op-codes. Tests look good:
Reloading directly is correct for ods, xls, sdc, and sxc.
Loading and resaving with StarOffice8 (for ods, sdc, and sxc) and
Excel2010 (for xls) and then loading in my build is correct too.
Good! Did you add them to the sc and oox modules?
== B ==
But I have still questions concerning the new imaginary functions. Those
functions have no op-code. Need I to add them to saFuncTable_Odf? If
yes, how can I do it?
Yes, the filters in sc are used for import/export of the XLS format. On
export, the current behaviour is:
If the function is an add-in function, the XCompatibilityNames interface
is used to retrieve its name used in the XLS file format (see in file
sc/source/filter/excel/xeformula.cxx, in function
XclExpFmlaCompImpl::AppendAddInCallToken(), call to GetExcelName()). So
I would suggest that this interface returns the _xlfnodf.XYZ function
names, to not get any name clashes with existing functions in Excel. The
import filter will try to convert these function names back to add-in
functions, again with the mentioned interface. But I do not know if this
will work out of the box. In file sc/source/filter/excel/xiroot.cxx,
there is a function XclImpRoot::GetScAddInName() that calls
GetCalcName() if you want to debug it.
I tried to add them to saFuncTableOdf in oox/source/xls/formulabase.cxx,
but does not know, which values to use for eighth and ninth parameter. I
have tried all combination of {RR},{VR} and FUNCFLAG_EXTERNAL,
FUNCFLAG_MACROCALLODF. But it has no effect on my test results.
Currently, the filters in the oox modules are only used to import XLSX
and XLSB file format. As we cannot export to these formats, the new
functions should not appear in these files. (It is planned to move the
old filters from sc to oox, but this is not finished yet.) So, it is
more important to add them to the sc filters.
To answer the question:
- 8th parameter: The token class codes RR, VR, etc. are important for
the function parameters, to let Excel distinguish reference, array, and
value parameters. They do not affect how the function itself is handled.
If you have regular value parameters, the code VR is sufficient in
most cases.
- 9th parameter: Special flags. Are used to trigger some special
behaviour in the filters. All functions unknown by Excel should get the
FUNCFLAG_MACROCALLODF flag. This will cause the import filter to convert
the function _xlfnodf.FUNCNAME to FUNCNAME.
The test results are:
== B1 Directly reloading ==
Correct with general setting 'ODF 1.0' in ods, sdc, sxc, and xls
Correct with general setting 'ODF 1.2 extended' in ods, sdc, and xls. It
fails for sxc (issue 95312).
== B2 Opening and resaving in StarOffice8 and Excel2010, reloading in my
build ==
Correct with general setting 'ODF 1.0' in xls, sdc, and sxc.
Correct with general setting 'ODF 1.2 extended' in xls and sdc.
In the cases
'ODF 1.0' with ods and
'ODF 1.2 extended' with sxc and ods,
the new functions are reloaded with #NAME?, but the cells contain the
formulas like '=imsech(z)'.
In contrast to issue 95312 the old imaginary functions are handled
correctly in this round trip through StarOffice8 and Excel2010
respectively.
Cannot say about the ODF filter, Eike should know better.
Do I miss something, or is that a general error with 'new' addin-functions?
Please have a look at issue 101386. Is it the same problem?
Again, something for Eike.
Regards
Daniel
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Regina Henschel schrieb: Hi Daniel, Daniel Rentz schrieb: Same for the equivalent table saFuncTable_Odf in sc/source/filter/excel/xlformula.cxx. It seems, that I have to wait till m78, because m76 does not contain saFuncTable_Odf and m77 does not build for me. Right, fix has been integrated into m77 http://qa.openoffice.org/issues/show_bug.cgi?id=79854 Daniel - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Debug the Calc Source Code
rashi dhing schrieb: I started building the sc module with debug=true but now I am getting the following error: ../wntmsci12.pro/bin/scuimi.dll : fatal error LNK1169 : one or more multiply defined symbols found. dmake: Error code 2, while making ' ../wntmsci12.pro/bin/scuimi.dll I came across a similar issue from the mail archives: http://www.mail-archive.com/d...@openoffice.org/msg12074.html That is exactly the issue that Niklas has mentioned in his previous posting. It does not work do compile the entire sc with debug. quote In fact, until CWS dr73 is integrated, building the complete sc module with debug info will fail, see issue 100534. /quote Until this fix will be integrated (one of the next milestones), please do the following: 1) Compile the sc module without debug. cd sc build killobj build 2) Build the files you are interested in with debug. touch source/ui//cxx build debug=t 3) Do not forget to copy the new DLLs into your OOo installation. Regards Daniel - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Functions in Excel 2010
Regina Henschel schrieb: I have started a new Wiki page http://wiki.services.openoffice.org/wiki/Calc/Drafts/Treatment_of_new_Excel_2010_functions Note that the functions are not renamed (as one may read on th Wiki), but that the old functions with the old names still exist. Daniel - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] 65,000 lines on calc
Alexandro Colorado schrieb: when did OOo Calc (what version #) get past the 65,000 limit on spreadsheets? It was the 32,000 row limit (now there are 65,536 rows available), and the feature announcement was in May 2004: http://sc.openoffice.org/servlets/ReadMsg?list=featuresmsgNo=157 (hmm, the mail is HTML...) So this has been gone into OOo 2.0, released in October 2005. Regards Daniel - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Missing second parameter in CEILING
Regina Henschel schrieb: Hi Daniel, I do not answer directly, because it seems that I described my concern not good enough. Next try: == Import == Importing an Excel-file with =CEILING(-3.4;) for example gives the cellcontent =CEILING(-3.4;;1), because in the current import filter the third parameter 1 is added to get Excels rounding away from zero behavior. This will be a valid formula in ODF1.2 and calculated as CEILING(-3.4;-1;1)= -4. But the formula =CEILING(-3.4;) gives the result 0 in Excel. Therefore I think, that it would be better, to import the formula as =CEILING(-3.4;0;1) which gives 0 in OOo too according to spec ODF1.2. The other problematic import case is Excels formula =CEILING(;value). In this case it becomes =CEILING(;value;1), which is an invalid formula in ODF1.2. Here too the result in Excel is 0, and an import as =CEILING(0;value;1) would give the same result as in Excel. This is true for the Excel formats xls, xlsx and xlsb. The import filter for xml does not alter the Excel formulas and so the formulas in the cells are invalid according to ODF1.2. But it could be solved the same way with =CEILING(0;value;1) and =CEILING(value;0;1) respectively. Change the import filter? Understood and agreed. This can be added in the import filters. I think it should be then: - If 1st param empty, replace with 0 - If 2nd param empty, replace with 0 - Add 3rd default param == Export == When the formula in OOo is =CEILING(3.4;;Mode) it is exported to =CEILING(3.4;) which results in 0 in Excel. But in OOo the formula results in 4. If the formula is exported as =CEILING(3.4;1) it would give the correct result in EXCEL. But for =CEILING(-3.4;;0) in OOo, which results in -3, the current export is =CEILING(-3.4;) which result in 0 in Excel which is wrong, but the export to =CEILING(-3.4;1) gives an invalid formula and =CEILING(-3.4;-1) would result in -4 in Excel, which is wrong too. When the formula in OOo is =CEILING(3.4) it is calculated as CEILING(3.4;1;0)=4. An export as =CEILING(3.4;1) would give correct values in Excel. But =CEILING(-3.4) is calculated as CEILING(-3.4;-1;0)=-3 and CEILING(-3.4;1) is invalid again and CEILING(-3.4;-1) result in -4 in Excel, which is wrong. I see no way to make a general export, that gives the same value in Excel as in OOo by simply setting or dropping parameters. So what to do in export? Hmm, I see. So the second parameter has to be set according to the current value of the first. No idea how to fix this easily... Daniel - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Missing second parameter in CEILING
Moin, Regina Henschel schrieb: Ah, IsMissing() is new to me. I can now set the missing second parameter to +1 or -1 depending on N. That works at least for CEILING on which I'm currently working. But Excel Import and Export is confusing. (1) Import: In cases CEILING(value;) and CEILING(;value) the result in Excel2007 is always 0. On import of CEILING(value;) OOo does this: .xlsturn to CEILING(value;;1) and show cell content 0. .xlsxturn to CEILING(value;;1) too, but show cell content Err:511 .xmlturn to CEILING(value;) and show cell content Err:511 Well that indicates that the formula parser in Calc does not handle the missing parameter correctly and does not create the svMissing formula token. The binary filter (.xls format) inserts that token for its own. You may also try the Excel 2007 .xlsb format, that should work too (it does build the token array for its own too). On import of CEILING(;value) OOo does this: .xlsturn to CEILING(;value;1) and show cell content 0. .xlsxturn to CEILING(;value;1) too, but show cell content Err:511 .xmlturn to CEILING(;value) and show cell content Err:511 The same I think. XML based filters (.ods, .xlsx) use the internal formula parser that forgets to insert the svMissing token. I could fix that for the .xlsx format when postprocessing the formula, but that would not be of any help for the .ods import. The errors are shown left as if they are text. The cell content is only recalculated, if you edit the cell, but that is another issue. Because Excel returns 0 in this cases, I think an import to CEILING(value;0) and CEILING(0;value) would be a better solution. Although I not yet know how to do it. (2) Export: Currently OOo drops the third parameter. So the value differs from Excel in the cases of (N0 and Mode=0). When now the second parameter it optional too, how should it be exported? Using +1 gives the same result as in OOo for all cases but (N0 and Mode=0). So I would prefer that. Gnumeric goes a total different way. It generates a new expression to simulate the behavior with it's two parameter version of CEILING. You can see it, when you open an ods-file in Gnumeric. For example CEILING(A2;B2;C2) becomes =if(0=C2;if(A20;floor(A2;B2);ceiling(A2;B2));ceiling(A2;B2)) What is the desired behavior on import from Excel and export to Excel? In my eyes, binary filters work as expected, and XML based filters need to be adjusted. Daniel - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Re: MS Excel file encryption feature contribution to OO.o
Hello, Kohei Yoshida schrieb: Great! BTW, the new security framework would probably affect the password input UI part, but should not affect anything else IMO. Btw, I am interested in the pw input UI stuff to add it to the ooxml filter. Do you have a pointer for me? Regards Daniel - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] The Excel import/export part of i35579.
maoyg schrieb: Hi,Daniel I am working the issue 35579 with lvyue, and now I come to the Excel import/export part. the Excel has some options,I have added some change,for example, excdefs.hxx added comparison operands, the XclImpAutoFilterData::ReadAutoFilter() method in excimp8.cxx added some codes, lcl_GetOperator() method in excrecds.cxx, XclExpAutofilter::AddEntry() method in excrecds.cxx, when the calc saved test.xls, this option still can't be saved, but I don't know much about that, can you give me more details? :) thanks! Hello, I am not familiar with your changes (and IssueZilla seems to lag currently), which settings did you add to the AutoFilter in Calc? Daniel - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] How to export expanded LOGNORMDIST to Excel
Eike Rathke schrieb: Hi Regina, On Tuesday, 2009-03-17 18:04:12 +0100, Regina Henschel wrote: But export to Microsoft Excel 2003 XML (.xml) is problematic. If OOo is set to save in odf1.2, the file opens with errors in Excel. All formulae are stripped. The error log says for example GRUND: Ungültiger Wert WERT: of:=LOGNORMDIST(0.6;[.B12];[.B11]) I think, there should not be this kind of WERT, because that form was unkown 2003. That's http://qa.openoffice.org/issues/show_bug.cgi?id=96018 We should consider to drop that filter completely... Daniel - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] How to export expanded LOGNORMDIST to Excel
Regina Henschel schrieb: Hi Eike, hi Daniel, Regina Henschel schrieb: No more questions for now, I'll continue my tests. Thanks for your help. Now all works as it should and I'm going to create patches. And have got the next problem. For the file token.cxx in formula/source/core/api I get an odd patch. The patch includes the function FormulaMissingContext::AddMissingExternal( FormulaTokenArray *pNewArr ) although there is nothing changed. (starting around line 1007) As far as I see, there are DOS line ends in that part. My editor PSPad autodetects DOS mode for this file. Having only UNIX line ends, it autodetects UNIX correctly. What to do? Remove the lines from the patch? Or use the patch as it is generated? I suggest to remove these lines from the patch. As far as I know the wrong DOS line ends have been replaced in another CWS already. Note that all files should contain Unix lineends only, so if possible please configure your editor to always use them (and not to auto-detect DOS). Daniel - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] How to export expanded LOGNORMDIST to Excel
Regina Henschel schrieb: Hi Daniel, That works. When exporting to xls, I get the correct function structure, if there are one, two or three parameters in OOo. If there are four parameters in OOo, I get a =#NV entry in German Excel 2007. I think, the error message is correct, because the user has to know, that there has been something, which is unknown to Excel. It is a concession that the missing parameters are added, although the user who will export to Excel-format should know, that Excel expects three parameters. Shouldn't we do the same for saving in old OOo formats, especially, when OOo3.0 is set in general to use ODF1.0-format? If you agree, that in cases saving to old OOo-formats the missing second and third parameters should be added, where is the place to do it? I don't know the code that exports to ODF, Eike should know more. To delete the 4th parameter, you can change the function info of this function. Go to xlformula.cxx and look for ocLogNormDist, change the ... I have done first the changes in formulabase.cxx. That gives no error, but I see no effect, so I cannot say if it really works. Then I changed xlformula.cxx. That works, now the entry in the xls-file has three parameters in all cases. Yes, formulabase.cxx is currently used for import from XLSX/XLSB format only, not export, so that does not have any effect on the XLS export filter. It is just a good idea to change both files equally to be prepared for the future where formulabase.cxx might be used for import/export of the XLS format too. The oox code module already contains a nearly complete XLS import filter that is intended to replace the old filter code from the sc module sometimes. I have rethought the problem. It seems no good idea to strip the fourth parameter. If it is stripped, there are no errors in Excel, but the cells might have different values than OOo, because in OOo you calculate the density function and in Excel the cumulative function is calculated. The user cannot notice, that the values are wrong, because there are no warnings. That is not good and we should not do it. There is no way to determine whether the forth parameter is true or false, because it might be no constant but a reference. The same problem is, when saving to old OOo-formats. Using four parameters should give an error, when opening in old versions. Of course this is something that has to be decided before. There are functions where stripping a parameter unknown to Excel is desired, otherwise this might be not a good idea for other functions. Currently, the only way to warn the user is to write #NA instead of the (wrong) function argument list, so this is a valid option. Again, Eike, what do you think? Daniel - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] How to export expanded LOGNORMDIST to Excel
Hi again,
Daniel Rentz schrieb:
To delete the 4th parameter, you can change the function info of this
function. Go to xlformula.cxx and look for ocLogNormDist, change the
line from
{ ocLogNormDist,290,3, 3, V, { V }, 0, 0 },
to
{ ocLogNormDist,290,3, 3, V, { V, V, V, C, I }, 0, 0 },
The C means that the 4th parameter is Calc-only and will be stripped
on export. The trailing I is needed for some internal resons.
Note that I am not sure that this works out of the box (adding and
deleting parameters for the same function), if not, we have to look a
bit deeper. Please change the function info in the oox module too, this
code might be used in the near/far future to export functions:
oox/source/xls/formulabase.cxx, look for LOGNORMDIST (line 498 here).
Nowadays, that table is used for XLSX/XLSB import only, so no other
changes are needed.
Regards
Daniel
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Re: [allsvn] r265030 - cws/ooxml02/offapi/com/sun/star/sheet
Kohei Yoshida schrieb: Hi Eike, On Tue, 2008-12-09 at 20:41 +0100, Eike Rathke wrote: If there isn't any, wouldn't it be natural to share the filter's name mapping with VBA? Absolutely, and that's what I envisioned too. What we seem to disagree is where to keep the shared filter name mapping instance. For me, it seemed natural to keep it with ScCompiler, the same way we keep the various address convention code within that class, and have it shared by xls import/export filters and VBA parser. But you prefer the opcode mapping outside the core, in oox. That would work fine for the filters (once the export filter moves to oox). But once VBA gets into the mix, it becomes a little ugly since the VBA code is still in sc. It may not be enough to add a mapping in the sc core. In oox there is some postprocessing code executed for each formula which takes care of e.g. missing/unsupported function parameters, add-in/external function handling etc. Would it be an option that the oox module offers the xl formula parser as a special UNO service that implements the com.sun.star.sheet.XFormulaParser interface? So it would be possible for any module to instanciate and use such a parser. Let's say we agree to keep the opcode mapping outside the core (after all, it's already done). But the problem, at least in the short-term, is to 1) refactor VBA to use the FormulaParser API instead of using ScCompiler directly (like it does now). 2) move the xls opcode mapping out of oox to a place where it can be accessed both from oox and sc. I want to keep all filter related stuff in one module, so I think my idea using a service may be a bit better ;-) Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] module dep fix code shrink ...
Hi, Michael Meeks schrieb: I just committed a chunk of code to the ooxml02 CWS. This extends the visibility markup to the classes we use during import and export: which turned out to be fewer symbols than I had feared (10k vs. 9k symbols), and splits out all of the calc filters (except for xml) into a separate library: 'scfilt' which is demand loaded via an abstract interface. Looks much better, thanks. In addition - I noticed fixed a number of problem symbols. The CWS tune03 seems (some time ago) to have publicly exposed a number of things without Sc prefixing that could be problematic in future: eg. 'Collection' 'StrCollection'. I added an Sc prefix to: ColToAlpha, Collection, SortedCollection, StrCollection, TypedStrCollection, AutoFmtPreview, DataObject and SingleRefData - hopefully that will avoid symbol clash problems in future. for consistency with SingleRefData, you may also change ComplexRefData. Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sc-dev] CWS ooxml02: some comments
Hello all some thoughts and questions about CWS ooxml02: 1) I noticed that you changed filter names and file type names in the configuration (module filter). This is not a good idea as these names can be considered public API. These strings may be used in macros and other programs to use a specific filter for loading/saving a file. So, changing the names may break existing macros, even if the new names may look more consistent. I decided to start a new naming scheme for the OOXML filters after some chat with other collegues, so there is a meaning behind the new names. The leading application name before the filter name (e.g. Calc MS Excel 2007 XML) denotes that the filter is part of the application Calc, while the missing application name before the file type name (e.g. MS Excel 2007 XML) denotes something existing outside OOo, namely the XML file format invented by MS. I would like to change all old filter/type names but cannot do this for the same reason as above... 2) What is the new STREAM_FOR_OUTPUT for, that is added besides the OUTPUT_STREAM in the media descriptor? Additionally all XOutputStream's in oox/core have been changed to XStream. Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] *.xls import: formula =Cell(Zeile) is broken
Oliver Brinzing schrieb: Hi, just recieved an excel file with a formula like this: =DATUM($G$1;MONAT(A$3);((ZELLE(ZEILE;A4))-3)) OO displays Err:502, cause the argument Zeile should be row ... is it possible to fix the import or localize the arguments ? Instead of using ZELLE(ZEILE;A4) one could use ZEILE(A4). That works in Calc and Excel. There will always be problems with these dumb localized arguments and other stuff (e.g. add-in function names) in Excel. An English Excel does not understand the German function names as well and shows an error, while all localized Excel versions understand the English names. It has been decided that OOo only supports the English names. Of course one could think about extending this, but that would be a lot of effort for low benefit... Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] The Excel import/export part of EUROCONVERT().
Daniel Rentz schrieb: lvyue schrieb: Hi Daniel, I made the changes you suggested, but it doesn't work. it is still =NA() I'm tracing the code, but I didn't get any clue yet. If you have findings, please tell me, thank you. Try to find where compiling the formula breaks. The N/A error is an indicator for an error while creating the formula. Then the result is dropped, and the N/A error is written instead, to prevent broken formulas that would confuse (and may crash) Excel. To correctly create the formula, the following places have to be reached. The member mbOk tracks the validity of the created formula. It has to remain true all the time. otherwise there is an error somewhere. ** XclExpFmlaCompImpl::CreateFormula The entry point. ** XclExpFmlaCompImpl::Expression Starts compiling the entire expression. ** XclExpFmlaCompImpl::ProcessFunction Processes the ocEuroConvert token. The call to maFuncProv.GetFuncInfoFromOpCode( eOpCode ) should return the function info for the EUROCONVERT function, check pFuncInfo. A few lines below, the code if( pFuncInfo-IsMacroFunc() ) aExtFuncData.Set( pFuncInfo-GetMacroFuncName(), false, true ); should be executed and should write the function name EUROCONVERT into the aExtFuncData struct. ** XclExpFmlaCompImpl::ProcessParam Starts processing the first parameter of the EUROCONVERT function. Here, the filter should find that extra processing is needed for EUROCONVERT (due to the EXC_FUNC_PAR_EXCELONLY flag) and should call... ** XclExpFmlaCompImpl::AppendDefaultParam Should call your new AppendEuroToolToken() which should execute without error (mbOk should be true afterwards). Check that the \001\010EUTOTOOL.XLA link is created correctly (it should because it already exists in the test file you sent me) :-) Forgot one: ** XclExpFmlaCompImpl::FinishFunction check that the parameter count is handled correctly. nParamCount should contain the value 4, if the EUROCONVERT function has 3 parameters. nXclFuncIdx should contain 255. The else part with the comment variable number of parameters should be executed. ** XclExpFmlaCompImpl::FinalizeFormula Creates the N/A on any error (if mbOk is false). Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sun Microsystems GmbH Nagelsweg 55 20097 Hamburg Germany Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] The Excel import/export part of EUROCONVERT().
lvyue schrieb: Hi Daniel, I made the changes you suggested, but it doesn't work. it is still =NA() I'm tracing the code, but I didn't get any clue yet. If you have findings, please tell me, thank you. Try to find where compiling the formula breaks. The N/A error is an indicator for an error while creating the formula. Then the result is dropped, and the N/A error is written instead, to prevent broken formulas that would confuse (and may crash) Excel. To correctly create the formula, the following places have to be reached. The member mbOk tracks the validity of the created formula. It has to remain true all the time. otherwise there is an error somewhere. ** XclExpFmlaCompImpl::CreateFormula The entry point. ** XclExpFmlaCompImpl::Expression Starts compiling the entire expression. ** XclExpFmlaCompImpl::ProcessFunction Processes the ocEuroConvert token. The call to maFuncProv.GetFuncInfoFromOpCode( eOpCode ) should return the function info for the EUROCONVERT function, check pFuncInfo. A few lines below, the code if( pFuncInfo-IsMacroFunc() ) aExtFuncData.Set( pFuncInfo-GetMacroFuncName(), false, true ); should be executed and should write the function name EUROCONVERT into the aExtFuncData struct. ** XclExpFmlaCompImpl::ProcessParam Starts processing the first parameter of the EUROCONVERT function. Here, the filter should find that extra processing is needed for EUROCONVERT (due to the EXC_FUNC_PAR_EXCELONLY flag) and should call... ** XclExpFmlaCompImpl::AppendDefaultParam Should call your new AppendEuroToolToken() which should execute without error (mbOk should be true afterwards). Check that the \001\010EUTOTOOL.XLA link is created correctly (it should because it already exists in the test file you sent me) :-) ** XclExpFmlaCompImpl::FinalizeFormula Creates the N/A on any error (if mbOk is false). Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sc-dev] Application modules become dependent from module oox?
Hello, with some surprise I have seen hundrets of check ins in the CWS ooxml02 with the goal to implement OOXML export filters. For Calc this seems to be done by extending the binary BIFF export filter. As it looks this makes it necessary to export headers from and linking against oox thus making the sc module dependent from oox. I wonder if this design decision with such an impact has been discussed somewhere before. The oox module has been started to be independent from most modules to make the entire office a bit more modular. Remember all the rants from users and developers about the monolithic office we currently have. Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Application modules become dependent from module oox?
Jonathan Pryor schrieb: On Fri, 2008-11-21 at 11:57 +0100, Daniel Rentz wrote: with some surprise I have seen hundrets of check ins in the CWS ooxml02 with the goal to implement OOXML export filters. For Calc this seems to be done by extending the binary BIFF export filter. As it looks this makes it necessary to export headers from and linking against oox thus making the sc module dependent from oox. I wonder if this design decision with such an impact has been discussed somewhere before. It wasn't actually discussed at all, and no thought went into it; it was the easiest thing to do. The oox module has been started to be independent from most modules to make the entire office a bit more modular. Understood. So, what's the solution to this? In particular, a reasonably fast solution as I'd like to get this merged for OpenOffice.org 3.1. :-) I see the following solutions: 1. Leave the dependency, merge ooxml02 for 3.1, and work to remove it for 3.2+. 2. Split out oox's XmlFilterBase dependent types into a helper library (or perhaps use comphelper?), and depend on this helper library from both sc oox. 3. Implement BIFF/OOXML export within oox. (1) is obviously the easiest, requiring no immediate work, and the work to remove it for 3.2+ could be (2) or (3). I'm not sure how feasible (2) actually is -- it looks doable, but I'm not sure what hidden issues will show up, nor what library it would be appropriate to move FilterBase, XmlFilterBase, ZipStorage, etc. into. Cursory discussions suggest that comphelper may be a good destination, as sc already indirectly depends upon comphelper, so it's not really adding anything that wasn't there before. I don't like (2). I think best thing is to do (1), and think about (3) for 3.x as you suggested. (3) isn't really viable, not short term, though I understand that the long term plan is to obsolete sc/source/filter/excel in favor of using oox for saving .xls files. Ok. So, as it is now means there is less potential for source code conflicts while working on import (me) and export (you) :-) Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Application modules become dependent from module oox?
Daniel Rentz schrieb: Jonathan Pryor schrieb: On Fri, 2008-11-21 at 11:57 +0100, Daniel Rentz wrote: with some surprise I have seen hundrets of check ins in the CWS ooxml02 with the goal to implement OOXML export filters. For Calc this seems to be done by extending the binary BIFF export filter. As it looks this makes it necessary to export headers from and linking against oox thus making the sc module dependent from oox. I wonder if this design decision with such an impact has been discussed somewhere before. It wasn't actually discussed at all, and no thought went into it; it was the easiest thing to do. The oox module has been started to be independent from most modules to make the entire office a bit more modular. Understood. So, what's the solution to this? In particular, a reasonably fast solution as I'd like to get this merged for OpenOffice.org 3.1. :-) I see the following solutions: 1. Leave the dependency, merge ooxml02 for 3.1, and work to remove it for 3.2+. 2. Split out oox's XmlFilterBase dependent types into a helper library (or perhaps use comphelper?), and depend on this helper library from both sc oox. 3. Implement BIFF/OOXML export within oox. (1) is obviously the easiest, requiring no immediate work, and the work to remove it for 3.2+ could be (2) or (3). I'm not sure how feasible (2) actually is -- it looks doable, but I'm not sure what hidden issues will show up, nor what library it would be appropriate to move FilterBase, XmlFilterBase, ZipStorage, etc. into. Cursory discussions suggest that comphelper may be a good destination, as sc already indirectly depends upon comphelper, so it's not really adding anything that wasn't there before. I don't like (2). I think best thing is to do (1), and think about (3) for 3.x as you suggested. ... reading this ... should have written a reason for disliking (2) :-) As you said, separating the base code from filter code may raise hidden issues and would make everything more complicated (working/building in 2 or more modules etc)... And I think this filter stuff is a little bit too special for comphelper. Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] The Excel import/export part of EUROCONVERT().
Daniel Rentz schrieb:
case T_Ext:
{
UINT16 n = pElement[ nId ];
EXTCONT* p = ( n nP_Ext )? ppP_Ext[ n ] : NULL;
if( p )
+ {
+ if( p-eId == ocExternal )
Oh no, there is a typo, it has to be:
+ if( p-eId == ocEuroConvert )
of course
Daniel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] The Excel import/export part of EUROCONVERT().
Lvyue schrieb: Hi, Daniel I have add what you advised in sc/source/filter, a new book type in xllink.hxx, in xilink.cxx, XclImpSupbook::XclImpSupbook(), a new type in enum XclImpExtNameType (and set it in XclImpExtName::XclImpExtName() ), and I also add a case for the new xlExt*** type. now, when imported, the formula EUROCONVERT can be caculated, but the name shown in is wrong, it appears as EUROCONVERTEUROCONVERT(..). If the formula calculates correctly, that means, the formula structure created by the filter is correct (there is only one ocEuroConvert token). Maybe the resource containing the function name is wrong. Could you attach a diff of your changes? That would help to judge what is going wrong. I'm confused, I wonder you can tell me what I'm missing. :( Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] About the ExternalDocLinks API in CWS mooxlsc
Hello Kohei looking at XExternalSheetCache::[sg]etCellValue(), I suggest to swap the parameters nRow and nColumn, because cell addresses are passed around in the entire sc module that way, and it is the member order in com::sun::star::table::CellAddress. Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] About the ExternalDocLinks API in CWS mooxlsc
Daniel Rentz schrieb: Hello Kohei looking at XExternalSheetCache::[sg]etCellValue(), I suggest to swap the parameters nRow and nColumn, because cell addresses are passed around in the entire sc module that way, and it is the member order in com::sun::star::table::CellAddress. ... see also com::sun::star::sheet::XCellRangeAccess::getCellByPosition() ;) Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] About the ExternalDocLinks API in CWS mooxlsc
Hi Kohei, some more thoughts... :-) Do we really need the SheetName string member in the ExternalReference struct? How about transporting the index of the cache in the Sheet member of the SingleReference/ComplexReference? The index should be available as attribute in XExternalSheetCache similar to the TokenIndex attribute in XExternalDocLink. This would allow to use external multi-sheet ranges, because the ComplexReference will contain two cache indexes. The only thing we will lose is the possibility to encode sheet-local external names. But as we do not support internal sheet-local names yet, we have to think about a (consistent) solution for both cases in the future. Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sc-dev] About the ExternalDocLinks API in CWS mooxlsc
Hi Kohei some thoughts about the new ExternalDocLinks API in CWS mooxlsc... First, there is no documentation in the IDL files, please consider to add some ;-) I think, a cleaner way to implement the service ExternalDocLinks is to make it a container, i.e. to support the interfaces XNameAccess, XIndexAccess, and XEnumerationAccess, similar to e.g. the DDELinks service. The interface XExternalDocLinks would add the new method addDocLink() that looks for an existing link or creates a new one, and returns the index. The XNameAccess uses the URLs as names. The elements of the container could implement the new service ExternalDocLink which is a container too. Elements are the ExternalSheetCache objects, names of the elements are the sheet names in the external document. A new interface XExternalDocLink adds the method addSheetCache() that looks for an existing cache similar to above. To do: do we need API to remove something from the cache, or an entire cache, or even an entire external linked document? Yes I know, that would be a little bit more work, but would make the new API more consistent to the existing Calc API. :-) Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] About the ExternalDocLinks API in CWS mooxlsc
Kohei Yoshida schrieb: Hey Daniel, On Fri, 2008-08-29 at 09:29 +0200, Daniel Rentz wrote: Hi Kohei some thoughts about the new ExternalDocLinks API in CWS mooxlsc... First, there is no documentation in the IDL files, please consider to add some ;-) Well, real men use code as the documentation. ;-) Yes, I know ;-) The elements of the container could implement the new service ExternalDocLink which is a container too. Elements are the ExternalSheetCache objects, names of the elements are the sheet names in the external document. A new interface XExternalDocLink adds the method addSheetCache() that looks for an existing cache similar to above. That was in fact pretty much my first version, then I realized that it was not consistent with the internal API from ScExternalRefManager, so I simplified it by removing the container class. But I can add it back for consistency's sake with the DDELink API. It just will be mostly a glue code though since internally there is no doc link container for each linked document. Yes, would be nice to have it. As you said, not so difficult to implement, as only container read-access is provided. And gives more freedom to use it externally. To do: do we need API to remove something from the cache, or an entire cache, or even an entire external linked document? I think we do, eventually. I would like to eventually export much of ScExternalRefManager's functionality via API so that we could use it for export filters as well as automation. But I'm still on my first version, so not all of its functionality is made available yet. Ok, I wrote all that came into my mind :) Yes I know, that would be a little bit more work, but would make the new API more consistent to the existing Calc API. :-) Well, I'm all for API's consistency. But keep in mind that I'm not through with my API yet. I checked it in so that we can start our discussion on API design (like this one). :-) I saw that Juergen Schmidt asked something too, on the [EMAIL PROTECTED] list. Looking forward to have this feature, thanks for your work :-) Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] About the ExternalDocLinks API in CWS mooxlsc
Kohei Yoshida schrieb: On Fri, 2008-08-29 at 09:29 +0200, Daniel Rentz wrote: To do: do we need API to remove something from the cache, or an entire cache, or even an entire external linked document? I don't think it makes sense to add API to remove individual cell cache from a table, since I can't think of a use case for it. So, I think it would make sense just to add API to remove entire cache per linked document, and/or remove all caches for all linked documents. Agreed, that would be enough. Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Calc Autoformatting Error
Leonard Mada schrieb: Hi Daniel, Thank you. Indeed, this did it. [I must say I did search up and down through the Options Dialog for a suitable option at no success.] Though I still miss an UNDO option in the context menu. I don't miss it, for me ALT+BS is much faster ;-) Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Calc Autoformatting Error
Leonard Mada schrieb: Hello everyone, I try to enter in a Calc cell: Diabetes mellitus Typ IIb but the last part gets converted automatically to Typ Iib. How do I undo this? This is obvious a serious bug. Why does Calc autoformat something it is NOT supposed to do? try to uncheck Tools - AutoCorrection - Options - Two capitals Regards Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Multiline formulae support
Hi, Eike Rathke schrieb: Some potential issues: - Compatibility with Excel possibly needs discussing. We've not been compatible with Excel in the past and this patch does not make it 100% compatible, rather it improves compatibility, and improves further where Excel gets it wrong IMHO. I really don't have any problem with Calc being superior to Excel at some places ;-) But being different here may result in documents being displayed with different row heights when imported, something that sometimes makes users act strangely.. As Excel does not support multiline formula results, chances are low that there are many Excel documents really using '\n' in formula results. Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Issue for #VALUE! on Excel import ?
Cor Nouws schrieb: Hi Eike, Solution would be to always generate an error in such case. You mean an error if an formula holds an non numeric argument. This is the same as Excel does, 'only' with this difference that Excel in some formulas uses text that can be interpreted as number, and in other also simply neglects it. Which - with my limited knowledge - looks as a sort of a mess. And I have the impression that it differs over various versions of Excel as well. Anyone with basic or comprehensive data on the way different versions of Excel handles text in different formula's?? Would be much appreciated! (reason further below) So the Excel way is not something I propose. I have a few Excel versions lying around here, and cannot find any differences. Tested Excel versions: - Excel 3.0a German UI - Excel 4.0 German UI - Excel 5.0 German UI - Excel 2003 German UI - Excel 2003 English UI - Excel 2007 English UI I have made the following test: A1: 1.5 A2: '1.5 A3: '1.500 A4: '1,500 A5: text A6: =A1+A2+A3+A4 A7: =SUM(A1,A2,A3,A4) A8: =SUM(A1:A4) A9: =1.5+1.5+1.500+1,500 A10: =SUM(1.5,1.5,1.500,1,500) A11: =A1+A2+A3+A4+A5 A12: =SUM(A1,A2,A3,A4,A5) A13: =SUM(A1:A5) A14: =1.5+1.5+1.500+1,500+text A15: =SUM(1.5,1.5,1.500,1,500,text) Using locale en-US, the results of the formula cells are: A6 = 1504.5 A7 = 1.5 A8 = 1.5 A9 = 1504.5 A10 = 1504.5 A11 = #VALUE! A12 = #VALUE! A13 = 1.5 A14 = 1.5 A15 = #VALUE! - 1.5 and 1.500 are interpreted as 1.5 - 1,500 is interpreted as 1500 - the addition operator always tries to convert text to numbers - the SUM function ignores text cells, but converts literal text Using locale de-DE, the results of the formula cells are: A6 = 41072 A7 = 1,5 A8 = 1,5 A9 = 41072 A10 = 41072 A11 = #VALUE! A12 = #VALUE! A13 = 1,5 A14 = 1,5 A15 = #VALUE! - 1.5 is interpreted as 1st of May 2008, resulting in 39569 - 1.500 is interpreted as 1500 - 1,500 is interpreted as 1.5 Do you have other examples that I may test in different Excel versions? Regards Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] start issue92313
yunjingtao schrieb: hi, Daniel can you explain these SFX_STYLE_FAMILY_CHAR SFX_STYLE_FAMILY_PARA SFX_STYLE_FAMILY_FRAME SFX_STYLE_FAMILY_PAGE to me? Open a Writer document and the Stylist (Format-Styles or key F11). On top you see different buttons for different types of styles for paragraphs (SFX_STYLE_FAMILY_PARA), characters (SFX_STYLE_FAMILY_CHAR), pages (SFX_STYLE_FAMILY_PAGE), or text frames (SFX_STYLE_FAMILY_FRAME). Now open a Calc document and the Stylist. You see that Calc uses page styles (SFX_STYLE_FAMILY_PAGE) and cell styles (SFX_STYLE_FAMILY_PARA) only. In Calc, all styles are ScStyleSheet objects (sc/inc/stlsheet.hxx) derived from SfxStyleSheet (svtools/inc/style.hxx). The SfxStyleSheet class is able to store the style family. should I disable the Delete contex menu item appeared after having remove the protection ? Yes, try to find the place where the context menu item is disabled (there should be some code that checks whether the style is built-in). Then, when protection is disabled, something similar has to be done. Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] How to use erfc() or getErfc() from scaddins in sc ?
Hi Regina, Regina Henschel schrieb: Hi Daniel, hi Kohei, I've learned now, that I can get erfc(z) by GetUpRegIGamma(0.5,z^2), so I need no copypaste. GetUpRegIGamma is a private function of ScInterpreter, in file interpr6.cxx. But now I have the next problem: The structure now is: We have a public function void ScInterpreter::ScBetaDist() Inside this, and in some other functions too, there is a call to the private function double ScInterpreter::GetBetaDist This function is so complex, that I thought, it would be a good idea to swap out some steps into local functions. For example, I have defined a function lcl_GetBetaHelperContFrac which calculates a continued fraction needed for GetBetaDist. Thats works good, because it uses only 'normal' functions. But the next part, which I want to modularize, is the algoritm known as BASYM (Didonato/Morris algoritm 708). It is a part of about 90 lines. Unfortunately it needs the private functions double ScInterpreter::GetUpRegIGamma( double fA, double fX ) and double ScInterpreter::GetLogBeta(double fAlpha, double fBeta) How to solve this? I know, if I would make it a private function of ScInterpreter too, I can access GetUpRegIGamma and GetLogBeta. But is that the structure you want? Are there other, better ways to get access to that functions? Are ScInterpreter::GetUpRegIGamma() and ScInterpreter::GetLogBeta() static (A), can they be static (B), or do they actually use members or other non-static functions of ScInterpreter (C)? (A) remove them from ScInterpreter and make them local functions. (B) same as (A) (C) it does not help, BASYM has to be a private member of ScInterpreter. Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] macro fails with oo 3.0 - returns byte instead of string array !
Oliver Brinzing schrieb: Hi Daniel, But I'm not an expert, and as the code below is not specific to the Calc API, you probably should ask on the [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing list. i found out what is going wrong, just run the new example ... i think this is a bug ... can you confirm ? Yes, confirmed. Behaviour changed between 2.4.1 and 3.0, and looks wrong in 3.0. Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] About issue25018
yunjingtao schrieb:
Daniel schrieb:
Please do not rely on the item state only, but test the contents of the
item too. See the example for the FID_MERGE_TOGGLE item in the same
file: the test ... = SFX_ITEM_DEFAULT
makes sure that the item exists (it has state DEFAULT or SET), and
that it is possible to use the item returned in the pItem parameter of
the QueryState function. Try to combine the GetValue() test into the else
if ...;
hi, Daniel
I made some changes and submitted another patch to issue25018.
I don't know whether I understood you completely.
The variable bIsFullScreen I add is used to test.
Hello,
Some comments on the new attached patch: You query the state of item
nSlot which is currently SID_CANCEL (nSlot is used in the
switch/case). But we need to query the current state of the
SID_WIN_FULLSCREEN slot. Next, you call pTabViewShell-Escape() when
fullscreen is enabled, and disble fullscreen if it is already off.
Please try the following:
1) Add two functions to ScCellShell, as I mentioned in my last mail:
bool IsFullScreen() const
{
... query the state of the SID_WIN_FULLSCREEN slot as described
before (use QueryState and SfxBoolItem::GetValue)
}
void SetFullScreen( bool bSet )
{
... put a new bool item for the SID_WIN_FULLSCREEN slot
}
This is done to improve readability of the code.
2) Now it is possible to add a simple two-liner to the SID_CANCEL
handler in cellsh3.cxx, something like
...
else if( IsFullScreen() )
SetFullScreen( false );
else
...
Hope this helps
Daniel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] macro fails with oo 3.0 - returns byte instead of string array !
Oliver Brinzing schrieb: Hi, are there any known issues with the basic engine in oo 3.0 ? i tried m23/m25 with same results ... i have code *similar* to the snippet below, which will filter Named Ranges of a calc document, for example all Named Ranges starting with X_XXX ... it will return an array of strings, containing the cell ranges ... debugging the program show's that the array contains bytes instead of string. mRanges() shows type: String, mX() shows type Byte ... btw: i can not reproduce the bug with the example below no problems with oo 2.4.1 at all... any hints are welcome Oliver Hi Oliver, What happens if you set mX as Variant? But I'm not an expert, and as the code below is not specific to the Calc API, you probably should ask on the [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing list. Regards Daniel REM * BASIC * OPTION EXPLICIT Sub Main Dim mX() as String mX() = Test() 'after the call mX() sometimes has Byte Values instead of String ! 'for example: mX(0) = 1, mX(0) = 0, ... MsgBox mX(0) mX(1) End Sub Function Test() as Variant Dim mRanges(100) as String mRanges(0) = 1 mRanges(1) = $A$1:$B$10 ' mRanges is a String Typ (correct) Test = mRanges() End Function -- Sun Microsystems GmbH Nagelsweg 55 20097 Hamburg Germany Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] About issue25018
yunjingtao schrieb: hi, Daniel I submitted a patch to issue25018. Using some test cases, I checked it, and it's ok. Hope you review it, and if possible,give me some advice. If there is no problem with it, assign me issues please. I have one question and wish you answer it at your convenience.The function SfxBindings::QueryState can return SfxItemState, but I don't understand what the several state types mean, such as SFX_ITEM_SET,SFX_ITEM_DONTCARE and so on, can you explain them for me? In this patch the return value is 32,eaque to SFX_ITEM_DEFAULT. Please do not rely on the item state only, but test the contents of the item too. See the example for the FID_MERGE_TOGGLE item in the same file: the test ... = SFX_ITEM_DEFAULT makes sure that the item exists (it has state DEFAULT or SET), and that it is possible to use the item returned in the pItem parameter of the QueryState function (see below for more info about the states). Try to combine the GetValue() test into the else if ...; or even better, add two helper functions to ScCellShell: bool IsFullScreen() const and void SetFullScreen( bool bSet ). This would make it more readable. There are 6 item state constants defined in svtools/poolitem.hxx: #define SFX_ITEM_UNKNOWN0x for unknown items. #define SFX_ITEM_DISABLED 0x0001 for disabled items (e.g. gray icons in toolbars). #define SFX_ITEM_READONLY 0x0002 for read-only items. #define SFX_ITEM_DONTCARE 0x0010 for items with mixed values in the current context (e.g. different colors in a range of cells). Therefore the QueryState() function cannot return an item. #define SFX_ITEM_DEFAULT0x0020 for the predefined value of an item defined in the item pool (e.g. no background color for a sheet cell). The QueryState() function returns an item that contains this default value. #define SFX_ITEM_SET0x0030 for a changed value (e.g. some color for a sheet cell). The QueryState() function returns an item with this value. Only *one* of the states DONTCARE, DEFAULT, or SET can be set at a time, but the flags DISABLED and READONLY may be combined with the state. Therefore it is possible to make the test = SFX_ITEM_DEFAULT as you can see in the FID_MERGE_TOGGLE example above. If you need more issues, please have a look in my issue list: http://qa.openoffice.org/issues/buglist.cgi?issue_status=UNCONFIRMEDissue_status=NEWissue_status=STARTEDissue_status=REOPENEDemail1=dremailtype1=exactemailassigned_to1=1email2=emailtype2=exactemailreporter2=1issueidtype=includeissue_id=changedin=votes=chfieldfrom=chfieldto=chfieldvalue=short_desc=short_desc_type=allwordslong_desc=long_desc_type=allwordsissue_file_loc=issue_file_loc_type=fulltextstatus_whiteboard=status_whiteboard_type=fulltextkeywords=keywords_type=anytokensfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitnewqueryname=order=%27%27Submit+query=Submit+query Of course I will try to find some issues too... Here are some more User Interface issues: http://qa.openoffice.org/issues/show_bug.cgi?id=89173 http://qa.openoffice.org/issues/show_bug.cgi?id=40679 http://qa.openoffice.org/issues/show_bug.cgi?id=91532 DR-NN: please correct me if something with the item stuff is wrong... Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] about issue86945
yunjingtao schrieb: Daniel wrote: The aEdComment gets the focus though you do not pass WB_TABSTOP to its c'tor? hi, Daniel Thank you for you reply. Yes, exactly. The aEdComment gets the focus, I think the reason is because of WB_DIALOGCONTROL | WB_TABSTOP in ScScenarioWindow constructor, so TAB key can travel aLbScenario and aEdComment. I add WB_NOTABSTOP to avoid this. I It is OK that the edit gets the focus, I just didn't expect that this works without the WB_TABSTOP flag. Please do not disable this with the WB_NOTABSTOIP flag. submit a patch to this issue. Please check it. It works well on my computer. The remaining patch is ok, nice work. I will apply it in my next CWS. Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Values depending on linked and not available spreadsheet - xls-viewer OOO
Eike Rathke schrieb: Hi Cor, On Thursday, 2008-04-17 10:10:19 +0200, Cor Nouws wrote: Easy to fix as you suggested. Only saving as xls and re-opening, again shows #NA ... Saving as ods does save the results. It seems that interim results of external references aren't saved to Excel file format. Daniel? They are saved as long as the referenced range does not exceed a size of 1024 cells. This has been done to prevent memory problems with files that reference an entire sheet in an external document, see http://www.openoffice.org/issues/show_bug.cgi?id=70418. AFAIK, Excel does only save the results of non-empty external cells, that would be an option for the export filter too. Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] three issues
Eike Rathke schrieb: Hi YunJingtao, On Tuesday, 2008-04-15 09:43:32 +0800, YunJingtao wrote: hi, Daniel As you Cc'ed Daniel's personal account I assume that he answered directly, as usual. However, for transparency I'd prefer if people didn't Cc personal accounts if the receiver reads the mailing list anyway, in order to make replies go always to the mailing list. Otherwise it looks like your questions were never answered.. Either that, or Daniel should use the GroupReply/ReplyAll function of his mail reader to break the silence ;-) Good point, will do so now... ;) Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] another problem related i10755
YunJingtao schrieb: Yes.Following these steps Data-Define Range, you can find that the dialog are the same and the same mistakes. According to your advice, I try to fix the function UpdateNames() and add some code. at the begining: //aEdName.Clear(); String aNewEntry = aEdName.GetText(); //get the name the mouse selected NameSelectHdl(0); USHORT nNamePos = aEdName.GetEntryPos( aNewEntry); //get the postion USHORT nStoreNamePos = aEdName.InsertEntry(aNewEntry, nNamePos); //store and at the end: aEdName.GetSelectEntryPos(nStoreNamePos); //restore but this doesn't work. Maybe I am wrong, any advice? Hello Try using the functions ComboBox::GetTopEntry() and ComboBox::SetTopEntry() (see vcl/inc/combobox.hxx). This should be easier. These functions get/set the first visible entry (and thus the scrollbar position) in the list. Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] another problem related i10755
YunJingtao schrieb: hi, Daniel Same phenomenon happens when Define Range(Data-Define Range). They are all related to ScrollBar. What should we do next? Hello the dialog should behave correctly for all functions (Add, Remove, Modify). Are there other places where the name list is cleared and rebuilt? My impression was that by fixing the UpdateNames() function, all these functions are fixed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] issue10755
YunJingtao schrieb: hi, Daniel Do you mean that I should use ListBox instead of ComboBox? Sorry, ComboBox is correct, no need to change this (I didn't check what class is used in the dialog). Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] issue10755
Hello, This morning seeing the status and resolution of Issue3866 were changed to resolved and wontfix, I read them as it needn't fix now, so today I begin to fix the issu10755. So simple the description of the issue10755 is that it is difficult for me to reproduce the wrong phenomenon it mentions. Can you depict it in details? In the Insert-Name-Define dialog, add a lot of entries until you have more than are visible in the listbox (type a new unique name, click to a cell of the sheet, press Add, repeat). Now, scroll to the last entry, select it, select another cell, click Modify. Now, the list jumps back to top, but should stay at its old position. Hope that helps. If not, feel free to ask again. Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Iimporting OpenXML files with more than 65K rows?
Kirill S. Palagin schrieb: Thanks for the link. Actually I meant our specification for the import and how we are handling spreadsheets with more than 65K rows on import, not full spec of OpenXML. Contents out of the limits of the current document are truncated. After import, this will be shown in a warning box. There is no specification for that. Do you want to know something specific? Regards Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Our plan to improve Calc functionality related tophonetic text
Kohei, Kohei Yoshida schrieb: As for the OOXML file, the texts with ruby are represented as follows. sst xmlns=http://schemas.openxmlformats.org/spreadsheetml/2006/main; count=2 uniqueCount=2 si t吉田浩平/t rPh sb=0 eb=2 tヨシダ/t /rPh rPh sb=2 eb=4 tコウヘイ/t /rPh phoneticPr fontId=1/ /si si t私は今アメリカで働いています。/t rPh sb=0 eb=1 tワタシ/t /rPh rPh sb=2 eb=3 tイマ/t /rPh rPh sb=8 eb=9 tハタラ/t /rPh phoneticPr fontId=1/ /si /sst And this appears inside the sharedStrings.xml fragment. Just for interest: what do these examples mean in English? I want to add them into our filter test documents. Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Our plan to improve Calc functionality related to phonetic text
Daniel Rentz schrieb: Kohei Yoshida schrieb: On Mon, 2007-08-20 at 18:39 +0200, Niklas Nebel wrote: Kohei Yoshida wrote: Ok, but I don't think the ruby text is entirely a formatting attribute of the text. I consider that a part of the raw text data. When querying for raw text, as in formulas, or text export, do you expect the ruby text to be included? If the caller requests the ruby to be included, then yes, otherwise no. Of course the default behavior should be to exclude the ruby text when the string instance is queried for raw data, but that doesn't mean the ruby text data should not be there. The way Excel works is as following: Think about a situation where cell A1 contains a text and phonetic text. The formula =A1 will return the main text only, and the formula =PHONETIC(A1) will return the phonetic text only. Formula cells with text results will never contain phonetic text information, so if you have the formulas above in cell A2 and A3, and call =PHONETIC(A2) and =PHONETIC(A3) in other cells, the result will be an empty string in both cases. While I am playing with that... If a text cell does not contain phonetic text, the PHONETIC function call returns the main text instead of an empty string. Of course, as mentioned, this does not happen with formula cells. Regards Dainel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Our plan to improve Calc functionality related to phonetic text
Kohei Yoshida schrieb: On Mon, 2007-08-20 at 18:39 +0200, Niklas Nebel wrote: Kohei Yoshida wrote: Ok, but I don't think the ruby text is entirely a formatting attribute of the text. I consider that a part of the raw text data. When querying for raw text, as in formulas, or text export, do you expect the ruby text to be included? If the caller requests the ruby to be included, then yes, otherwise no. Of course the default behavior should be to exclude the ruby text when the string instance is queried for raw data, but that doesn't mean the ruby text data should not be there. The way Excel works is as following: Think about a situation where cell A1 contains a text and phonetic text. The formula =A1 will return the main text only, and the formula =PHONETIC(A1) will return the phonetic text only. Formula cells with text results will never contain phonetic text information, so if you have the formulas above in cell A2 and A3, and call =PHONETIC(A2) and =PHONETIC(A3) in other cells, the result will be an empty string in both cases. That would be consistent with XHTML ruby markup, but different from Excel. Is that really different from Excel? Because Excel is where the idea of embedding the ruby into the raw text string came from. As mentioned, only in text cells, not at all places where strings are used, such as formula results. Regards Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Our plan to improve Calc functionality related tophonetic text
Eike Rathke schrieb: Hi Kohei, On Tuesday, 2007-08-21 08:12:13 -0400, Kohei Yoshida wrote: What I meant to say was that Excel embeds the ruby text directly into string data in the shared string table, instead of storing it as a cell attribute. As part of the string? How is it distinguished? Talking about BIFF, each string may contain two kinds of additional data, first the portion formatting (rich text aka edit text), second the phonetic text, including all positioning data. Similar in OOXML, effectively an entry in the shared string table is the complete string cell, including portion formatting and phonetic text. Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Formula import for OOXML
Hi Kohei Also, how are we dealing with Excel's shared formulas? I have implemented shared formula import for the OOX and BIFF filters. They are as good as the underlying formula import. The only outstanding task is to hide the generated defined names __shared_??? that are used to simulate shared formulas in Calc. We will do this when Niklas is back from vacation. Gotcha. I was just wondering about the status of shared formulas, because I had noticed some recalculation problem upon loading of documents containing shared formulas. Anyway, I trust that problem will be worked on as part of solving the above problem (?) I am not aware of such a problem, please check with the latest code changes and let me know about any problem. Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Formula import for OOXML
Leonard Mada schrieb: What are shared formulas? Is it the same as the concept I presented in a previous e-mail, where one can have a default formula for a column? This is indeed a very useful feature to have in OOo Calc and is one issue that gets into my TOP 5 of major design flaws of existing spreadsheets. You cannot create shared formulas by yourself, neither in Calc nor in Excel. Excel creates them automatically e.g. when pasting a formula cell to a range selection. They are not visible in the user interface. A similar concept to have a named formula definition for multiple cells are defined names (Insert-Name-Define). It definitely helps reduce the spaghetti code inherent to spreadsheets and is also an important concept when extending the simple spreadsheet to multidimensional spreadsheets. I will file a new feature request when I will have some time. Shared formulas are intended to reduce memory usage and file size, don't know if they would help you. What do you mean with spaghetti code? Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Rubber/Pencil function for Calc
Max Giesbert schrieb: actually i have problems with the very first line of code you sent: acc = ThisComponent.CurrentController.Frame.ComponentWindow.AccessibleContext i am doing development right now using java. so i do get the ComponentWindow by: XWindow window = xController.getFrame().getComponentWindow(); but how do i get the AccessibleContext from XWindow? The Window should support the XAccessible interface, which in turn contains one function getAccessibleContext() that returns the XAccessibleContext interface. XAccessible acc = (XAccessible)UnoRuntime.queryInterface(XAccessible.class, window); XAccessibleContext accessibleContext = acc.getAccessibleContext(); Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Rubber/Pencil function for Calc
Max Giesbert schrieb: Thx again. feels like i am already there. i got the XCell now from the Target but how can i get the location of the cell on the screen. i read about XAccessibleComponent but XCell doesn't seem to implement it... I have written a tiny test script in Basic recently, that gets the XAccessible for the first sheet in the first open Calc document. Maybe this helps you to continue... Some ideas how to proceed: You can get the parent of the sheet, this is the container of all sheets, to be able to get the n-th sheet. From the sheet you can call getAccessibleCellAt(row,column) to access the cells. Note that the lines in the code below may be broken into several lines. Sub Main acc = ThisComponent.CurrentController.Frame.ComponentWindow.AccessibleContext table = GetAccessibleForRole( acc, com.sun.star.accessibility.AccessibleRole.TABLE ) If Not IsNull( table ) Then ... EndIf End Sub Function GetAccessibleForRole( acc As Object, role As Integer ) As Object If IsNull( acc ) Then Exit Function count = acc.AccessibleChildCount If count = 0 Then Exit Function For i = 0 To count - 1 child = acc.getAccessibleChild( i ).AccessibleContext If child.AccessibleRole = role Then GetAccessibleForRole = child Exit Function EndIf Next For i = 0 To count - 1 child = GetAccessibleForRole( acc.getAccessibleChild( i ).AccessibleContext, role ) If Not IsNull( child ) Then GetAccessibleForRole = child Exit Function EndIf Next End Function - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] sheetViews context handling strategy
Kohei Yoshida schrieb: Hi all, So, worksheet element has a child element called sheetViews, which contains a group of sheetView elements. It contains view data such as the cursor position, active sheet etc. Here is a problem with importing these view settings. For us to set such view data, we have to gain access to the current controller, which is not available at time of file import. It appears to be set after the import is complete. This may be reasonable since a file typically gets loaded before the corresponding application frame gets shown. I have also looked into getting a XViewDataSupplier instance from the model since there is a model instance during import, but so far no luck. I have not looked far enough into this, but my gut feeling is that, the view data needs to be set before we can query for its instance, which it is not during import (correctly me if I'm wrong). Now, since we need to keep our design of the oox::xls code reasonably close to the design of the existing Excel binary filter, it's probably logical to do something similar to what the binary filter currently does for the view settings. I've discovered that the binary filter creates an instance of ScExtTabSettings for each sheet to temporarily store view settings of their respective sheet during import, and use ScExtTabSettingsCont as a container and ScExtDocOptions to control the life cycle of those ScExtTabSettings instances. Once the import is complete, the filter calls PostDocLoad() to commit the view settings collected during import. I could see us doing something similar for SpreadsheetML import. We would still need to work out a way to do equivalent of PostDocLoad(), but at least for now, we could create view setting container classes to start collecting view data during import. Yes, these container structs can be designed very similar to the existing structs in the core. Don't know if we want to stick to the existing approach of creating a sequence property values and passing it to the view settings interface. Btw, an existing equivalent of PostDocLoad() is WorkbookFragment::endDocument(). Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Metadata section of XLS files
René Peinl wrote: Hi guys, I'm sorry to bother you with this, but you seem to be the only people reachable outside Microsoft that know about the XLS file format. I've dealt myself a lot with the XML versions and also did some minor enhancements to the OO XSLTs that convert WordML to OO, but now I need some help with the binary version. I'm trying to write a comparison function that compares two versions of a document with each other and should return true if the documents have the same content and false otherwise. I'm using an MD5 hash to do this. The reason is, that I want to eliminate versions of documents in Sharepoint where only metadata has changed. Unfortunately, Sharepoint is so clever that it writes Metadata not only into its own database, but also inside the document itself, if it is an office document type. Therefore I want to strip off the header (and trailer) that contains metadata. For doc files this is quite easy. I just had to remove (or overwrite with zeros) the first 2554 and the last 1520 bytes and compare the files afterwards. Unfortunately this strategy does not work with XLS files. It seems that every sheet inside the file has it's own copy of metadata. Can you give me any advice, how to get rid of the metadata (just for the comparison). Is there any byte sequence I can search for and then overwrite the next x byte with zeros? I would be really thankful for any help. Thanks a lot and We have a complete description of the OLE2 container file format: http://sc.openoffice.org/compdocfileformat.pdf Regards Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Spreadsheet functions' issues
Hi, Eike Rathke schrieb: Last year ;) Muthu Subramanian sent me a mail in which he asked whether we're already working on specific issues he picked to work on. I asked him to repeat the question on the mailing list because I want to keep discussion public, but he didn't show up since. Nevertheless I investigated the issues he listed and following is the status, or was on December 15th. On Fri, Dec 02, 2005 at 23:33:40 +0530, Muthu Subramanian wrote: Function Incompatibility http://www.openoffice.org/issues/show_bug.cgi?id=3866 : NETWORKDAYS http://www.openoffice.org/issues/show_bug.cgi?id=32269 : SERIESSUM Daniel, your AddIn area: are you planning to work on it? These are minor changes (input checking only), you can fix them, otherwise I may do it when working on other add-in issues. Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] open office calc question.
Hi, Askanthea wrote: I dont know if you can help but i got your email from the -to do page. If I have a long column of variables for example numbers 1-100 in cells a1-a100 when i try to print it comes out on 2 or 3 pages - i want the finished result to appear on one page but in 2 or 3 columns without changing my origional data. Im sure there is an option within msoffice to do this. Hmm, I'm not so sure about this. Do you remember any details, how to achieve this in MS Excel? Best regards Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Functions needed?
Hi, Kohei Yoshida schrieb: On 5/17/05, Daniel Rentz [EMAIL PROTECTED] wrote: Yes, it is. It also includes information about differences between the varios versions of Excel, e.g. available functions and different parameter counts. Cool. That's even better. Thanks for the clarification. One addition: Note that this document does not contain any of the Analysis add-in functions. Only built-in functions are listed. Regards Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
