Hi Sergey, I agree, it is not necessary to increase the toolkit counter here. It is a copy-paste error. I am sorry about that. Please find the updated webrev here: http://cr.openjdk.java.net/~dmarkov/8165428/webrev.02/
Thanks, Dmitry > On 07 Dec 2016, at 03:40, Sergey Bylokhov <sergey.bylok...@oracle.com> wrote: > > 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 >> <mailto: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/ >> <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? >>> >> >
