AWT.requestFocus deadlocks with SWT.EventQueue.invokeAndWait [message #461465] |
Sat, 24 September 2005 14:08 |
David Scott Messages: 19 Registered: July 2009 |
Junior Member |
|
|
The AWT event thread is blocked in WComponentPeer._requestFocus and the
SWT event thread is blocked in EventQueue.invokeAndWait - any idea what
the WComponentPeer is waiting for?
Thread [AWT-EventQueue-0] (Suspended)
WComponentPeer._requestFocus(Component, boolean, boolean, long)
line: not available [native method]
WEmbeddedFramePeer(WComponentPeer).requestFocus(Component,
boolean, boolean, long) line: not available
Report$LabelField(Component).requestFocusHelper(boolean,
boolean) line: not available
Report$LabelField(Component).requestFocus() line: not available
Report$LabelField(JComponent).requestFocus() line: not available
Report$LabelField.textChanged() line: 292
Report$LabelField.setText(String) line: 271
Report.setLabelText(Style, String) line: 449
LuminexReport.setLuminexFileName(String) line: 129
ReportView$1.run() line: 56
InvocationEvent.dispatch() line: not available
EventQueue.dispatchEvent(AWTEvent) line: not available
EventDispatchThread.pumpOneEventForHierarchy(int, Component)
line: not available
EventDispatchThread.pumpEventsForHierarchy(int, Conditional,
Component) line: not available
EventDispatchThread.pumpEvents(int, Conditional) line: not
available
EventDispatchThread.pumpEvents(Conditional) line: not available
EventDispatchThread.run() line: not available
Thread [TimerQueue] (Running)
Thread [main] (Suspended)
owns: RunnableLock (id=70)
waiting for: EventQueue$1AWTInvocationLock (id=69)
Object.wait(long) line: not available [native method]
EventQueue$1AWTInvocationLock(Object).wait() line: not available
EventQueue.invokeAndWait(Runnable) line: not available
LViewPart.invokeAndWait(Runnable) line: 161
DView.access$4(Runnable) line: 1
DView$MFolder.addDView(Composite, Assay, Marker) line: 279
DView$MFolder.createTabFolder(Composite) line: 264
DView$MFolder.<init>(DView, Assay, DView$MarkerName[],
Composite, int) line: 229
DView$MFolder.<init>(DView, Assay, DView$MarkerName[],
Composite) line: 219
DView.createPartControl(Composite) line: 107
ViewReference.createPartHelper() line: 305
ViewReference.createPart() line: 180
ViewReference(WorkbenchPartReference).getPart(boolean) line: 552
ViewPane(PartPane).setVisible(boolean) line: 283
ViewPane.setVisible(boolean) line: 512
PresentablePart.setVisible(boolean) line: 126
PresentablePartFolder.select(IPresentablePart) line: 268
LeftToRightTabOrder.select(IPresentablePart) line: 65
TabbedStackPresentation.selectPart(IPresentablePart) line: 391
ViewStack(PartStack).refreshPresentationSelection() line: 1102
ViewStack(PartStack).setSelection(LayoutPart) line: 1051
ViewStack(PartStack).showPart(LayoutPart, Object) line: 1256
ViewStack(PartStack).createControl(Composite,
StackPresentation) line: 576
ViewStack(PartStack).createControl(Composite) line: 528
ViewSashContainer(PartSashContainer).createControl(Composite )
line: 485
PerspectiveHelper.activate(Composite) line: 230
Perspective.onActivate() line: 813
WorkbenchPage.setPerspective(Perspective) line: 2928
WorkbenchPage.busySetPerspective(IPerspectiveDescriptor) line: 902
WorkbenchPage.access$11(WorkbenchPage, IPerspectiveDescriptor)
line: 887
WorkbenchPage$12.run() line: 3051
BusyIndicator.showWhile(Display, Runnable) line: 69
WorkbenchPage.setPerspective(IPerspectiveDescriptor) line: 3049
PlateEditor(LuminexEditorPart).switchPerspective(String) line: 294
PlateEditor.switchPerspective() line: 87
PlateEditor.access$3(PlateEditor) line: 84
PlateEditor$1.run() line: 103
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 123
Display.runAsyncMessages(boolean) line: 3057
Display.readAndDispatch() line: 2716
Workbench.runEventLoop(Window$IExceptionHandler, Display) line:
1699
Workbench.runUI() line: 1663
Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor)
line: 367
PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor)
line: 143
Application.run(Object) line: 45
PlatformActivator$1.run(Object) line: 226
EclipseStarter.run(Object) line: 376
EclipseStarter.run(String[], Runnable) line: 163
NativeMethodAccessorImpl.invoke0(Method, Object, Object[])
line: not available [native method]
NativeMethodAccessorImpl.invoke(Object, Object[]) line: not
available
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: not
available
Method.invoke(Object, Object...) line: not available
Main.invokeFramework(String[], URL[]) line: 334
Main.basicRun(String[]) line: 278
Main.run(String[]) line: 973
Main.main(String[]) line: 948
|
|
|
|
|
|
|
Re: AWT.requestFocus deadlocks with SWT.EventQueue.invokeAndWait [message #461702 is a reply to message #461682] |
Tue, 27 September 2005 14:58 |
Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
No. You should probably do the invokeAndWait on a non-UI thread so that
the SWT UI thread stays responsive.
David Scott wrote:
> Rich Kulp wrote:
>
>> Probably request focus is trying to take focus from an SWT window, but
>> since you have the SWT thread waiting on the AWT event queue the SWT
>> thread can't process the request to release focus from the SWT window.
>>
>
> ok - is there a way to release swt focus before the invokeAndWait?
--
Thanks,
Rich Kulp
|
|
|
Re: AWT.requestFocus deadlocks with SWT.EventQueue.invokeAndWait [message #467614 is a reply to message #461702] |
Wed, 01 February 2006 21:43 |
Eclipse User |
|
|
|
Originally posted by: sandi.schoellhammer.apc*SPAM*.com
Rich Kulp wrote:
> No. You should probably do the invokeAndWait on a non-UI thread so that
> the SWT UI thread stays responsive.
>
> David Scott wrote:
>
>> Rich Kulp wrote:
>>
>>> Probably request focus is trying to take focus from an SWT window,
>>> but since you have the SWT thread waiting on the AWT event queue the
>>> SWT thread can't process the request to release focus from the SWT
>>> window.
>>>
>>
>> ok - is there a way to release swt focus before the invokeAndWait?
>
>
Use invokeLater. requestFocus will call back into your SWT thread which
you just blocked by syncing with the AWT thread. invokeLater will
prevent your SWT from syncing (waiting) on your AWT thread. Ff you have
code that is dependant on focus received then use a focus listener as
callback. Late answer but others might want it.
-Sandi
|
|
|
Re: AWT.requestFocus deadlocks with SWT.EventQueue.invokeAndWait [message #467618 is a reply to message #467614] |
Wed, 01 February 2006 21:52 |
Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
That's true. That's why I said do the invokeAndWait on a NON-UI thread.
His code was doing an invokeAndWait so I assumed he needed to do a
series of steps in a certain order, one of which is the invokeAndWait.
But an invokeLater will work too if he doesn't need to wait or he does
the entire series of steps within the runnable passed to the invokeAndWait.
Sandi Schøllhammer wrote:
> Rich Kulp wrote:
>
>> No. You should probably do the invokeAndWait on a non-UI thread so
>> that the SWT UI thread stays responsive.
>>
>> David Scott wrote:
>>
>>> Rich Kulp wrote:
>>>
>>>> Probably request focus is trying to take focus from an SWT window,
>>>> but since you have the SWT thread waiting on the AWT event queue the
>>>> SWT thread can't process the request to release focus from the SWT
>>>> window.
>>>>
>>>
>>> ok - is there a way to release swt focus before the invokeAndWait?
>>
>>
>>
>
>
> Use invokeLater. requestFocus will call back into your SWT thread which
> you just blocked by syncing with the AWT thread. invokeLater will
> prevent your SWT from syncing (waiting) on your AWT thread. Ff you have
> code that is dependant on focus received then use a focus listener as
> callback. Late answer but others might want it.
>
> -Sandi
--
Thanks,
Rich Kulp
|
|
|
Powered by
FUDForum. Page generated in 0.03175 seconds