Created attachment 183218 [details] The demo announced in the report The CurrentController of a drawing model claims to support the service 'DrawingDocumentDrawView' which in turn is specified to export the interface 'XTransferableSupplier'. It doesn't - and never did, as far as I could see. Background: In pursuit of a question in the ask site I tried to use "flavor conversion" via a helper drawing. The attenmpt faild in consequence of the bug. To reproduce the bug do as described in the attached drawing which also contains the Sub: Sub demo() cCtrl = ThisComponent.CurrentController MsgBox(cCtrl.SupportedServiceNames(0)) REM cCtrl should export the interface XTransferableSupplier REM See https://api.libreoffice.org/docs/idl/ref/interfacecom_1_1sun_1_1star_1_1datatransfer_1_1XTransferableSupplier.html For Each shape In ThisComponent.DrawPages(0) If shape.String="Ellipse" Then Exit For Next shape cCtrl.select(shape) MsgBox(shape.String) trans = cCtrl.getTransferable() REM cCtrl doesn't know the method. REM Trying to order cCtrl.insertTransferable(trans) (with a valid object trans gotten elsewhere) shows that cCtrl also doesn't know the second method. End Sub
Yes, I get BASIC runtime error. Property or method not found: getTransferable Arch Linux 64-bit, X11 Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9a930ef9ea45277109c9acd6e7e1ccfe47fe136c CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 27 February 2023
DrawingDocumentDrawView inherits XTransferableSupplier from css::frame::Controller, which has it marked as optional: https://git.libreoffice.org/core/+/3ffd375f/offapi/com/sun/star/frame/Controller.idl#77 (i.e. not every implementation has to support it).
(In reply to Maxim Monastirsky from comment #2) > DrawingDocumentDrawView inherits XTransferableSupplier from > css::frame::Controller, which has it marked as optional: > https://git.libreoffice.org/core/+/3ffd375f/offapi/com/sun/star/frame/ > Controller.idl#77 (i.e. not every implementation has to support it). Might there be an enhancement one day?