+1
I also suggest to file a bug to specify "null" behavior for the new methods. In some cases we already do this, in some not.


On 18.10.16 14:15, Semyon Sadetsky wrote:
+1

--Semyon


On 18.10.2016 14:13, Alexander Zvegintsev wrote:
Updated the "behavior is undefined" section:

http://cr.openjdk.java.net/~azvegint/jdk/9/8166594/01/

Thanks,
Alexander.

On 10/6/16 6:14 PM, Semyon Sadetsky wrote:
On 10/6/2016 3:38 PM, Alexander Zvegintsev wrote:

Hi Semyon,

Yes it is, Microsoft defined some set of rules for such case[0].

However it looks redundant and too implementation-specific(which can
be changed) for me.
I didn't mean to specify the behavior for Windows platform. It seems
that any desktop platform may have its own rules for this case.
"Unspecified  behavior" just sounds a bit like a warning to me. Maybe
it worth to write that this behavior is a platform specific, or don't
mention the scenario at all since those rules cannot be changed by
JDK anyway. But it is just a recommendation, the decision is up to you.

Reformatted for 80 chars in place.
Thanks. Looks good then.

--Semyon


[0]
https://msdn.microsoft.com/en-us/library/windows/desktop/dd391698(v=vs.85).aspx#How_the_Taskbar_Button_Chooses_the_Progress_Indicator_for_a_Group



On 10/6/16 9:23 AM, Semyon Sadetsky wrote:
Hi Alexander,

416      * Note that the behavior is undefined when multiple
windows is grouped in the task area.

Isn't the above a some kind of simplification?

Could you reformat changed lines to make them following the 80
chars maximum?

--Semyon


On 06.10.2016 04:56, Alexander Zvegintsev wrote:
Hello,

please review the fix

http://cr.openjdk.java.net/~azvegint/jdk/9/8166594/00/

for the issue

https://bugs.openjdk.java.net/browse/JDK-8166594


It also fixes two issues to conform the documentation:

setting value below 0 doesn't disable progress indication

switching from indeterminate to normal state has no effect








--
Best regards, Sergey.

Reply via email to