|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | warn before pasting into "too many" cells | ||
|---|---|---|---|
| Product: | Calc | Reporter: | jamescrompton <james> |
| Component: | editing | Assignee: | AOO issues mailing list <issues> |
| Status: | CONFIRMED --- | QA Contact: | |
| Severity: | Trivial | ||
| Priority: | P2 | CC: | amy2008, andre.schnabel, aoo-bugs, clarence.guo.bj, discoleo, donjaime, issues, kai_m_ooo, lars_o_hansen, mh.hh, niklas.nebel, ooo.redflag, steve.m.frank, zgbrown07 |
| Version: | OOo 2.0 | Keywords: | oooqa |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | ENHANCEMENT | Latest Confirmation in: | --- |
| Developer Difficulty: | --- | ||
|
Description
jamescrompton
2005-12-16 16:09:03 UTC
Writer hangs but this is only because it needs a such long time to paste in all the cells... closing User stupidity should not be permitted to cause a hang and consequent data loss. If you don't see this as a defect, maybe reclassify it as a request for an enhancement: confirmation should be sought for pasting into more than (say) 100000 cells. Or at least there should be a progress dialog with a cancel button. RFE: warn before pasting if operation is likely to take a long time, use up all available memory or make Calc unresponsive JA->NN: is there something we can do for 2.0.3 ? Added you to CC list. There has been some discussion about this on the QA Dev list, so I decided to try it for myself. After examining the situation, I would recommend reclassification as a defect. The defect summary would be "pasting into all cells in a workbook causes OOo Calc to hang." Here is my reasoning: In Excel, I typed "asdf" in a single cell, then copied that cell to all other cells. An hourglass appeared, then a progress dialog in the lower left corner of the Excel sheet. The progress dialog lasted until the operation completed, which took about 15 seconds. After 15 seconds every cell in the sheet had "asdf" in it without too much trouble. In Calc, I tried the same thing. I noticed the lack of a progress bar right away, which is what the RFE would be for. BUT, what really got me was the length of time it took to perform the paste! I decided to let Calc run until the paste completed, which was a mistake. 15 minutes later, Calc was still running and Windows gave me a "virtual memory low" error. At that point, I thought I had better cancel the operation in Calc, but there was no way to cancel. So I decided to kill Calc by clicking close... that didn't work. So I used CTRL+ALT+DELETE. Calc didn't respond to that either. Plus, it must have kept right on eating memory, because pretty soon Excel and Firefox, which had been idling in the background, crashed too. At this point I just rebooted, but even that operation took about 8 minutes to complete because of the low memory availbility during shutdown. So, I would say this is a defect. Expected Behavior: Calc should copy the contents of a single cell into the contents of the entire worksheet within a reasonable time frame, or should cancel the operation when it runs out of memory. Reasonable is defined here as within 1 or 2 minutes on a P4 machine w/ 512 MB RAM. (2 minutes would make Calc about 8 times slower than Excel, but that's still reasonable.) Actual Behavior: Calc begins the copy operation but never completes it. Instead, it continues to use up system memory until the entire system slows to a crawl or crashes altogether. Additional Notes: Calc seems to exhibit the same behavior when copying to multiple entire columns as well, which is a more likely scenario anyway. Also, maybe OS should be changed to Windows? Does OOo do this on Linux/BSD/Solaris? *** Issue 39839 has been marked as a duplicate of this issue. *** I'll file a new issue for the fact that Calc needs so long to paste into all cells as this one is about a warning only now. -> Issue 62878 (and sorry for not finding the other duplicates). Crashing is definitely a BUG. However, what wonders me is that when I select everything (ctrl + A), Calc would select only the range A1:Y68 on an empty sheet, yet when I paste, it tries to paste well beyond this range. Actually, the range gets incremented over and over again. What is the limit? What should this "maximum range" be? I would opt for something like: 1.) either A1:Y68 as currently (or some other small value) 2.) in case of a non-empty cell: up to the last row/column that is non-empty 3.) open dialog box and ask user how many rows/columns should be filled I would strongly prefer options 2 and 3. don't you think that most users will consider this as a bug (on a low-end computer) or at least an annoyance (on a high-end computer) ? if 0.01% of users need this and consider it as a feature why don't you give them a checkbox in the option dialog ? something like "paste only once when full sheet is selected" default=checked and maybe a confirmation dialog when pasting (with a checkbox "remember my answer") *** Issue 78326 has been marked as a duplicate of this issue. *** A similar bug has been posted on gnumeric's list: http://bugzilla.gnome.org/show_bug.cgi?id=530956 *** Issue 90740 has been marked as a duplicate of this issue. *** (Additional info from issue 90740, courtesy of amy2008, one of our QA Team:) WinXP, BEB300_m2. Reproducing the process: 1. Copy an entire worksheet in Excel 2. Make sure you didn't do Ctrl+A in Calc, then paste it to Calc In this way, I can't reproduce issue 90740 (computer hanging) in BEB300_m2 on WinXP. But if you do Ctrl+A in Calc before pasting the Excel worksheet to Calc, OOo doesn't respond. *** Issue 92095 has been marked as a duplicate of this issue. *** *** Issue 92360 has been marked as a duplicate of this issue. *** *** Issue 86869 has been marked as a duplicate of this issue. *** *** Issue 94132 has been marked as a duplicate of this issue. *** ==> oc I reopend issue 94132, as QA seems to missunderstand the functions in dispute, aswell as the neccessity of being free from data-loss just be using "allowed" functions ( ctrl-A / ctrl-C / ctrl-V ) well, in here it is about the enhencement to make OO.o more verbose for a "I can not do that". so issue 94132 needed to be re-opened for make clear, that cell-copy is defect too. Martin *** Issue 84777 has been marked as a duplicate of this issue. *** Crashing the application when system based memory limitation (eg 4 GB on 32 bit operating systems) is reached from my POV is a DEFECT but adding a warning dialog that is shown in case memory limit is reached is an ENHANCEMENT. I'd like to suggest to change the issue type of this issue to DEFECT because error handling of a crash is more important than adding a dialog. Because this has been reported as a crash I set the Priority field to P2. forgot to modify priority... if change this one to a defect, maybe issue 62878 is a duplicate of this one? *** Issue 94132 has been marked as a duplicate of this issue. *** *** Issue 92361 has been marked as a duplicate of this issue. *** *** Issue 95509 has been marked as a duplicate of this issue. *** *** Issue 97479 has been marked as a duplicate of this issue. *** we now have OO.o 3.0.1 issue is still open for 3,5 years, and still no solutions for the crashes? Note: it crashes both ways, as well from allowed operations (select all and copy and paste) to sensless operations ( select one cell and paste it to an uncounted "select all" at the target) hmm, some should be done with that. Martin *** Issue 97589 has been marked as a duplicate of this issue. *** As to the issue, I think, it is not good idea. when clipboard contains
large table, definitely we must paste all cells in the table. Although maybe
it would cost much time to deal with it, we can not discard anything in the
clipboard. There is no need to warn user when there are too many cells need
to be pasted. What we should do just only remind of user to wait for some
times. In fact, it is enough. If pasting large table has been enhanced in
performanceaspect, any copy&paste operation will be executable and quick.
Wanrning "too many" cells dose not make any sense for us.
I have a plan to resolve this issue, now I am doing some research.
Maybe after two weeks, I will post a patch for it.
ChenJingDong
As to the issue, I think, it is not good idea. when clipboard contains
large table, definitely we must paste all cells in the table. Although maybe
it would cost much time to deal with it, we can not discard anything in the
clipboard. There is no need to warn user when there are too many cells need
to be pasted. What we should do just only remind of user to wait for some
times. In fact, it is enough. If pasting large table has been enhanced in
performanceaspect, any copy&paste operation will be executable and quick.
Wanrning "too many" cells dose not make any sense for us.
I have a plan to resolve this issue, now I am doing some research.
Maybe after two weeks, I will post a patch for it.
ChenJingDong
ChenJingDong, I think you misunderstood this issue, the size of the clipboard doesn't really matter. What matters is the size of the "destination area". What i think would be a simple fix for the most current case : if the "destination area" is a whole sheet, past the clipboard only one time. @ctrlbrk. If a user "select all" and "paste" he normaly has the intention to have the clipboard content in every cell (or block of cells). But maybe he don't know the consequenses of this, he don't see how big is a hole sheet. This is also because the sliders are not proportional if you are at the top of a sheet. In a text document it is more easy. A hole doc is all pages with a letter in (or space or return). In calc it is for a simple user not calculable. So the question is, how big should be the area to paste in (ask the user) or maybe how can it stored more intelligentr (not to store in every cell but store that every cell has content "bla" or that every block of X*Y has that array "a, b, c; d, e, f" as content.) So why not ask the user if a paste operation is requested for a hole table what he realy want? An other possibility is to have a standard table size (which the user can set for every table) and "select all" means that size or (if bigger) all used cells. Anyhow: if an operation needs long (more then i.e. 10 seconds) a status bar and a cancel button is nessesary. And the user should be warned if operations needs huge amount of resources. I can not understand, where the problem is. The function "copy all" has a glitch, as it is copying also the cell-formats to the destination, which causes ther problems, whereas important things are in the cells you can find from A1 to strg-end. That is important to be copied. I have no problems, if a for example a source-column is set to bold or has a surounding, that that stops at the introduced/copied cells-area - if that stops to fear about crashes. my 2 cents Martin *** Issue 104091 has been marked as a duplicate of this issue. *** *** Issue 92171 has been marked as a duplicate of this issue. *** Six years after filing this bug report (under a different name, whose email address no longer exists) I accidentally clicked on the column heading instead of the top cell in the column and didn't realise until I'd hit ctrl-V. Half an hour later, I killed the application. I think it can be safely assumed that most users most of the time do not want to paste into a million rows at once, and that those that do want to do it would appreciate a warning that they won't be able to do anything else for a long, long time. *** Issue 121062 has been marked as a duplicate of this issue. *** *** Issue 127691 has been marked as a duplicate of this issue. *** |