Posted by
Slava Mazur on
Aug 19, 2008; 6:53pm
URL: http://quantlib.414.s1.nabble.com/Error-calling-xlfGetDef-Excel-API-function-from-Objecthandler-s-FunctionCall-callerName-tp12192p12194.html
Hi Eric,
Thank you for the information and for the insides of ObjectHandler
functionality which have been really helpful to pinpoint the problem.
Objects are stored in objectMap_ using object ID as a key (see
std::string Repository::storeObject).
ObjectXL class returns a user defined id ignoring the calling range and
this id is used as a key in the object map (see ObjectXL::id() and
RepositoryXL::storeObject()).
This is obviously a problem - if we create two different objects in
different Excel cells they will definitely substitute each other in the
object map.
Another problem is CallingRange::updateCount_. Since it's a non-static
member then it's possible to generate the same ObjectXL::idFull_ for
different objects with the same user defined id (see
ObjectXL::setCallingRange()).
Note that if a user doesn't specify their id, everything works fine
because in this case internally generated id takes into account a
calling range (see again ObjectXL::setCallingRange()).
I think this can be fixed in two ways. For my quick fix I changed the
logic of ObjectXL::id() - it generates id upending calling range key
regardless of whether a user passed a valid id or not.
However, as far as I understood, one of motivations for the current
design was to hide calling range keys from the users and handle them
internally. In this case one needs to figure out a caller range key and
generate a key to find an object in the map out of a user defined id and
the calling range key. I'm not sure how to do that. And also, in this
case one needs to make CallingRange::updateCount_ static. Otherwise a
user will be able to generate the same object ids for different objects,
which although will be handled correctly internally (since calling
ranges are different) would look misleading from the user's perspective.
Eric, I know I owe you my reply regarding XLL containers. Thank you for
your appreciation and interest. I still don't have any feedback from my
employer regarding the source code (perhaps because of vacation time and
Olympic Games of course :), but it looks like they won't object. As for
technical details, I'll definitely get back to you as soon as I sort out
all existing issues with ObjectHandler.
Regards,
Slava Mazur
-----Original Message-----
From: Eric Ehlers [mailto:
[hidden email]]
Sent: Tuesday, August 19, 2008 5:21 AM
To: Slava Mazur
Cc:
[hidden email]
Subject: Re: [Quantlib-dev] Error calling xlfGetDef Excel API function
from Objecthandler's FunctionCall::callerName()
Hi Slava,
Functions of the Excel C API are documented in the macrofun help file
that
shipped with Excel 4:
http://support.microsoft.com/kb/128185The help file identifies the functions by their old names in the Excel 4
macro
language, xlfGetDef was called GET.DEF. xlfGetDef retrieves the name,
if any,
that is associated with the specified range.
ObjectHandler names the ranges from which addin functions are called as
a way
of tracking objects. The names are created by the call to xlfSetName in
the
constructor of class CallingRange. FunctionCall::callerName() wraps
xlfGetDef
and returns the name which has been associated with the range that
invoked
whatever function is currently executing.
If no name is associated with the given range then xlfGetDef returns a
value
of type xltypeErr (16). This isn't an error condition as far as
FunctionCall::callerName() is concerned and the function returns an
empty
string. The possible return values of FunctionCall::callerName() are
handled
in RepositoryXL::getCallingRange(). It would not make sense for
FunctionCall::callerName() to return FunctionCall::callerAddress() in
the
absence of a name.
If two different objects are somehow acquiring duplicate keys, that's
certainly an error condition which should be prevented. I haven't seen
the
error, is there any chance that you could troubleshoot further and maybe
come
up with an example that would enable me to recreate the problem?
Regards,
Eric
-------------------------
Eric Ehlers
nazcatech sprl | Brussels |
http://www.nazcatech.beDistributed computing for pricing analytics - Use Microsoft Excel as a
client
to the Grid
On Fri, August 15, 2008 19:07, Slava Mazur wrote:
> Greetings,
>
> Has anyone experienced such a behavior? It happens intermittently for
some
spreadsheets in some circumstances and I cannot figure out why. Also I
couldn't find any details about xlfGetDef function.
> If anyone knows could you please point me to?
>
> Here are some details.
>
> The following function call inside FunctionCall::callerName() returns
xName->xltype = 16 meaning error:
>
> Excel(xlfGetDef, &xName, 1, FunctionCall::instance().callerAddress());
>
> The function returns an empty string in such a case. This may result
in
duplicate object keys defined in different cells, which is totally
undesirable. So my questions are:
>
> 1. Does anyone know why the function fails?
> 2. Why ObjectHandler doesn't handle a possible error condition?
> 3. Wouldn't it better to return
FunctionCall::instance().callerAddress()
instead of an empty string in such a case?
>
> Thanks,
>
> Slava Mazur
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev