Re: [sc-dev] The Excel import/export part of EUROCONVERT().
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. Best regards Lvyue - 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]
Re: [sc-dev] The Excel import/export part of EUROCONVERT().
hi Daniel, Sorry to disturb you again. I have added some functions in the classes you mentioned in last mail( you can see them in the patch 4 of issue 93789 ). http://www.openoffice.org/issues/show_bug.cgi?id=93789 but it works stranger, now, after export, and when open again, the formula appears =NA(). can you tell me what is wrong in my patch? and I wonder what is nRecSize, nRecPos, and nRec... used for. I must miss many things in exporting, but I can not find out, please offer me some help. thank you very much. Best regards Lvyue - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] The Excel import/export part of EUROCONVERT().
Hi Daniel,
On Tuesday, 2008-10-21 09:41:05 +0200, Daniel Rentz wrote:
+BOOL lclConvertMoney( const String aSearchUnit, double rfRate, int
rnDec )
Btw, aSearchUnit should be a const reference instead of a copy, so
const String aSearchUnit
^^^
+{
+#define COUNT 16
+#define CURRENCY( name ) \
+(String::CreateFromAscii( RTL_CONSTASCII_STRINGPARAM( name ) ))
+ConvertInfo aConvertTable[ COUNT ] = {
+{ CURRENCY( EUR ), 1.0, 2 },
I am not sure (-Eike?) but initializing the strings this way may fail
with certain compilers.
Yes, initializing static instances of class objects isn't guaranteed to
always work in the order assumed (well, it probably would in this case),
plus it adds unnecesary overhead when initializing the library's data.
One more thing: the often observed pattern
String aFoo( String::CreateFromAscii( RTL_CONSTASCII_STRINGPARAM( literal )))
is better written as
String aFoo( RTL_CONSTASCII_USTRINGPARAM( literal ))
with the advantage that an approriate ctor is called that already
includes the count of characters and no temporary instance of class
String is needed just to pass to the final String copy-ctor.
Note the U in USTRINGPARAM, without that you would get a different
parameter count and meaning!
However, the latest revision of the patch already changed the table
layout to use ASCII literals. The String::CreateFromAscii(...) still
applies though.
Please do not #define the COUNT but calculate the array size after the
array. In the future, more countries may convert to the Euro currency.
This may be the source of errors when the next developer forgets to
update the COUNT after adding a line to the list.
Which (w|sh)ould make the compiler complain about extra elements ...
anyway
Better:
const ConvertInfo aConvertTable[] = {
...
};
const int COUNT = sizeof( aConvertTable ) / sizeof( ConvertInfo );
Some nitpicks:
- Counts shouldn't be of type int but size_t instead.
- COUNT is a very common name that may clash sooner or later with some
includes, I suggest nConversionCount or such.
- Instead of sizeof(ConvertInfo) use sizeof(aConvertTable[0]), this way
one would not had to adapt that place in case the name of ConvertInfo
would have to be changed for whatever reason.
if( maXclUrl.EqualsIgnoreCaseAscii( \008EUROTOOL.XLA ) )
Note the characters \008 which encode the ASCII character 8.
Erm.. \010, just for the records, but we already clarified that on IRC ;-)
As a side note maybe interesting to others reading this: a literal
\x08EUROTOOL.XLA failed because the compiler takes \x08E as one entity
and thus produces the string 0x8E,UROTOOL.XLA ...
Eike
--
OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
SunSign 0x87F8D412 : 2F58 5236 DB02 F335 8304 7D6C 65C9 F9B5 87F8 D412
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't send personal mail to the [EMAIL PROTECTED] account, which I use
for
mailing lists only and don't read from outside Sun. Use [EMAIL PROTECTED]
Thanks.
pgplSq7Kq8DN5.pgp
Description: PGP signature
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: Re: [sc-dev] The Excel import/export part of EUROCONVERT().
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(..). I'm confused, I wonder you can tell me what I'm missing. :( Thank you very much. Lvyue 2008-10-17
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]
