https://bugs.documentfoundation.org/show_bug.cgi?id=145725
--- Comment #7 from Mike Kaganski <[email protected]> --- (In reply to Wolfgang Jäger from comment #6) > I feel lost considering the consequences for users Of VBA in > LibO generally. And what would be the effect if LiBO running code under > VBAsupport 1 Would revert the byte order for the RGB result to its own > habit. Where are RGB results ever exported to the file except when assigned > to a colored object? The visible color is interpreted the LibO way, of > course, and written after encoding it the LibO way. This is a very good concern. MS RGB implementation follows MS COLORREF datatype [1]. So whenever one wants to use the color value in a WinAPI call (which is rather common in VBA), or when one works with file IO, it may be crucial to use specific byte order. So in compatibility mode, there's an interoperability with Windows API, but lack of interoperability with own API working with colors. OTOH, there's unclear aspect of cross-platform operation. WinAPI (and VBA) are likely defined in terms of their (only) endianness? Which is little-endian (even NT on Alpha was little-endian). Then on big-endian platforms, the byte order should be reversed. Anyway, I'd simply document it carefully in help (the documentation in code is already done by Julien), and right there in the help would suggest a recommended code that would not depend on the compatibility mode. [1] https://docs.microsoft.com/en-us/windows/win32/gdi/colorref -- You are receiving this mail because: You are the assignee for the bug.
