Community
Participate
Working Groups
I20050209 The primary selection feature is neat, but it kills me when debugging: since my debug target workbench always changes the selection when typing, I will run into bug 44915 whenever I debug text editor stuff. Bug 44915 has not been a problem any more until the primary selection feature was added, so I blame it on that... Until I can disable that, I cannot debug any more - just had it four times in a row. -- My stack dumps ususally look like: "main" prio=1 tid=0x0805bcb0 nid=0x64d7 runnable [0xbfffc000..0xbfffd508] at org.eclipse.swt.internal.gtk.OS._gtk_clipboard_wait_for_contents(Native Method) at org.eclipse.swt.internal.gtk.OS.gtk_clipboard_wait_for_contents(OS.java:3361) at org.eclipse.swt.dnd.Clipboard.gtk_clipboard_wait_for_contents(Clipboard.java:613) at org.eclipse.swt.dnd.Clipboard.getContents(Clipboard.java:289) at org.eclipse.swt.dnd.Clipboard.getContents(Clipboard.java:236) at org.eclipse.debug.internal.ui.actions.breakpointGroups.PasteBreakpointsAction$1.run(PasteBreakpointsAction.java:101) at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:147) at org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:28) at org.eclipse.swt.widgets.Display.syncExec(Display.java:3189) at org.eclipse.debug.internal.ui.actions.breakpointGroups.PasteBreakpointsAction.updateSelection(PasteBreakpointsAction.java:97) [...]
You say that the target workbench always changes the selection when typing: what do you mean by that? The PRIMARY clipboard won't be updated by Eclipse unless you highlight some text with the mouse. Also, I am confused a bit by your stack trace. Are you trying to paste something, or is the paste breakpoint action checking the clipboard too often (similar to bug 78450)?
I guess I should not be making assumptions about why this is happening, I really don't know whether it is the primary selection feature or something else. It is always the breakpoint action updater that hangs, though. And I only saw it when I triggered the breakpoint upon a keypress, that's why I figured it would have to do with the selection. Thinking of it, it always happened when pressing return in the editor, which causes a call to StyledText.setSelectedRange internally (because of the auto-indenter).
AFAICT, StyledText.setSelectionRange does not set the clipboard contents. You have to actually select text with your mouse to have the clipboard get set. Regardless, if the breakpoint action is checking clipboard contents without you explicitly hitting paste, I think this is a bug in the breakpoint action.
ok, let's bug debug a little... Moving to debug for commenting on the breakpoint action update.
Fixed in PasteBreakpointsAction and BreakpointsView. The action only updates when the selection changes and the view has focus, or when the view regains focus.
Changes to PasteBreakpointsAction and BreakpointsView.
Why can it not only update when the user hits paste (or, why does it need to update its state at all)?
Adding DW for last comment
We update the state so that the action has proper enablement in the context menu, when the menu is realized. Otherwise the action will always be enabled and may/may not have an effect.
I'm going to re-open this then. It is still too easy to hang on Linux. Here are the steps I used with I20050215-0800. 1. With the following application, put a breakpoint on the line with the call to shell.open(). 2. Debug. Eclipse stops at the breakpoint. 3. Click on the tab for the breakpoints view. 4. Eclipse will now hang. It would be better to have Paste always enabled in the menu than to hang waiting for the application which owns the clipboard to respond. public static void main(String [] args) { Display display = new Display(); Shell shell = new Shell(display); Text text = new Text(shell, SWT.BORDER); text.setText("Please copy this text"); text.setSelection(0, 10); text.copy(); shell.open(); while(!shell.isDisposed()) { if(!display.readAndDispatch()) display.sleep(); } display.dispose(); }
OK, will fix for M5. It's unfortunate, but the paste action will always have to be enabled.
released to noon build.
please verify, Luc.
If bug 39369 is fixed, we may have a way to solve problems like this in a more sane way.
Verified.
I removed the unnecessary Clipboard passing to the constructor of the action (and the unread private field it was stored in). Changes to BreakpointsView and PasteBreakpointsAction
