This logic looks better by it is unclear why you increase the toolkit’s counter? [AWTToolkit eventCountPlusPlus]; This counter should be increased in the native callbacks and should indicate that there are some activity on the toolkit thread. But it seems it is unnecessary in the new isBlocked() method?
> 2 дек. 2016 г., в 3:16, dmitry markov <dmitry.mar...@oracle.com> написал(а): > > Hi Sergey, > > According to the current implementation we disable a window only when we are > going to show a modal dialog. However I agree it is not a good idea to use > isEnabled flag for testing whether the window is blocked or not, since such > logic is not clear and might be accidentally broken. So I have updated the > fix; new webrev is located at > http://cr.openjdk.java.net/~dmarkov/8165428/webrev.01/ > Summary of changes: > - Added a new function isBlocked() to CPlatformWindow class > - In AWTWindow.m use isBlocked() instead of isEnabled in the cases where we > have to decide whether the ordering operation is required or not. > > Thanks, > Dmitry > On 01/12/2016 03:29, Sergey Bylokhov wrote: >> Hi, Dmitry. >> Is it true that the window is disable only if blocked by some other window? >> Is it possible a situation when it can be disabled by application and in the >> same moment can have an enabled child which should be moved upfront? >> >
