.uno:Copy doesn't copy a given range but uses the clipboard contents

English
#1

Hi!
I’m currently stumbling on a strange problem w/r copying formats between ranges in Calc by macro in BASIC.
I’ve searched numerous sources (the Ask pages, the usual suspects like Andrew Pitonyak’s documentations, etc.) to no avail. The Ask pages I found do not apply to the situation at hand. Not sure whether I’m goofing or there’s something else here.

I attach a demo document showing the problem:
test_copy_formats.ods (31.9 KB)
.
Tested under LibreOffice 7.3.6 under LinuwMint 20.3 Cinnamon
and LibreOffice 7.5 under Windows 10.

Clicking any of the two buttons doesn’t give the expected result. Button v1 code was given by the macro recorder. Button v2 is a mix of API calls and macro recorded.

Expected: C1:C10 range format is copied to B1:B10 range.
Actual result: B1:B10 receives whatever format the clipboard contents hold (see details in the document).
A quick process analyze shows that the problem comes from the .uno:Copy instruction which doesn’t apply.

Can any knowledgeable soul help on this matter?

This is a reduced calc spreadsheet for demo.

The actual overall process is:

  1. Column R is used for data entering
  2. When validated, a column is added to the right (-> S)
  3. and the data in R copied to S
  4. Then the R column contents is cleared, ready for new data.

As (1) R and S have different formats and (2) inserting a column copies the format from the one at its left (iow, at insertion time, S receives the R format), I must update the S format from column T in order to keep the overall aspect.

Everything works OK, except for that format copy.
Please note that, though I am sure a database actually is the solution, I’m given that spreadsheet to handle as-is and can not switch to something else.
Hence the format question…

Thanks for any hint!

#2

A tip:
Apply predefined Cell Styles by your macro instead of copy/pasting manual (direct) formatting properties. Use API functions only.

#4

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!

#5

You must create exactly same number of directly formatted cells (to copy) as you need number of Cell styles (to apply).

#6

Yes… (sigh)

#7

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
#8

@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.

#9

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.

#10

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. :confused:
I also suspected the clipboard manager (I even wrote in my first deleted message), but it turned out to be much more serious.

#11

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 :smile:
Will report here asap.

#12

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!

#13

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.

#14

@Lupp

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?

#15

@sokol92
Nope :frowning: The error doesn’t go away without the buttons.

#16

In my opinion, no doubt. And please report the bug number (tdf#000000) here.

#17

See tdf#153546

#18

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.

#19

Visit München!
There is then a second beer on my bill - and if it suits also white sausages…

1 Like
#20

Possibly this could be implemented by a combined approach, creating XTransferable, and then setting system clipboard’s content using XClipboard::setContents.

1 Like
#21

A generic implementation XTransferable.insertTranferableWithRestrictions(trans, restri) might be preferrable.
Well fixed .uno slots may also do (though I don’t like the dispatcher).

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.