Bugzilla – Full Text Bug Listing
| Summary: | [StyledText] StyledText incorrectly handles DND.ERROR_CANNOT_SET_CLIPBOARD | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Adam Kiezun <akiezun> |
| Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | Felipe Heidrich <eclipse.felipe> |
| Severity: | normal | ||
| Priority: | P3 | CC: | daniel_megert, snorthov, veronika_irvine |
| Version: | 2.0 | Keywords: | triaged |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | stalebug | ||
|
Description
Adam Kiezun
Agree that StyledText shouldn't just catch all SWTErrors. However, when we fixed PR 1GDQAVN we decided that StyledText should ignore errors and continue when a text copy to clipboard fails because this is a common scenario. Other apps silently fail as well(tried Wordpad and Word). As described in 1GDQAVN the last copy operation wins if there is a conflict. I don't think we should change this, so 2b won't be addressed. I don't see 2a as a major problem since ERROR_CANNOT_SET_CLIPBOARD is the only exception Clipboard.setContents throws, assuming we don't pass in incorrect arguments. Relevant excerpt from 1GDQAVN: ----------------- KR (5/16/01 2:34:25 PM) The clipboard throwing an ERROR_CANNOT_SET_CLIPBOARD exception because of an OS error seems to be the same as, for example, List.getItem throwing ERROR_CANNOT_GET_ITEM. Apparently Eclipse does not catch SWTErrors. Normally it should display an error message box, log the error and continue. If an unexpected error were to occur in List.getItem() Eclipse would probably crash, too. That aside, it seems that the clipboard error can happen a lot easier than other unexpected errors. I.e., open two SwtStyledTextUseCases, load a big file (1 MB) in one of them, copy the entire text to the clipboard, as soon as you pressed ctrl+insert to copy switch to the other use case and copy as well. The first use case will crash. I don't think we should do anything when there is a conflict accessing the clipboard. I.e., if the clipboard operation doesn't work because someone else interrupted us don't complain and just continue . If you try the above with wordpad (copy a large file and copy some other text) wordpad will just loose the clipboard and your second copy operation will succeed. LK (5/15/01 11:33:52 AM) It makes sense to me that conflicts when accessing the clipboard should be handled below StyledText. If not, any application using the clipboard will have the same problem. Last one wins seems like the way to handle it (e.g., like wordpad above). McQ (28/05/2001 2:19:02 PM) - LK to catch the exception and silently fail. See discussion above as to why we won't fix this. The only interesting question here is why copy fails more on Linux, which is a general SWT clipboard issue. silently swallowing serious errors is always a very bad thing, imo Fixed the rethrowing of errors other than ERROR_CANNOT_SET_CLIPBOARD. Reopening to reconsider. We augment cut/copy in JDT land to add additional info to the clipboard so that we can offer smart paste (e.g. adding imports). We now have a hole in our code because we get no feedback from StyledText.cut() and StyledText.copy() operations. I agree that silently failing is always bad. Not sure what to do. We can't change API for 3.1. Daniel / Steve: What do you guys want me to do here ? Daniel: This is two years old, do you still care ? Steve: if we can't break API just close this PR for me. Note: this is a very minimal break, the method already throws SWTError anyway. My vote is to fix this, throw all exceptions up. Can we change the signature to return true/false without breaking binary compatibility? If this is really important, a new API can be added getLastClipboardError() or something stupid like that. Personally, I'd close this as WONTFIX. >Daniel: This is two years old, do you still care ?
Yes I do and I vote to fix it. Getting no error at all might also be the cause for the several "copy/paste doesn't work" bugs in SWT land.
Your bug has been moved to triage, visit http://www.eclipse.org/swt/triage.php for more info. This is a one-off bulk update. (The last one in the triage migration). Moving bugs from swt-triaged@eclipse to platform-swt-inbox@eclipse.org and adding "triaged" keyword as per new triage process: https://wiki.eclipse.org/SWT/Devel/Triage See Bug 518478 for details. Tag for notification/mail filters: @TriageBulkUpdate This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |