Community
Participate
Working Groups
Build ID: M20080911-1700 Steps To Reproduce: 1. Setup a Text widget with a ContentProposalAdapter. Constructor used: (text, adapter, null, null, null); 2. Paste text into the widget using Ctrl-V or right-click and paste. More information: Pasting text does not trigger the auto-activation that I would get by typing the same text into the widget. It appears that the "watchModify" flag in the implementation is not getting set, so the Modify event being triggered by the paste is being ignored. If this is by design, feel free to close the bug. Or any workaround would be welcomed.
Ben, the code below works fine for me on M20080911-1700 and I20090217-2200. Can you modify the snippet so that it fails? ------------------ Display display= new Display(); Shell shell= new Shell(display); shell.setLayout(new FillLayout()); Text text = new Text(shell, SWT.SINGLE); ContentProposalAdapter adapter = new ContentProposalAdapter(text, new TextContentAdapter(), null, null, null); adapter.setContentProposalProvider(new IContentProposalProvider(){ public IContentProposal[] getProposals(String contents, int position) { return new IContentProposal[] { new IContentProposal(){ public String getLabel() { return "label"; //$NON-NLS-1$ } public String getDescription() { return "description"; //$NON-NLS-1$ } public int getCursorPosition() { // TODO Auto-generated method stub return 0; } public String getContent() { // TODO Auto-generated method stub return null; } } }; } }); shell.pack(); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose();
With your snippet, right click and paste using the popup menu does not trigger activation. Is that expected? Ctrl+V works for your snippet, but still broken on my code. Going to continue trying to figure the difference. I must be eating an event that the basic example isn't eating. Thanks
(In reply to comment #2) > With your snippet, right click and paste using the popup menu does not trigger > activation. Is that expected? Sorry Ben, I forgot to test that case. It is not working on my computer also and I am running Linux. This may not be a Windows specific issue then.
(In reply to comment #2) > With your snippet, right click and paste using the popup menu does not trigger > activation. Is that expected? As to whether it's "expected" or not, someone else may have to comment on this since I'm not familiar with this code.
(In reply to comment #0) > Pasting text does not trigger the auto-activation that I would get by typing > the same text into the widget. It appears that the "watchModify" flag in the > implementation is not getting set, so the Modify event being triggered by the > paste is being ignored. From debugging and looking at the code's comments, it seems 'watchModify' was introduced to rectify 183650. When code is pasted from the context menu, only an SWT.Modify event is sent so the field stays 'false'.
Looks like my lack of auto-activation from Ctrl+V is because WorkbenchKeyboard is intercepting it. It ultimately causes Text#paste() to get called. What this means is that the 'v' KeyDown never reaches the adapter, so the "watchModify" flag is not set.
Moving to M4. We really need to resolve bug 275393 (getting the automated tests working on all platforms) before we would attempt this. The basic issue is that we want to ignore programmatic changes and honor user changes, and this is a case where a "programmatic" change to the text was initiated by a user event. However, fooling around with the event flow is tricky and we need to feel confidence in the test suite.
other work taking priority over this...marking 3.6 to keep on radar.
Removing milestone. We really need to nail down the automated test suites in order to tackle bugs like this. Any thoughts in bug 275393 are welcome.
unassigning bugs without milestones
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. If you have further information on the current state of the bug, please add it. 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. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
