Description: Given the following python code: import uno from com.sun.star.awt.PushButtonType import OK def enum_error(): ctx = uno.getComponentContext() button_model = ctx.ServiceManager.createInstance("com.sun.star.awt.UnoControlButtonModel") button_model.PushButtonType = OK button_model.setPropertyValue("PushButtonType", OK) The penultimate line passes, while the last one raises the following error: <class 'uno.com.sun.star.lang.IllegalArgumentException'>: Unable to convert the given value for the property PushButtonType. Expected type: short Found type: com.sun.star.awt.PushButtonType The workaround is obvious with "setPropertyValue" method, but the convenient and more efficient "setPropertyValues" raises the same error without as efficient alternative, as far as I understand. Steps to Reproduce: 1. Copy and run the small python script above from within a LibreOffice session. Actual Results: Error raised at last line (see error message in above description) Expected Results: Last line should pass without error, as per the penultimate line. Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: fr Module: TextDocument [Information guessed from browser] OS: Linux (All) OS is 64bit: yes
There's PushButtonType.idl with "PushButtonType" enum + UnoControlButtonModel.idl with "PushButtonType" property PushButtonType is defined as a short property but wonder if it shouldn't be "PushButtonType". 2 problems here: - in this case var type and var name would be the same - we would change an interface I tried to find similar examples and noticed: wizards/com/sun/star/wizards/letter/LetterDocument.py:84: xPageNumberField.setPropertyValue("SubType", CURRENT) PageNumber.idl indicates: [property] PageNumberType SubType; and indeed, the line after in LetterDocument.py, shows: xPageNumberField.NumberingType = ARABIC since we got the declaration: [property] short NumberingType; Stephan: as Uno expert, thought you might have some ideas here?
(In reply to Julien Nabet from comment #1) [why don't you give file names with their full paths in the core repo; that would make it easier for others to follow what you write] > There's PushButtonType.idl with "PushButtonType" enum > + UnoControlButtonModel.idl with "PushButtonType" property > > PushButtonType is defined as a short property but wonder if it shouldn't be > "PushButtonType". 2 problems here: Yeah, looks odd to have enum css.awt.PushButtonType but specify property css.awt.UnoControlButtonModel.PushButtonType to be of type short instead;... > - in this case var type and var name would be the same ...and while the duplicated use of identifier shouldn't be a problem... > - we would change an interface ...this certainly would be, as service css.awt.UnoControlButtonModel is published. (The reason why > button_model.PushButtonType = OK happens to work while > button_model.setPropertyValue("PushButtonType", OK) doesn't is because the former is handled by inspection code in PyUNO which implicitly coerces the value on the right to the type expected on the left, while the latter causes PyUNO to pass a UNO ANY containing a css.awt.PushButtonType to native code but which expects a UNO ANY containing a UNO SHORT.)
Thanks both of you for your comments. I understand (I think) why the definition of the interface can't be changed. But I'm not sure at all why this report is marked as "NOTABUG", while it obviously concerns a defect: the error is not the expected behaviour, and doesn't occur with other languages, especially basic and java. Isn't this rather a pyuno bug?
(In reply to jeanmarczambon from comment #3) > But I'm not sure at all why this report is marked as "NOTABUG", while it > obviously concerns a defect: the error is not the expected behaviour, and It is not obvious to me how this is a defect, or how it does not match expected behavior if you take into account how PyUNO turns the "OK" in the last line into a UNO ANY. > doesn't occur with other languages, especially basic and java. Exactly what corresponding Basic and Java code does not exhibit this issue?
> Exactly what corresponding Basic and Java code does not exhibit this issue? I was half wrong. If this basic code rases no error: Sub any_enum_test(): button_model = createUnoService("com.sun.star.awt.UnoControlButtonModel") button_types = com.sun.star.awt.PushButtonType button_model.setPropertyValue("PushButtonType", button_types.OK) print button_model.PushButtonType 'PushButtonType = 1 End Sub Java does indeed need conversion, as shown by this (not tested) snippet from the Developpers's Guide, that helped me for the python code: public XButton insertButton(XActionListener _xActionListener, int _nPosX, int _nPosY, int _nWidth, String _sLabel, short _nPushButtonType){ XButton xButton = null; try{ [...] xButtonMPSet.setPropertyValues( new String[] {"Height", "Label", "Name", "PositionX", "PositionY", "PushButtonType", "Width" } , new Object[] {new Integer(14), _sLabel, sName, new Integer(_nPosX), new Integer(_nPosY), new Short(_nPushButtonType), new Integer(_nWidth)}); [...] I totally forgot the "Short" type conversion. So you were right, this could be the expected behaviour, and the correct Python translation should be something like this (that works): uno.invoke(button_model, "setPropertyValue", ("PushButtonType", uno.Any("short", OK)))