Looks fine to me too.
Regards,
Alexey
On 07.12.2016 21:01, dmitry markov wrote:
Thank you very much, Sergey!
Looking for the second +1 from someone else.
Thanks,
Dmitry
On 07/12/2016 19:25, Sergey Bylokhov wrote:
Looks fine.
7 дек. 2016 г., в 2:24, Dmitry Markov
Thank you very much, Sergey!
Looking for the second +1 from someone else.
Thanks,
Dmitry
On 07/12/2016 19:25, Sergey Bylokhov wrote:
Looks fine.
7 дек. 2016 г., в 2:24, Dmitry Markov > написал(а):
Hi Sergey,
I agree, it is not
Looks fine.
> 7 дек. 2016 г., в 2:24, Dmitry Markov написал(а):
>
> 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:
>
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()
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.
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?
--
Best regards, Sergey.
Hello,
Could you review a fix for jdk9, please?
bug: https://bugs.openjdk.java.net/browse/JDK-8165428
webrev: http://cr.openjdk.java.net/~dmarkov/8165428/webrev.00/
Problem description:
Sometimes the function orderChildWindows() might be called for the window which
is blocked