Bug 140093 - Latest input not considered when PRINTING a Calc sheet
Summary: Latest input not considered when PRINTING a Calc sheet
Status: RESOLVED DUPLICATE of bug 38003
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.1.0.2 rc
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-02-02 14:47 UTC by cpohle
Modified: 2021-02-02 21:14 UTC (History)
0 users

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description cpohle 2021-02-02 14:47:35 UTC
Description:
When printing a Calc sheet while the cursor is still in a cell just edited, the old value is printed, thus the hardcopy shows different content than the screen.

Steps to Reproduce:
1. Enter some VALUE in a Calc sheet
2. Move the cursor/focus to anonther cell
3. Change the value in the cell from step #1 to some OTHERVALUE
4. Without moving the focus from the cell showing OTHERVALUE, print the sheet.

Actual Results:
The printout reads "VALUE"

Expected Results:
The printout should read "OTHERVALUE"


Reproducible: Always


User Profile Reset: No



Additional Info:
When initiating the print process, the focus should be pulled from the last cell edited.
Comment 1 Eike Rathke 2021-02-02 17:53:47 UTC
"Without moving the focus" means you don't even press Enter to have the input accepted as cell content? Then of course it is not printed because printed are cell contents. It's debatable whether invoking Print should close the input and write the pending input to cell content (and then of course also recalculate dependencies) without the user having said so.
Comment 2 cpohle 2021-02-02 20:58:34 UTC
(In reply to Eike Rathke from comment #1)
> "Without moving the focus" means you don't even press Enter to have the
> input accepted as cell content?

That's correct.

> It's debatable whether invoking Print should
> close the input and write the pending input to cell content (and then of
> course also recalculate dependencies) without the user having said so.

Not closing the input seems counter-intuitive, as the consequence (and current behaviour) is a difference between what you see on the screen and what you get on paper. Which is really bad if you print to a remote device (like a printer in another room or a fax device), leaving no chance to notice the mistake (as happened in our office).
Comment 3 cpohle 2021-02-02 21:14:49 UTC
Sorry, just discovered Bug #38003 - this is a duplicate

*** This bug has been marked as a duplicate of bug 38003 ***