Download it now!
Bug 69795 - Macros: Copying a cell form one table to another looks different on Windows
Summary: Macros: Copying a cell form one table to another looks different on Windows
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
Version:
(earliest affected)
4.0.4.2 release
Hardware: Other Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords: preBibisect, regression
Depends on:
Blocks: Macro-VBA
  Show dependency treegraph
 
Reported: 2013-09-25 08:30 UTC by bugs.kde.attila
Modified: 2020-07-27 08:35 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot of source cell, destination cell on Linux, destination cell on Win 7 (13.74 KB, image/png)
2013-09-25 08:30 UTC, bugs.kde.attila
Details
File with macro 2.ott (38.69 KB, application/vnd.oasis.opendocument.text-template)
2014-04-01 13:24 UTC, bugs.kde.attila
Details
File 3.odt (30.83 KB, application/vnd.oasis.opendocument.text)
2014-04-01 13:26 UTC, bugs.kde.attila
Details

Note You need to log in before you can comment on or make changes to this bug.
Description bugs.kde.attila 2013-09-25 08:30:28 UTC
Created attachment 86522 [details]
Screenshot of source cell, destination cell on Linux, destination cell on Win 7

Problem description: 

The command
"DestCell.String = SourceCell.String"
reproduces a different result.


Steps to reproduce:
1. Open an .ott file you would like to edit. The file includes a table with some cells (lets call it destination).

2. Execute the macro which comes with this file.

3. The Macro does the following: It opens another .odt file (lets call it Source) as hidden. A Procedure is searching for a certain cell within a table in the hidden source file. If the cell is found, it will be copied to the destination file into a cell like

DestCell.String = SourceCell.String

Both cells has the same format.

Current behavior:
The copy of the destination cell looks different from the source cell. It contains after each line a "newline".

Expected behavior:
The copy of the source cell should not look like different.

Additional info:
The macro is working as expected on Linux (4.1.0.4) and MaxOS (4.1.1) except on Windows. On Windows 7 I tried the latest version (4.1.1.2)  too with no success.

Operating System: Windows 7
Version: 4.0.4.2 release
Last worked in: 3.6.7.2 release
Comment 1 bugs.kde.attila 2014-01-30 09:47:46 UTC
Today I did an update to LibreOffice 4.1.4.2 on Windows 7. The bug is still there.
I did not get any response until today. Is there anything I can do to help? Additional info?
Comment 2 Andras Timar 2014-03-26 11:50:16 UTC
(In reply to comment #1)
> Today I did an update to LibreOffice 4.1.4.2 on Windows 7. The bug is still
> there.
> I did not get any response until today. Is there anything I can do to help?
> Additional info?

You did not attach the file with macro. Only the screenshot is there. Also, please explain, why it is a regression. Was it good in earlier releases? Which one is the last release, when it was good?
Comment 3 bugs.kde.attila 2014-04-01 13:21:49 UTC
Here a little instuction for how to reproduce the bug.

- Please open the attached file "2.ott"
- Execute the macro
- Select in the "open" dialog file "3.odt"
- Check the result in column "Artikel" and compare it with the content from file "3.odt"

For the inspection, focus on the function "UebertrageQuellDaten", row "DestCell.String = Cell.String"

To your questions: This is not a regression, this is a bug. You get a different result on Linux and Windows, when you copy a text from one document to another. This problem never appeared on Linux or Mac.
The last working version on Windows was OO 1.1.4 (I know, it is been a while, but now I have to use the macro some times on Windows again). That is what I can tell you about running the macro on Windows. It is possible that a version in between on Windows was also good.
Comment 4 bugs.kde.attila 2014-04-01 13:24:06 UTC
Created attachment 96719 [details]
File with macro 2.ott
Comment 5 bugs.kde.attila 2014-04-01 13:26:38 UTC
Created attachment 96721 [details]
File 3.odt
Comment 6 QA Administrators 2014-11-02 16:46:22 UTC Comment hidden (obsolete)
Comment 7 raal 2014-11-06 20:20:03 UTC
I can confirm with Version: 4.3.2.2, win 7. No problem on linux.
Comment 8 bugs.kde.attila 2015-11-19 08:54:47 UTC
Dear developers,

I am asking myself right now whether it does make a sense to report bugs. Please don't get me wrong. I don't reply to rant. It's been more then two years ago since I reported my bug. If you can't or don't want to fix this bug, that's OK. I can live with that. In this case please close this bug report, otherwise give me a sign.
Comment 9 raal 2015-11-19 09:05:02 UTC
Hello, unfortunatelly there is no predictable time when bugs will be fixed.
Comment 10 Robinson Tryon (qubit) 2015-12-10 01:28:49 UTC Comment hidden (obsolete)
Comment 11 Xisco Faulí 2016-09-13 10:49:26 UTC
This regression was introduced before branch 4.4, thus it can't be bibisected with the current bibisect repositories. Changing keyword 'notBibisectable' to 'preBibisect'
Comment 12 QA Administrators 2018-07-06 02:46:13 UTC Comment hidden (obsolete)
Comment 13 QA Administrators 2020-07-06 03:34:00 UTC Comment hidden (obsolete)
Comment 14 bugs.kde.attila 2020-07-27 08:35:12 UTC
No changes, the bug is still there.