Posted by
Eric Ehlers-2 on
Aug 20, 2008; 10:10am
URL: http://quantlib.414.s1.nabble.com/Error-calling-xlfGetDef-Excel-API-function-from-Objecthandler-s-FunctionCall-callerName-tp12192p12195.html
Hi Slava,
On Tue, August 19, 2008 19:53, Slava Mazur wrote:
> Thank you for the information and for the insides of ObjectHandler
functionality which have been really helpful to pinpoint the problem.
OK! I'll help however I can to promote the use of OH as a standalone app.
> 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.
ObjectHandler is not as badly broken as that! ;)
Try an experiment:
- Start Excel
- Load your favorite OH-derived XLL - ExampleXLLStatic, QLXL,
your own app, whatever
- In cell A1, create an object with ID foo
- In cell A2, create an object with ID foo
The constructor in A2 fails with this error message:
ohCustomer - Cannot create object with ID 'foo' in cell
[exampleStatic.xls]Feuil1!L2C1 because an object with that ID already
resides in cell [exampleStatic.xls]Feuil1!L1C1
See RepositoryXL::storeObject().
All the QLXL constructors have an autogenerated parameter Overwrite which you
can set to True if you really want to do that.
> 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()).
idFull_ takes the form abcd#0000 where
1) abcd is either the string supplied by the user, or the value obj_12345
generated by OH if the user passed a null string. As far as the user is
concerned, the 12345 is just a value which OH guarantees to be unique. In
practice it is the key of the calling range.
2) 0000 is the update count for the calling range
As explained above, 1) is guaranteed to be unique, whether the value is
provided by the user or autogenerated by OH.
But note that 2) is for informational purposes only and we don't rely on the
uniqueness of 2) to ensure the uniqueness of idFull_. Any time an object ID
is used for internal processing, it is passed to getStub() which strips off
the #0000 suffix if present.
Also class ObjectXL last appeared in OH version 0.9.0 and is replaced by
ObjectWrapperXL in 0.9.6. Once you get down to implementation you will
probably want to work from the svn trunk.
> 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()).
Yes, an autogenerated ID is guaranteed unique by incorporating
CalingRange::key(), which I represented as 12345 above.
> 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.
Based on the above I think no fix is necessary, unless you have found a bug
which breaks the test I described. Your resolution would be effective in such
a situation, though I wouldn't use it as a permanent solution since I think
the user would be surprised to find his key altered. I understand you have
this as just a quick fix.
> 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.
I haven't explicitly set out to hide keys from the user. They can be accessed
by function ohObjectCallerKey() and are written to the log file by function
ohLogAllObjects(). I find that very helpful for troubleshooting but I doubt
anyone else ever used it so yes in general the keys are not displayed to the
user.
Again I think that the uniqueness of object IDs is already enforced, without
the need to make updateCount unique. Please review this and let me know - if
you have found a bug in the current implementation then we can work out a fix.
> 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.
No hurry at all. I'm glad to hear that the early signs are encouraging and I
look forward to getting into the details when the time comes.
Regards,
Eric
-------------------------
Eric Ehlers
nazcatech sprl | Brussels |
http://www.nazcatech.beDistributed computing for pricing analytics - Use Microsoft Excel as a client
to the Grid
-------------------------------------------------------------------------
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