https://bugs.documentfoundation.org/show_bug.cgi?id=169229
--- Comment #2 from Stephan Bergmann <[email protected]> --- (In reply to Neil Roberts from comment #1) > I had a go at implementing a patch that would make it possible to pass > uno.Null("com.sun.star.task.XInteractionHandler") below. It’s still not > really ideal so I’m not sure whether it’s worth it. I don’t think it’s > really feasible to make None work in this case because that is already > defined to represent the VOID type and when it’s passed through an Any pyuno > has no way of knowing whether the callee actually wants a void type or not. > > https://gerrit.libreoffice.org/c/core/+/195100 thanks; I commented on the Gerrit change > Maybe another option that would help for the specific case of instantiating > a service could be to make pyuno add class “create” methods for new-style > services like it does when generating headers for C++. That way you could > just call something like StringResourceWithLocation.create(…, None). If > pyuno knows the destination type it can safely convert None to a null > interface. That already happens if you call a regular method that takes an > interface. I will have a go at implementing that too. yeah, service constructors are somewhat orthogonal (the issue of wanting to pass a UNO ANY containing a null interface reference can arise in other contexts, too), but would surely be nice to have, too -- You are receiving this mail because: You are the assignee for the bug.
