A tip:
Apply predefined Cell Styles by your macro instead of copy/pasting manual (direct) formatting properties. Use API functions only.
I thought to this already. But, as there are plenty of various formats applied, this appears to be unpractical. I guess that if I can’t copy formats globally, I’ll have to do that in the end.
Thanks!
You must create exactly same number of directly formatted cells (to copy) as you need number of Cell styles (to apply).
Yes… (sigh)
For me with freshest V 7.5.0.3 under Win 10 both your Sub work as expected. Did you (@jfn) actually test with this version under this OS?
I added nonetheless an API-only version (not actually recommended!).
To do it API-only without a back-paste of original content would require to clone “all” attributes. I made an attempt to do so in a similar case with portions of Writer text based on the PropertySet. Basically that works, but it requires to know in detail whitch steps are capable of introducing unwanted defaults… It’s hard work.
test_copy_formats_completed.ods (31.4 KB)
1 Like
@jfn, thanks for a very interesting example!
In my LibreOffice, the error is reproduced if, for example, information is copied to the clipboard from Firefox, and then any of your macros is executed.
If I remove the buttons to run macros, then the error seems to disappear. What about you?
LO 7.4.2.3 Win 10.
If “you” is “me” (@Lupp): I didn’t test with different versions or in different environments. During the mentioned tests everything worked as well whether running the code from the IDE or as onExecute for a button.
May there any ClipboardManager have interfered?
You may also check if I probably changed a tiny detail in the code inadvertently.
Dear @Lupp, I make the same mistake over and over again, assuming that the default address of any message is the topic author. I will be more careful in the future. 
I also suspected the clipboard manager (I even wrote in my first deleted message), but it turned out to be much more serious.
Thanks a lot Lupp! Your v3 test works great under LibreOffice 7.3, LinuxMint 20.3 Cinnamon.
I remain now to test it in my “real world” app 
Will report here asap.
I didn’t yet regard this information, but tested now with Firefox as the source used with the most recent copy operation - and can confirm your result. Additional test confused me additionally.
There’s something everything rotten in the state of Denmark world of IT!
The situation looks threatening, since the “.uno:Copy” command is widely used in macros and has no equivalent in the UNO API (as far as I know).
If, nevertheless, the controls are to blame, then the threat can be localized.
Works great also in my “real world” spreadsheet where there are currently 200 rows to copy (might go up to 1000-1500 no more). And things are fast enough on my old X240 laptop.
BTW, this made me discover the get/setFormulaArray methods I had never used before (things have to start, some day).
I owe you a beer!
Also, I think I’d declare a bug about the .uno:Copy thing, shouldn’t I?
In my opinion, no doubt. And please report the bug number (tdf#000000) here.
You surely know that there is XTransferable storing to a transferable object that will have the same (or very similar) structure as a clipboard content - reduced to flavors of interest for LibreOffice probably.
But I don’t know (e.g.) how to restrict the .insertTransferable(oneTransObject) to attrributes only. getTr/setTr inside the sheets of the same model are therefore substituted copyRange method.
Visit München!
There is then a second beer on my bill - and if it suits also white sausages…
1 Like
Possibly this could be implemented by a combined approach, creating XTransferable, and then setting system clipboard’s content using XClipboard::setContents.
1 Like
A generic implementation XTransferable.insertTranferableWithRestrictions(trans, restri) might be preferrable.
Well fixed .uno slots may also do (though I don’t like the dispatcher).
Some after thoughts
@sokol92 Following Mike’s responses in the bug report, it seems I had wrongly tested your suggestion about the button… You were in fact on the good track and I missed it. Sorry for that and thanks! I had not realized that the focus interferes with data selection 
Anyway, @Lupp’s solution is better fit because there’s no UI interference then.
Sokol92 and Lupp, thank you again for your comments. That helped very much and I learned new things!
1 Like