Re: 8160438: [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.java fails

2016-07-11 Thread Avik Niyogi 
Hi All,
A gentle reminder, please review my code changes.

With Regards,
Avik Niyogi

> On 08-Jul-2016, at 4:24 pm, Yuri Nesterenko  
> wrote:
> 
> It pass for me if I provide some time to process native events
> after the user activity simulation. For instance,
> setAutoDelay(50) for robot does that plus waitForIdle()
> after every mouseMove(). In this case, the part with that additional
> check and a (misleading, I think) comment about the color profiles
> may be removed. The test would take much more time though, and
>   @run main/timeout=600 bug8057791
> line would be necessary.
> 
> Thanks,
> -yan
> 
> On 07/08/2016 04:28 AM, Avik Niyogi wrote:
>> The test does not pass if mac specific check is not done for
>> backgroundcolor.
>> The check is required to get the same values from BufferedImage as they
>> are the same as found with Digital Color Meter.
>> This test case fixes that.
>> Please provide inputs if this fix will get a +1 or if not any positive
>> inputs to modify the test case will be welcome.
>> 
>> With Regards,
>> Avik Niyogi
>>> On 07-Jul-2016, at 9:51 pm, Semyon Sadetsky
>>> > wrote:
>>> 
>>> 
>>> 
>>> On 7/7/2016 6:30 PM, Yuri Nesterenko wrote:
 On 07/07/2016 06:15 PM, Semyon Sadetsky wrote:
> 
> 
> On 7/7/2016 5:58 PM, Yuri Nesterenko wrote:
>> On 07/07/2016 05:35 PM, Yuri Nesterenko wrote:
>>> On 07/07/2016 05:04 PM, Semyon Sadetsky wrote:
 
 
 On 07.07.2016 16:35, Avik Niyogi wrote:
> Hi Semyon,
> 
> Thank you for the review comment.
> 
> In Mac OS X, *System Preferences > Displays > Colors > Display
> Profile*  section, the default value is *Color LCD*.
> This causes a failure in some test cases which uses robot.The colour
> configuration it expects to use is the *Generic RGB Profile*.
> That is what “Non-generic display settings” means.
 AFAIK there are instruction that tests should be executed using color
 profile with no color corrections on OS X. I guess there are many
 other
 tests that fail with color correction.
 If this is a root cause than the bug doesn't need to be fixed.
>>> 
>>> Well, I filed this bug and I used Generic RGB on all my
>>> test machines. There may be additional precautions in the tests
>>> about that but misconfiguration is not the root case here.
>>> That said, I feel vary about attempts to guess Apple colors
>>   wary I mean
>>> in non-generic profiles.
> Yuri. Do you mean that the non-generic is not a root case?
 No: I had Generic RGB everywhere, and it failed for me.
 I should say that the new version of the test properly
 fails with b120 and pass with current PIT. And colors
 are visibly different in the two builds: so the test works OK now.
>>> That contradicts with the description of the fix.
>>> Probably the test does unnecessary care about the non-Generic profiles.
>>> 
>>> 159 if (!foundMatch && isMac()) {
>>> 160 //One more chance for Mac due to non-Generic
>>> display setting
>>> 161 detectedColor = new Color(img.getRGB(x, y), true);
>>> 162 if (detectedColor.equals(colorCheck)) {
>>> 163 foundMatch = true;
>>> 164 break checkLoops;
>>> 165 }
>>> 166 }
>>> 
>>> Does it mean that the code above, which is necessary to serve
>>> non-Generic profiles on OS X, may be removed and the test still passes?
>>> 
>>> --Semyon
 
 -yan
 
> 
> --Semyon
>>> 
>>> -yan
>>> 
>>> 
 
 --Semyon
> 
> Regarding “Negative scenarios”, these include cases where
> colours are
> different from the expected background or foreground colors
> is checked with the robot and BufferedImage respectively to
> *eliminate
> false positives due to coincidentally finding a match* by using
> robot
> or BufferedImage.
> 
> Please find my changes appropriating the inputs provided.
> I removed the variable foundMatch as I found that it is not required
> at all and incorporated the suggestion to use return instead of a
> labelled break.
> 
> http://cr.openjdk.java.net/~aniyogi/8160438/webrev.01/
> 
> 
> 
>> On 07-Jul-2016, at 6:30 pm, Semyon Sadetsky
>> >
>> wrote:
>> 
>> Hi Avik,
>> 
>> could you clarify what is "Non-generic display settings"? Is it
>> known
>> bug on OS X?
>> And also please be more specific on "negative

Re: [9] Review request for 8159587: IOOBE in javax/swing/JFileChooser/7199708/bug7199708.java

2016-07-11 Thread Alexandr Scherbatiy 

The fix looks good to me.

Thanks,
Alexandr.

On 7/11/2016 12:28 PM, Semyon Sadetsky wrote:

Hello,

Please review fix for JDK9:

bug: https://bugs.openjdk.java.net/browse/JDK-8159587

webrev: http://cr.openjdk.java.net/~ssadetsky/8159587/webrev.00/

Exception is caused by row index value =0 which is not in a valid 
range because table model contains no rows at the moment. The issue is 
in FilePane's clear selection method. The correct way to clear a 
selection model is to set the anchor/lead index to -1 not to 0.


--Semyon

Re: Review Request JDK-8159168 [hidpi] Window.setShape() works incorrectly on HiDPI

2016-07-11 Thread Alexandr Scherbatiy 

The fix looks good to me.

Thanks,
Alexandr.

On 7/11/2016 12:13 PM, Semyon Sadetsky wrote:


Looks good to me.

--Semyon

On 7/11/2016 12:08 PM, Rajeev Chamyal wrote:


Hello Semyon,

Please review the updated webrev as per review comments.

http://cr.openjdk.java.net/~rchamyal/8159168/webrev.04/

Regards,

Rajeev Chamyal

*From:*Semyon Sadetsky
*Sent:* 11 July 2016 14:29
*To:* Rajeev Chamyal; Alexander Scherbatiy; 
swing-dev@openjdk.java.net; Sergey Bylokhov
*Subject:* Re:  Review Request JDK-8159168 [hidpi] 
Window.setShape() works incorrectly on HiDPI


On 7/11/2016 11:10 AM, Rajeev Chamyal wrote:

Hello Semyon,

Thanks for the review. Yes, mouse move is not required I have
removed it.

Please review the updated webrev.

http://cr.openjdk.java.net/~rchamyal/8159168/webrev.03/

Thanks.
I also cannot see the reason to wait 1 second in line 59.
It seems tx variable from line 53 is never used.

--Semyon

Regards,

Rajeev Chamyal

*From:*Semyon Sadetsky
*Sent:* 11 July 2016 12:30
*To:* Rajeev Chamyal; Alexander Scherbatiy;
swing-dev@openjdk.java.net; Sergey Bylokhov
*Subject:* Re:  Review Request JDK-8159168 [hidpi]
Window.setShape() works incorrectly on HiDPI

Hi Rajeev,

The fix itself looks good. I only did not get for what purpose
mouse pointer is moved in the test?

--Semyon

On 7/5/2016 9:16 AM, Rajeev Chamyal wrote:

Hello Alexandr,

Please review updated webrev.

http://cr.openjdk.java.net/~rchamyal/8159168/webrev.02/

Regards,

Rajeev Chamyal

*From:*Alexandr Scherbatiy
*Sent:* 05 July 2016 11:38
*To:* Rajeev Chamyal; swing-dev@openjdk.java.net; Sergey Bylokhov
*Subject:* Re:  Review Request JDK-8159168 [hidpi]
Window.setShape() works incorrectly on HiDPI

On 7/5/2016 8:25 AM, Rajeev Chamyal wrote:



Hello Alexandr,

Thanks for the review.

As per windows specification X & Y scale are always equal
that’s why I have put scaleX == scaleY check.

But it may change in future so I have removed this check.

http://cr.openjdk.java.net/~rchamyal/8159168/webrev.01/


1135 if (scaleX != 1 && scaleY != 1) {

  It is better to use 'or' operator because the shape should
be scaled when on of the scales is differ from 1.

Thanks,
Alexandr.




Regards,

Rajeev Chamyal

*From:*Alexandr Scherbatiy
*Sent:* 04 July 2016 18:03
*To:* Rajeev Chamyal; swing-dev@openjdk.java.net; Sergey
Bylokhov
*Subject:* Re:  Review Request JDK-8159168
[hidpi] Window.setShape() works incorrectly on HiDPI

On 7/4/2016 3:09 PM, Rajeev Chamyal wrote:




Hello All,

Please review the following webrev.

Bug: https://bugs.openjdk.java.net/browse/JDK-8159168

Webrev:
http://cr.openjdk.java.net/~rchamyal/8159168/webrev.00/



Issue: In HiDPI screen shape set through
window::setShape API is not scaled based on system scale.

Fix:. Updated the WComponentPeer::applyShape to
update shape based on system scale.

1131 double scaleX =
winGraphicsConfig.getDefaultTransform().getScaleX();
1132 double scaleY =
winGraphicsConfig.getDefaultTransform().getScaleY();

 The getDefaultTransform() is called twice which leads
that AffineTransform object is created two times
1133 if (scaleX != 1 && scaleY != 1 && scaleX
== scaleY) {

   Is the check scaleX == scaleY really necessary here?

   Is it possible to make the test automated? Just run it
with option "@run main/othervm -Dsun.java2d.uiScale=2
TestName" and check the area where the shape is drawn?

  Thanks,
  Alexandr.




Regards,

Rajeev Chamyal

[9] Review request for 8159587: IOOBE in javax/swing/JFileChooser/7199708/bug7199708.java

2016-07-11 Thread Semyon Sadetsky 

Hello,

Please review fix for JDK9:

bug: https://bugs.openjdk.java.net/browse/JDK-8159587

webrev: http://cr.openjdk.java.net/~ssadetsky/8159587/webrev.00/

Exception is caused by row index value =0 which is not in a valid range 
because table model contains no rows at the moment. The issue is in 
FilePane's clear selection method. The correct way to clear a selection 
model is to set the anchor/lead index to -1 not to 0.


--Semyon

Re: Review Request JDK-8159168 [hidpi] Window.setShape() works incorrectly on HiDPI

2016-07-11 Thread Semyon Sadetsky 

Looks good to me.

--Semyon

On 7/11/2016 12:08 PM, Rajeev Chamyal wrote:


Hello Semyon,

Please review the updated webrev as per review comments.

http://cr.openjdk.java.net/~rchamyal/8159168/webrev.04/ 



Regards,

Rajeev Chamyal

*From:*Semyon Sadetsky
*Sent:* 11 July 2016 14:29
*To:* Rajeev Chamyal; Alexander Scherbatiy; 
swing-dev@openjdk.java.net; Sergey Bylokhov
*Subject:* Re:  Review Request JDK-8159168 [hidpi] 
Window.setShape() works incorrectly on HiDPI


On 7/11/2016 11:10 AM, Rajeev Chamyal wrote:

Hello Semyon,

Thanks for the review. Yes, mouse move is not required I have
removed it.

Please review the updated webrev.

http://cr.openjdk.java.net/~rchamyal/8159168/webrev.03/


Thanks.
I also cannot see the reason to wait 1 second in line 59.
It seems tx variable from line 53 is never used.

--Semyon

Regards,

Rajeev Chamyal

*From:*Semyon Sadetsky
*Sent:* 11 July 2016 12:30
*To:* Rajeev Chamyal; Alexander Scherbatiy;
swing-dev@openjdk.java.net ;
Sergey Bylokhov
*Subject:* Re:  Review Request JDK-8159168 [hidpi]
Window.setShape() works incorrectly on HiDPI

Hi Rajeev,

The fix itself looks good. I only did not get for what purpose
mouse pointer is moved in the test?

--Semyon

On 7/5/2016 9:16 AM, Rajeev Chamyal wrote:

Hello Alexandr,

Please review updated webrev.

http://cr.openjdk.java.net/~rchamyal/8159168/webrev.02/


Regards,

Rajeev Chamyal

*From:*Alexandr Scherbatiy
*Sent:* 05 July 2016 11:38
*To:* Rajeev Chamyal; swing-dev@openjdk.java.net
; Sergey Bylokhov
*Subject:* Re:  Review Request JDK-8159168 [hidpi]
Window.setShape() works incorrectly on HiDPI

On 7/5/2016 8:25 AM, Rajeev Chamyal wrote:



Hello Alexandr,

Thanks for the review.

As per windows specification X & Y scale are always equal
that’s why I have put scaleX == scaleY check.

But it may change in future so I have removed this check.

http://cr.openjdk.java.net/~rchamyal/8159168/webrev.01/



1135 if (scaleX != 1 && scaleY != 1) {

  It is better to use 'or' operator because the shape should
be scaled when on of the scales is differ from 1.

Thanks,
Alexandr.




Regards,

Rajeev Chamyal

*From:*Alexandr Scherbatiy
*Sent:* 04 July 2016 18:03
*To:* Rajeev Chamyal; swing-dev@openjdk.java.net
; Sergey Bylokhov
*Subject:* Re:  Review Request JDK-8159168
[hidpi] Window.setShape() works incorrectly on HiDPI

On 7/4/2016 3:09 PM, Rajeev Chamyal wrote:




Hello All,

Please review the following webrev.

Bug: https://bugs.openjdk.java.net/browse/JDK-8159168

Webrev:
http://cr.openjdk.java.net/~rchamyal/8159168/webrev.00/



Issue: In HiDPI screen shape set through
window::setShape API is not scaled based on system scale.

Fix:. Updated the WComponentPeer::applyShape to update
shape based on system scale.

1131 double scaleX =
winGraphicsConfig.getDefaultTransform().getScaleX();
1132 double scaleY =
winGraphicsConfig.getDefaultTransform().getScaleY();

 The getDefaultTransform() is called twice which leads
that AffineTransform object is created two times
1133 if (scaleX != 1 && scaleY != 1 && scaleX
== scaleY) {

   Is the check scaleX == scaleY really necessary here?

   Is it possible to make the test automated? Just run it
with option "@run main/othervm -Dsun.java2d.uiScale=2
TestName" and check the area where the shape is drawn?

  Thanks,
  Alexandr.




Regards,

Rajeev Chamyal

Re: Review Request JDK-8159168 [hidpi] Window.setShape() works incorrectly on HiDPI

2016-07-11 Thread Rajeev Chamyal 
Hello Semyon,

 

Please review the updated webrev as per review comments.

http://cr.openjdk.java.net/~rchamyal/8159168/webrev.04/ 

 

Regards,

Rajeev Chamyal

 

From: Semyon Sadetsky 
Sent: 11 July 2016 14:29
To: Rajeev Chamyal; Alexander Scherbatiy; swing-dev@openjdk.java.net; Sergey 
Bylokhov
Subject: Re:  Review Request JDK-8159168 [hidpi] Window.setShape() 
works incorrectly on HiDPI

 

On 7/11/2016 11:10 AM, Rajeev Chamyal wrote:

Hello Semyon,

 

Thanks for the review. Yes, mouse move is not required I have removed it.

Please review the updated webrev.

http://cr.openjdk.java.net/~rchamyal/8159168/webrev.03/

Thanks. 
I also cannot see the reason to wait 1 second in line 59. 
It seems tx variable from line 53 is never used.

--Semyon



 

Regards,

Rajeev Chamyal

 

From: Semyon Sadetsky 
Sent: 11 July 2016 12:30
To: Rajeev Chamyal; Alexander Scherbatiy; HYPERLINK 
"mailto:swing-dev@openjdk.java.net"swing-dev@openjdk.java.net; Sergey Bylokhov
Subject: Re:  Review Request JDK-8159168 [hidpi] Window.setShape() 
works incorrectly on HiDPI

 

Hi Rajeev,

The fix itself looks good. I only did not get for what purpose mouse pointer is 
moved in the test?

--Semyon

 

On 7/5/2016 9:16 AM, Rajeev Chamyal wrote:

Hello Alexandr,

 

Please review updated webrev.

http://cr.openjdk.java.net/~rchamyal/8159168/webrev.02/

 

Regards,

Rajeev Chamyal

 

From: Alexandr Scherbatiy 
Sent: 05 July 2016 11:38
To: Rajeev Chamyal; HYPERLINK 
"mailto:swing-dev@openjdk.java.net"swing-dev@openjdk.java.net; Sergey Bylokhov
Subject: Re:  Review Request JDK-8159168 [hidpi] Window.setShape() 
works incorrectly on HiDPI

 

On 7/5/2016 8:25 AM, Rajeev Chamyal wrote:





Hello Alexandr,

 

Thanks for the review.

As per windows specification X & Y scale are always equal that's why I have put 
scaleX == scaleY check.

But it may change in future so I have removed this check.

 

http://cr.openjdk.java.net/~rchamyal/8159168/webrev.01/


1135 if (scaleX != 1 && scaleY != 1) {
  
  It is better to use 'or' operator because the shape should be scaled when on 
of the scales is differ from 1.

Thanks,
Alexandr.






 

Regards,

Rajeev Chamyal

 

From: Alexandr Scherbatiy 
Sent: 04 July 2016 18:03
To: Rajeev Chamyal; HYPERLINK 
"mailto:swing-dev@openjdk.java.net"swing-dev@openjdk.java.net; Sergey Bylokhov
Subject: Re:  Review Request JDK-8159168 [hidpi] Window.setShape() 
works incorrectly on HiDPI

 

On 7/4/2016 3:09 PM, Rajeev Chamyal wrote:






Hello All,

 

Please review the following webrev.

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8159168 

Webrev: HYPERLINK 
"http://cr.openjdk.java.net/%7Erchamyal/8159168/webrev.00/"http://cr.openjdk.java.net/~rchamyal/8159168/webrev.00/
 

 

Issue: In HiDPI screen shape set through window::setShape API is not scaled 
based on system scale.

Fix:. Updated the WComponentPeer::applyShape to update shape based on system 
scale. 

1131 double scaleX = 
winGraphicsConfig.getDefaultTransform().getScaleX();
1132 double scaleY = 
winGraphicsConfig.getDefaultTransform().getScaleY();

 The getDefaultTransform() is called twice which leads that AffineTransform 
object is created two times
1133 if (scaleX != 1 && scaleY != 1 && scaleX == scaleY) {

   Is the check scaleX == scaleY really necessary here?

   Is it possible to make the test automated? Just run it with option "@run 
main/othervm -Dsun.java2d.uiScale=2 TestName" and check the area where the 
shape is drawn?

  Thanks,
  Alexandr.






 

Regards,

Rajeev Chamyal

Re: Review Request JDK-8159168 [hidpi] Window.setShape() works incorrectly on HiDPI

2016-07-11 Thread Rajeev Chamyal 
Hello Semyon,

 

Thanks for the review. Yes, mouse move is not required I have removed it.

Please review the updated webrev.

http://cr.openjdk.java.net/~rchamyal/8159168/webrev.03/

 

Regards,

Rajeev Chamyal

 

From: Semyon Sadetsky 
Sent: 11 July 2016 12:30
To: Rajeev Chamyal; Alexander Scherbatiy; swing-dev@openjdk.java.net; Sergey 
Bylokhov
Subject: Re:  Review Request JDK-8159168 [hidpi] Window.setShape() 
works incorrectly on HiDPI

 

Hi Rajeev,

The fix itself looks good. I only did not get for what purpose mouse pointer is 
moved in the test?

--Semyon

 

On 7/5/2016 9:16 AM, Rajeev Chamyal wrote:

Hello Alexandr,

 

Please review updated webrev.

http://cr.openjdk.java.net/~rchamyal/8159168/webrev.02/

 

Regards,

Rajeev Chamyal

 

From: Alexandr Scherbatiy 
Sent: 05 July 2016 11:38
To: Rajeev Chamyal; HYPERLINK 
"mailto:swing-dev@openjdk.java.net"swing-dev@openjdk.java.net; Sergey Bylokhov
Subject: Re:  Review Request JDK-8159168 [hidpi] Window.setShape() 
works incorrectly on HiDPI

 

On 7/5/2016 8:25 AM, Rajeev Chamyal wrote:




Hello Alexandr,

 

Thanks for the review.

As per windows specification X & Y scale are always equal that's why I have put 
scaleX == scaleY check.

But it may change in future so I have removed this check.

 

http://cr.openjdk.java.net/~rchamyal/8159168/webrev.01/


1135 if (scaleX != 1 && scaleY != 1) {
  
  It is better to use 'or' operator because the shape should be scaled when on 
of the scales is differ from 1.

Thanks,
Alexandr.





 

Regards,

Rajeev Chamyal

 

From: Alexandr Scherbatiy 
Sent: 04 July 2016 18:03
To: Rajeev Chamyal; HYPERLINK 
"mailto:swing-dev@openjdk.java.net"swing-dev@openjdk.java.net; Sergey Bylokhov
Subject: Re:  Review Request JDK-8159168 [hidpi] Window.setShape() 
works incorrectly on HiDPI

 

On 7/4/2016 3:09 PM, Rajeev Chamyal wrote:





Hello All,

 

Please review the following webrev.

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8159168 

Webrev: HYPERLINK 
"http://cr.openjdk.java.net/%7Erchamyal/8159168/webrev.00/"http://cr.openjdk.java.net/~rchamyal/8159168/webrev.00/
 

 

Issue: In HiDPI screen shape set through window::setShape API is not scaled 
based on system scale.

Fix:. Updated the WComponentPeer::applyShape to update shape based on system 
scale. 

1131 double scaleX = 
winGraphicsConfig.getDefaultTransform().getScaleX();
1132 double scaleY = 
winGraphicsConfig.getDefaultTransform().getScaleY();

 The getDefaultTransform() is called twice which leads that AffineTransform 
object is created two times
1133 if (scaleX != 1 && scaleY != 1 && scaleX == scaleY) {

   Is the check scaleX == scaleY really necessary here?

   Is it possible to make the test automated? Just run it with option "@run 
main/othervm -Dsun.java2d.uiScale=2 TestName" and check the area where the 
shape is drawn?

  Thanks,
  Alexandr.





 

Regards,

Rajeev Chamyal

Re: Review Request JDK-8159168 [hidpi] Window.setShape() works incorrectly on HiDPI

2016-07-11 Thread Semyon Sadetsky 

Hi Rajeev,

The fix itself looks good. I only did not get for what purpose mouse 
pointer is moved in the test?


--Semyon


On 7/5/2016 9:16 AM, Rajeev Chamyal wrote:


Hello Alexandr,

Please review updated webrev.

http://cr.openjdk.java.net/~rchamyal/8159168/webrev.02/ 



Regards,

Rajeev Chamyal

*From:*Alexandr Scherbatiy
*Sent:* 05 July 2016 11:38
*To:* Rajeev Chamyal; swing-dev@openjdk.java.net; Sergey Bylokhov
*Subject:* Re:  Review Request JDK-8159168 [hidpi] 
Window.setShape() works incorrectly on HiDPI


On 7/5/2016 8:25 AM, Rajeev Chamyal wrote:

Hello Alexandr,

Thanks for the review.

As per windows specification X & Y scale are always equal that’s
why I have put scaleX == scaleY check.

But it may change in future so I have removed this check.

http://cr.openjdk.java.net/~rchamyal/8159168/webrev.01/



1135 if (scaleX != 1 && scaleY != 1) {

  It is better to use 'or' operator because the shape should be scaled 
when on of the scales is differ from 1.


Thanks,
Alexandr.


Regards,

Rajeev Chamyal

*From:*Alexandr Scherbatiy
*Sent:* 04 July 2016 18:03
*To:* Rajeev Chamyal; swing-dev@openjdk.java.net
; Sergey Bylokhov
*Subject:* Re:  Review Request JDK-8159168 [hidpi]
Window.setShape() works incorrectly on HiDPI

On 7/4/2016 3:09 PM, Rajeev Chamyal wrote:


Hello All,

Please review the following webrev.

Bug: https://bugs.openjdk.java.net/browse/JDK-8159168

Webrev:
http://cr.openjdk.java.net/~rchamyal/8159168/webrev.00/


Issue: In HiDPI screen shape set through window::setShape API
is not scaled based on system scale.

Fix:. Updated the WComponentPeer::applyShape to update shape
based on system scale.

1131 double scaleX =
winGraphicsConfig.getDefaultTransform().getScaleX();
1132 double scaleY =
winGraphicsConfig.getDefaultTransform().getScaleY();

 The getDefaultTransform() is called twice which leads that
AffineTransform object is created two times
1133 if (scaleX != 1 && scaleY != 1 && scaleX == scaleY) {

   Is the check scaleX == scaleY really necessary here?

   Is it possible to make the test automated? Just run it with
option "@run main/othervm -Dsun.java2d.uiScale=2 TestName" and
check the area where the shape is drawn?

  Thanks,
  Alexandr.


Regards,

Rajeev Chamyal