Download it now!
Bug 70947 - Incompatible API changes between versions: provide better support, information at runtime, .. for all API users
Summary: Incompatible API changes between versions: provide better support, informatio...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on: 70949
Blocks: UNO
  Show dependency treegraph
 
Reported: 2013-10-28 08:19 UTC by tim
Modified: 2018-06-17 19:12 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tim 2013-10-28 08:19:41 UTC
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.
Comment 1 Cor Nouws 2013-10-28 08:51:16 UTC
Hi tim,

What information channels/means would you suggest?
Are you aware of what is currently done to inform users/developers?

thanks,
Cor
Comment 2 tim 2013-10-28 09:01:22 UTC
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.
Comment 3 Cor Nouws 2013-10-28 09:08:51 UTC
thanks Tim. Is the summary as I made it now fine for you?
Cor
Comment 4 tim 2013-10-28 09:28:33 UTC
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.
Comment 5 Lionel Elie Mamane 2013-10-28 09:29:20 UTC
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.
Comment 6 Stephan Bergmann 2013-10-28 16:09:57 UTC
(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.