eSWT & Threading - "org.eclipse.swt.SWTException: Invalid thread access"

[funniew]

Hi,
I know and understand the cause of this error but I am curious why there are no convenience methods. For example on Windows Mobile platform, and .NET UI in general, I would do this.

public void someFoobarMethod()
{
    if (InvokeRequired)
    {
        BeginInvoke(new Action(() => tinkerWithUI()));
    }
    else
    {
        tinkerWithUI();
    }
}

The convenience property 'InvokeRequired' is really nice because it hides details of the mechanism. One could be oblivious and still be successful as long they stuck to the rules. Also, if the rules of when to call BeginInvoke()/Invoke() were to change internally once would safe.

However, in eSWT, and SWT in general I assume, I do this;

public void someFoobarMethod()
{
    if (Thread.currentThread() != display.getThread())
    {
        display.asyncExec(new Runnable() {
            public void run() {
                tinkerWithUI();
            }
        });
    }
    else
    {
        tinkerWithUI();
    }
}

Note the line if (Thread.currentThread() != display.getThread()) in the code above this is very implementation specific and potentially could break in future. The mechanism is exposed and in my opinion this is a bad thing. I like 'InvokeRequired()' because it hides actually implementation and one doesn't really have to understand what is going on. Is there a reason there is no convenience method? I am curious that's all. I am thinking there must be some smart reason why none is provided and I want to understand it.

Thanks!

[grahamhughes]

Note the line if (Thread.currentThread() != display.getThread()) in the code above this is very implementation specific and potentially could break in future.

In what way is this "implementaton specific"? How could it break?

You are asking if the thread executing your code is the user-interface thread. Isn't that what you want to know?

Is there a reason there is no convenience method?

Unless one of the designers of the eSWT happens to look here, it's going to be hard to find out. On the whole, CLDC-based APIs tend not to contain functionality that you can build if you need it. They're designed to fit in the least space, so focus on things you need. We might not, of course, always agree that the designer has followed this principle, or with the way in which it has been followed.

Graham.

[funniew]

Well, I it is specific because I am using Thread.current() to determine if it is safe to fiddle with ui. I think it would be nice if this was handled internally by eSWT library;

public void someFoobarMethod()
{
    if (display.invokeRequired())
    {
        display.asyncExec(new Runnable() {
            public void run() {
                tinkerWithUI();
            }
        });
    }
    else
    {
        tinkerWithUI();
    }
}

Now, chances of errors by newbies are eliminated as long as they follow the rule always check if one can safely fiddle with UI. Internally, Display.invokeRequired() will do whatever is required to determine this. It would be nice to further protect newbies if all of the above could be combined into one method. Just would have to slightly modify "asyncExec()".

public void safeCall(Runnable runnable)
{
    if (invokeRequired)
    {
		asyncExec(runnable);
    }
    else
    {
        runnable.run();
    }
}

I just wanted encapsulation of that's all. The more the library does the rudimentary operations the less likelihood of errors, in my most very humbled opinion

[gorkem.ercan]

Thread.currentThread() != display.getThread()

check is not implementation specific. In eSWT & SWT, UI thread is the one that creates the Display object so application already has a way to know the UI thread and all event callbacks are done on that thread . In fact, internally implementation uses the same kind of checks to determine validity of the thread.

Also I should note the Display.syncExec() and Display.asyncExec() also checks if they are invoked from the UI thread. So the benefit of application doing a check for the UI thread will be minimal.
--
Gorkem