EsWindowSystemStartUp class>>#cleanUpBeforeWalkback - #syncExecInUI: missing ?

Greetings Norbert,

I'm not able to say if this is an invariant with certainty.
It's a private method so it may not have been intended to determine the proc context.
It also has a lot of sender chains that I'm trying to follow in areas that are older code I'm not comfortably familiar with.

Have you located a public entry point that is causing you issues in this area?

-- Seth

On Monday, August 20, 2018 at 6:02:52 AM UTC-4, Norbert Schlemmer wrote:

Have these statements to be executed under UI process ?

        CommonWidgets cleanUpBeforeWalkback.
        CommonGraphics cleanUpBeforeWalkback.
        System resetBusyCursor.

Use of "CwAppContext default syncExecInUI: [ .. ]. " shall be added ?

Hello Norbert,

Thanks for this great information. The fact that you have incorporated this change for so long gives me much more confidence.
Let me take another look and see if we can get some basic tests incorporated.  After that, I would be happy to officially incorporate it.

We appreciate all the great bug reports you have shared so far and for taking the time to share them.

Kind Regards,

- Seth

On Thursday, August 23, 2018 at 4:30:12 AM UTC-4, Norbert Schlemmer wrote:

Hello Seth

we did change in 1999 without using a tracking tool ...

and migrated this (and other) change(s) to each new VA version...

Currently I don't have debug output or walkback.

But I'm sure that we had troubles with error and walkback handling.

Our GUI runtime class uses EpRuntimeStartUp as base class

EpRuntimeStartUp subclass: #TmcsClientRuntimeStartUp

We added TmcsClientRuntimeStartUp class>>#reportError:resumable:startBP: to exchange the order of these statements:

self
        outputWalkback: errorString;
        cleanUpBeforeWalkback.

->

self
        cleanUpBeforeWalkback;

        outputWalkback: errorString.

And calling #reportError:resumable:startBP: from a "not UI process" leads to an assertion regarding the UI process.

background:

we had troubles doing GUI changes running in background thread instead of the UI process. Therefore we added (a lot of) assertions to improve our application.

example: using drag&drop in the GUI to start executing Oracle database operation in a background process with "busy cursor". Maybe in case of error #reportError:resumable:startBP: will be called by the background process and leads to an UI assertions ...

But I have no problem to migrate this change to the next new VA version(s) as done in the last years ... :-)

Am Mittwoch, 22. August 2018 21:00:47 UTC+2 schrieb Seth Berman:

Greetings Norbert,

I'm not able to say if this is an invariant with certainty.
It's a private method so it may not have been intended to determine the proc context.
It also has a lot of sender chains that I'm trying to follow in areas that are older code I'm not comfortably familiar with.

Have you located a public entry point that is causing you issues in this area?

-- Seth

On Monday, August 20, 2018 at 6:02:52 AM UTC-4, Norbert Schlemmer wrote:

Have these statements to be executed under UI process ?

        CommonWidgets cleanUpBeforeWalkback.
        CommonGraphics cleanUpBeforeWalkback.
        System resetBusyCursor.

Use of "CwAppContext default syncExecInUI: [ .. ]. " shall be added ?