Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 344384

Summary:

[SWT_AWT] Display.asyncExec runnables are not run when modal dialog is shown

Product:

[Eclipse Project] Platform

Reporter:

Christopher Deckers <chrriis>

Component:

SWT

Assignee:

Platform-SWT-Inbox <platform-swt-inbox>

Status:

RESOLVED WORKSFORME

QA Contact:

Severity:

major

Priority:

CC:

alexey, eclipse.felipe, Silenio_Quarti

Version:

4.0

Target Milestone:

---

Hardware:

OS:

Mac OS X

Whiteboard:

stalebug

Attachments:

Description	Flags
Test case showing the issue	none
Rewritten to not inherit from JFrame	none

Description Christopher Deckers

2011-04-30 16:27:31 EDT

Build Identifier: SWT 3.7M7

When a modal dialog is open, asyncExec calls never run until the dialog is closed.

The problem is that communication between a Swing application and the SWT handling uses syncExec/asyncExec to sync threads. sync calls hang (the whole application with it) and controls never receive their commands. This means that SWT_AWT cannot be used on Mac wien modal dialogs are also used.

Note that it works fine on Windows: sync calls are processed even when modal dialogs are shown.

Reproducible: Always

Steps to Reproduce:
1. have a thread call display.asyncExec every 500ms (print to console)
2. open a modal dialog
-> printing stops

Comment 1 Christopher Deckers

2011-04-30 16:28:13 EDT

Created attachment 194432 [details]
Test case showing the issue

Comment 2 Brian de Alwis

2011-11-01 13:52:45 EDT

Created attachment 206282 [details]
Rewritten to not inherit from JFrame

Christopher, although I can reproduce the problem with your code, it works fine if I change your SWTAWTExampleWithJDialog to not inherit from JFrame and instead create a JFrame() and populate it (see attached).  I'd hazard that JFrame or one of its superclasses have a static initializer which causes AWT to be initialized before SWT.

(MacOS X 10.7 with Eclipse 4.2M3)

Comment 3 Christopher Deckers

2011-11-02 16:18:59 EDT

Ouch, so I have been bitten again by the "main outside of a Component subclass" issue.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=291705#c3
https://bugs.eclipse.org/bugs/show_bug.cgi?id=291705#c6

Let's assume this is the cause of the bug: users have no way to know that they are in such an unstable state.

I can think of 3 possible improvements:

1. A way to force SWT initialization when AWT was already initialized to be in a consistent state.

2. SWT to detect that AWT already got initialized when creating the Display and output a message to the console to warn the user.

3. Not a generic solution: a way to test whether we are in such an unstable state so that user code performs this detection externally and warn the user.


This issue is actually quite severe because I am sure that some SWT users do not know they have this condition (not using modal dialogs for example or working around...) and may be struggling with other related side effects without knowing what is happening.
I would love to have solution 1 in place of course, but if 2 can be achieved easily it can already be an improvement as a temporary solution.

Comment 4 Eclipse Genie

2018-10-20 13:27:40 EDT

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.

--
The automated Eclipse Genie.

Comment 5 Lars Vogel

2019-09-02 15:02:58 EDT

This bug was marked as stalebug a while ago. Marking as worksforme.

If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard tag.

Comment 6 Lars Vogel

2019-09-02 15:04:16 EDT

This bug has been marked as stalebug a while ago without any further interaction.

If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard flag.