<div dir="ltr">Hey,<br><div class="gmail_extra"><br><br><div class="gmail_quote">2013/11/11 Kohei Yoshida <span dir="ltr"><<a href="mailto:kohei.yoshida@collabora.com" target="_blank">kohei.yoshida@collabora.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi there,<br>
<br>
Eike brought to my attention that my recent change to use the internal<br>
API to import formulas from xlsx broke the extra handling that the UNO<br>
API was doing to translate some of the newer Excel functions from Excel<br>
2010 and newer.  These new functions are typically prefixed with _xlfn.<br>
in the XML stream so that when the function name is e.g. BETA.DIST, it<br>
would appear as _xlfn.BETA.DIST in the sheet stream where the formula<br>
cell is stored.<br>
<br>
Long story short, the way I've decided to solve this was to add another<br>
set of function names and associate it with formula language XL_ENGLISH,<br>
which is, for now, only used for importing xlsx in a significant way.<br>
<br>
So, when you guys have implemented these new functions in Calc core, but<br>
have trouble importing them from xlsx, please take a look at resource<br>
RID_STRLIST_FUNCTION_NAMES_ENGLISH_OOXML in<br>
formula/source/core/resource/core_resource.src and see if the stored<br>
function name matches what's in the XML stream.<br>
<br>
Hopefully this fixes the old functionality from the UNO formar parser<br>
that we were missing in ScCompiler.<br>
<br></blockquote></div><br></div><div class="gmail_extra">And a small request by me. Could we maybe add always directly an import/export test when we add a new function?<br><br></div><div class="gmail_extra">Adding an import/export test for a function is normally a task of a few minutes and should help us prevent regressions with these functions.<br>
<br></div><div class="gmail_extra">Regards,<br>Markus<br></div></div>