A recent change in LO, version 4.1.1, is incompatible with previous versions, and with OO. Anyone using macros in Basic (or presumably other languages) will have to make changes to take account of this. There will be applications that need to run on both older and newer versions of LO. Rather than have two different versions one would want to have one application that changes its behaviour depending on the LO version. Some changes, such as the one in 4.1.1, can be detected by checking on the type of a data item (in this case the Date changed from a Long to a Struct in controls on forms in BASE). Other changes may be less obvious. There should therefore be functions to obtain information about the version, such as GetOfficeVersion and GetOfficeName and GetOfficeVendor. People can then write code that works on the different versions. For changes to behaviour based on types of data items there should also be simple functions to find out what the data type of an item in a control is. This isn't as easy as it seems, since many items are Variant/Empty when uninitialised and there is no difference in data type until one tries to set the contents. A GetDataType function which works in such cases is required (the Basic vartype function does not suffice). I have been given a lot of help from Lionel Mamane in overcoming the compatibility problems between LO 4.1.1 and previous versions, but a more generic set of facilities should be put in place so that application developers do not need to bother your own developers about such issues. He has worked out ways of detecting the data type change, and the LO version, but there are quite difficult, and very obscure. All such incompatible changes need to be flagged in advance and facilities provided for application developers to make appropriate adjustments.
Hi tim, What information channels/means would you suggest? Are you aware of what is currently done to inform users/developers? thanks, Cor
I'm aware of the release notes. People need to read these before installing new versions. I might suggest that where there's a backwards incompatibility this could be flagged more strongly. However, these notes don't help in writing code compatible with multiple versions of LO (or OO). For that, one needs to be able to detect the change at run-time. That's what I am asking for.
thanks Tim. Is the summary as I made it now fine for you? Cor
Almost OK, but it isn't just for extension developers, it is for anyone writing macros of any sort in their own organisation's applications.
As a matter of example, here is how to detect the alluded to change. 't would be nice if someone posted it on some documentation / FAQ / code snippets website. Dim OOoReflection As Object Set OOoReflection = CreateUnoService("com.sun.star.reflection.CoreReflection") Dim gD as Object Set gD = OOoReflection.forName("com.sun.star.awt.XDateField").getMethod("getDate").ReturnType if gD.TypeClass = com.sun.star.uno.TypeClass.LONG then gbDateIsStruct = false elseif gD.TypeClass = com.sun.star.uno.TypeClass.STRUCT And gD.Name = "com.sun.star.util.Date" then gbDateIsStruct = true else MsgBox "Unknown situation" end if (In reply to comment #0) > There should therefore be functions to obtain information about the version, > such as GetOfficeVersion and GetOfficeName and GetOfficeVendor. People can > then write code that works on the different versions. I agree that having utility functions to easily get version information is good; I disagree that using them to "adapt" code is a good idea. If possible, feature tests (rather than version tests) are more robust. > For changes to behaviour based on types of data items there should also be > simple functions to find out what the data type of an item in a control is. That's exactly what the above code does. The control implements an interface, and that code looks what data type that interface gives. As an example of "other change", if the control used to implement interface XFoo1 but now does not, then that's the "right thing" to test: does it implement interface "XFoo1"? > All such incompatible changes need to be flagged in advance Yeah, that one was rather "last minute". But OTOH, even if we had done it months before release, I'm still not clear on how to announce it in a way that users will notice.
(In reply to comment #5) > > All such incompatible changes need to be flagged in advance > > Yeah, that one was rather "last minute". But OTOH, even if we had done it > months > before release, I'm still not clear on how to announce it in a way that users > will notice. Bug 70667 tries to address that.