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: 2018-07-06 02:46 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
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug