Community
Participate
Working Groups
Although unable to force the behavior, it happens often enough to be a serious issue. I type the first few characters of something, followed by CTRL-SPACE to pop code assist, then arrow down to the selection I want and hit <return>. 90% of the time it does as it is supposed to do. 10% of the time, some (or all) of the editor's characters are replaced with junk characters (like trying to view a .dll in notepad).
Can you attach a screenshot? Moving to JDT/Text
Created attachment 2873 [details] before corrupted display and after This is an example of what happens to the editor.
I most recently had this issue after using the right-click menu item "Format".
Daniel, can you please have a look. This seems to be a strange error. Unclear if this is Text or SWT related.
Charles, this seems to be a major bug but I can't reproduce it. You say " it happens often enough to be a serious". Could you try to give a test case? Can you confirm that it only happens after you have used code formatter? Did you change any preferences? If so, could you export and attach your preferences as an .epf file? Could there be some line delimiter problems i.e. has the file been modified with another editor or on another OS (e.g. Linux or Mac)?
Created attachment 2906 [details] Charles Hasegawa preferences export Preferences file as requested
>this seems to be a major bug but I can't reproduce it. You say " it happens often enough to be a serious". Could you try to give a test case? I've tried to replicate this behavior myself, and have been unsuccessful at reproducing this at will. I would love to be able to tell you how to reproduce the bug (then I could stop doing it until it is fixed ;)) I understand its impossible to fix a bug if you don't know where to look for it. > Can you confirm that it only happens after you have used code formatter? No, it happens frequently after a format, but just as often after using code assist. > Could there be some line delimiter problems i.e. has the file been modified with another editor or on another OS (e.g. Linux or Mac)? The files are shared through CVS and some files would have been modified in Linux, however, I generally do not work on those files that are modified by the people who use a linux environment.
I tried to reproduce it - no luck. No one has seen it before. Did you select a template or a "normal" completion when it happened using code assist? I see that the code formatter is used for templates. I suspect the problem in the code formatter but as long as we don't have the test case/file which causes it there's nothing we can do. Next time you see it please reopen the bug and add all the information you can provide (including the file which causes the error).
Created attachment 2912 [details] Class to show this bug
Finally able to replicate this bug at will on my system (I hope this works for you as well). 1) Open the file. 2) In the outline view, select the class name (which should hide the comments and imports et al above the class definition. You should basically see : /** * @author Charles Hasegawa */ public class BugHunt implements Serializable, Cloneable, Enumeration, Comparable, Iterator { /** * @see java.util.Enumeration#hasMoreElements() */ public boolean hasMoreElements() { return false; } .... } 3)From any other source, copy the word "ListModel" to the clipboard 4) Click on the end of the word Iterator and type (no quotes) ",<CTRL-V>" 5) ListModel should now be underlined as a compile error - type "<CTRL-SPACE>" - the display will barf everytime for me.
Well, I can finally reproduce it now. Please confirm that you also get errors written to the log (either check the Error Log view or the .log file).
Yes - specifically: !ENTRY org.eclipse.ui 4 4 Jan 07, 2003 10:28:09.281 !MESSAGE Unhandled exception caught in event loop. !ENTRY org.eclipse.ui 4 0 Jan 07, 2003 10:28:09.281 !MESSAGE Failed to execute runnable (java.lang.IllegalArgumentException: Argument not valid) !STACK 0 org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.IllegalArgumentException: Argument not valid) at org.eclipse.swt.SWT.error(SWT.java:2180) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages (Synchronizer.java:97) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:1669) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1414) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1446) at org.eclipse.ui.internal.Workbench.run(Workbench.java:1429) at org.eclipse.core.internal.boot.InternalBootLoader.run (InternalBootLoader.java:845) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:462) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.launcher.Main.basicRun(Main.java:247) at org.eclipse.core.launcher.Main.run(Main.java:703) at org.eclipse.core.launcher.Main.main(Main.java:539) !ENTRY org.eclipse.ui 4 4 Jan 07, 2003 10:28:09.281 !MESSAGE *** Stack trace of contained exception *** !ENTRY org.eclipse.ui 4 0 Jan 07, 2003 10:28:09.281 !MESSAGE Argument not valid !STACK 0 java.lang.IllegalArgumentException: Argument not valid at org.eclipse.swt.SWT.error(SWT.java:2166) at org.eclipse.swt.SWT.error(SWT.java:2110) at org.eclipse.jface.text.DocumentAdapter.getLineAtOffset (DocumentAdapter.java:118) at org.eclipse.swt.custom.StyledText.getLineAtOffset (StyledText.java:3760) at org.eclipse.swt.custom.StyledText.getLineCount(StyledText.java:3716) at org.eclipse.jdt.internal.ui.javaeditor.OverviewRuler.doPaint (OverviewRuler.java:345) at org.eclipse.jdt.internal.ui.javaeditor.OverviewRuler.doubleBufferPaint (OverviewRuler.java:323) at org.eclipse.jdt.internal.ui.javaeditor.OverviewRuler.redraw (OverviewRuler.java:520) at org.eclipse.jdt.internal.ui.javaeditor.OverviewRuler.access$1 (OverviewRuler.java:517) at org.eclipse.jdt.internal.ui.javaeditor.OverviewRuler$5.run (OverviewRuler.java:507) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:31) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages (Synchronizer.java:94) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:1669) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1414) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1446) at org.eclipse.ui.internal.Workbench.run(Workbench.java:1429) at org.eclipse.core.internal.boot.InternalBootLoader.run (InternalBootLoader.java:845) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:462) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.launcher.Main.basicRun(Main.java:247) at org.eclipse.core.launcher.Main.run(Main.java:703) at org.eclipse.core.launcher.Main.main(Main.java:539)
ok, I now found a small reproducible test case in our environment: Build 20021218 (M4) 1. Start empty workspace 2. Create Java project and import JUnit 3. Open TestCase.java 4. !!! Remove the empty line between the last import and the class comment 5. Enable "Show Source of selected element only" 6. In the Outline click on TestCase 7. Give the focus to the editor by clicking into it 8. Ctrl+Shift+O (organize import) 9. Select some text or type into the editor ==> it is destroyed Note: formatting does not show this behavior, only organize imports The DocumentAdapter seems to get out of synch with the StyledText widget
After reviewing DM's last entry, I concur that formatting doesn't appear to cause this behavior, but rather changing the imports through code assist or organize imports seems to be the culprit. I assumed it was the formatter, as I usually do an organize imports followed immediately by a format. All instances of this behavior I have seen today all occured after a change to the imports.
This bug was not in 2.0 but in 2.1-M1
This bug surfaced a special case were the replaced text region was directly before the visible text region. Fixed in ChildDocumentManager.adaptToInsert Available in builds > N20030109
start verifying
