From zhouyx at linux.vnet.ibm.com  Tue Jan 10 04:23:29 2012
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Tue, 10 Jan 2012 12:23:29 +0800
Subject: <Swing Dev> Fwd: Focus on image icons are not visible in javaws
 cache with high contrast mode
In-Reply-To: <CAOo=rxVirN=zSaRdt+ccn10K46o9TZU5PjF=wH==s0NV=H9Bhw@mail.gmail.com>
References: <4e647dc3.82cde30a.3537.5eed@mx.google.com>
	<CAOo=rxWpsDbsS3GVaH8shVfu3NKr1gu2VRSOgmOgutQffWnxTQ@mail.gmail.com>
	<4E6A13ED.200@oracle.com>
	<CAOo=rxXAttuk+_dV9U39cjXtAt9XkGo3Pec9pJv2BE0NcCL=jQ@mail.gmail.com>
	<1316086740.27737.52.camel@chalkhill> <4E71F7D4.6000704@oracle.com>
	<1316098057.27737.111.camel@chalkhill>
	<4E732DB1.6070804@oracle.com>
	<CAOo=rxV3iW-2CM=NfOE9R+6fQm4P5jvCiJv77Ve_52aTRPDucQ@mail.gmail.com>
	<4EA8237B.4020407@oracle.com>
	<CAOo=rxUw_JTkttdKUfUMcZsKhU_4JOJH5X96tm55tEySiJFi4A@mail.gmail.com>
	<4EABFC41.7040504@oracle.com>
	<CAOo=rxUAckkHQCEFK8y5foZ6hgzgw5c7+S-kj066n2DuE9FjSg@mail.gmail.com>
	<4ECD3A38.9040406@oracle.com>
	<CAOo=rxVirN=zSaRdt+ccn10K46o9TZU5PjF=wH==s0NV=H9Bhw@mail.gmail.com>
Message-ID: <CAOo=rxUioqrMENeWje8WkKZ81cBF8eX62dqCh8F3hSSF4_Z+dQ@mail.gmail.com>

Hi all,

   Is anybody back from vocation ?

---------- Forwarded message ----------
From: Sean Chou <zhouyx at linux.vnet.ibm.com>
Date: Thu, Dec 22, 2011 at 3:04 PM
Subject: Re: <Swing Dev> Focus on image icons are not visible in javaws
cache with high contrast mode
To: Pavel Porvatov <pavel.porvatov at oracle.com>
Cc: swing-dev at openjdk.java.net


Hi Pavel,

    I made another patch, and it is uploaded to
http://cr.openjdk.java.net/~zhouyx/7089914/webrev.01/  .

    The button.focus is now similar to a windows property, it will
be loaded when other windows properties are loaded; and it
stays in the same priority as other windows properties so user
defined value won't be overwritten.

   And I also found a bug in WindowsRadioButtonUI which
blocks radiobutton and checkbox from reloading their styles,
its fix(override the uninstallDefaults ) is included in the webrev
as well.

A simple testcase which includes checkbox and radiobutton
is here:

/////////////////////////////

import java.awt.BorderLayout;
import java.awt.EventQueue;

import javax.swing.ImageIcon;
import javax.swing.JButton;
import javax.swing.JCheckBox;
import javax.swing.JFrame;
import javax.swing.JRadioButton;
import javax.swing.JToolBar;
import javax.swing.UIManager;
import javax.swing.UnsupportedLookAndFeelException;


public class TestButton {

    private JFrame frame;

    /**
     * Launch the application.
     */
    public static void main(String[] args) {

        try {

UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
        } catch (ClassNotFoundException | InstantiationException
                | IllegalAccessException | UnsupportedLookAndFeelException
e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }

        EventQueue.invokeLater(new Runnable() {
            public void run() {
                try {
                    TestButton window = new TestButton();
                    window.frame.setVisible(true);
                } catch (Exception e) {
                    e.printStackTrace();
                }
            }
        });
    }

    /**
     * Create the application.
     */
    public TestButton() {
        initialize();
    }

    /**
     * Initialize the contents of the frame.
     */
    private void initialize() {
        frame = new JFrame();
        frame.setBounds(100, 100, 450, 300);
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

        JToolBar toolBar = new JToolBar();
        frame.getContentPane().add(toolBar, BorderLayout.NORTH);

        JButton btnNewButton = new JButton(new ImageIcon("testicon.png"));
        toolBar.add(btnNewButton);

        JButton btnNewButton_1 = new JButton("New button");
        frame.getContentPane().add(btnNewButton_1, BorderLayout.CENTER);

        JCheckBox chckbxNewCheckBox = new JCheckBox("New check box");
        frame.getContentPane().add(chckbxNewCheckBox, BorderLayout.WEST);

        JRadioButton rdbtnNewRadioButton = new JRadioButton("New radio
button");
        frame.getContentPane().add(rdbtnNewRadioButton, BorderLayout.EAST);
    }
}

////////////////////////////////



On Thu, Nov 24, 2011 at 2:23 AM, Pavel Porvatov
<pavel.porvatov at oracle.com>wrote:

>  Hi Sean,
>
> Hi Pavel,
>
>     I rewrite a testcase, which is attached as TestButton.java . It has a
> toolbar and two buttons,
> one in toolbar and the other in contentpane. The one in toolbar use an
> image which is
> attached as testicon.png .  I don't know how to write an automatic
> testcase for this one
>  because it changes windows settings.
>
> Sometimes it's really hard to write automatic test. In your case SwingSet2
> demo and an appropriate instruction for testers is enough...
>
>
>    Just run TestButton and change windows to high contrast mode and you
> can find the focus
> is not painted.
>
>    I attached the patch in webrev.zip.  It just checks if button
> background is black when
> windows properties changed. Please have a look.
>
> It seems your fix adds the following regression:
> somebody can install own "Button.focus" value, but your code puts own
> value over the users one
>
> Regards, Pavel
>
>
>
>  On Sat, Oct 29, 2011 at 9:14 PM, Pavel Porvatov <
> pavel.porvatov at oracle.com> wrote:
>
>>  Hi Sean,
>>
>>
>>
>>     It seems the black color for focus is set intentionally. If we set it
>> to "ControlTextColor ",
>> the focus color may become red in above testcase, that's not what we want.
>>     And I changed the color for all items listed with "3D object", the
>> focus remains black;
>> maybe windows just uses "black" for focus color in normal mode, and
>> another color for
>> high contrast mode.
>>
>>     However, the original patch posted is not right in this scenario.
>> I'll modify it. How about
>> just uses white for high contrast mode ? As it simply uses black for
>> normal mode.
>>
>>  I'm not sure you can determine if high contrast mode is set... Every
>> heuristic function for selection color can fail in some situation.
>>
>> If somebody can take a look at source of
>> ControlPaint::DrawFocusRectangle(Graphics, Rectangle) method (see
>> http://msdn.microsoft.com/en-us/library/k2czzc46.aspx) and find out
>> which colors uses .NET....
>>
>> Regards, Pavel
>>
>>
>> On Wed, Oct 26, 2011 at 11:12 PM, Pavel Porvatov <
>> pavel.porvatov at oracle.com> wrote:
>>
>>>   Hi Sean,
>>>
>>> Hi Pavel,
>>>
>>>      From your image, I agree the focus color is not always the same
>>> with ControlTextColor,
>>> but I cannot recreate it. When I changed  color of "3D objects" to red,
>>> I got another image.
>>> Please have a look.
>>>
>>>  It seems you changed Color1, but not Color (which a little bit lower
>>> then Color1)....
>>>
>>>     I think your suggestion is reasonable, we'd better use the focus
>>> color from windows, but
>>> it maybe a problem to keep 100% the same, I still not found if there is
>>> a document for the
>>> focus color.
>>>
>>>  Yes, the MS documentation about focus color is the best way to fix the
>>> bug. Can anybody point to such document?
>>>
>>> Regards, Pavel
>>>
>>>
>>> On Fri, Sep 16, 2011 at 7:06 PM, Pavel Porvatov <
>>> pavel.porvatov at oracle.com> wrote:
>>>
>>>> Hi Neil,
>>>>
>>>>  On Thu, 2011-09-15 at 17:04 +0400, Pavel Porvatov wrote:
>>>>>
>>>>>> Hi Neil,
>>>>>>
>>>>>>> On Wed, 2011-09-14 at 14:14 +0800, Sean Chou wrote:
>>>>>>>
>>>>>>>> Hi Pavel,
>>>>>>>>
>>>>>>>>
>>>>>>>>     I reported a bug there yesterday,
>>>>>>>>     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7089914
>>>>>>>>     So far, I'm not sure if Windows use ControlTextColor, I'll check
>>>>>>>> it.
>>>>>>>>
>>>>>>>>  For ease of review, I've uploaded Sean's change as a webrev [1].
>>>>>>>
>>>>>>> With the change, I see the following focus-related color settings in
>>>>>>> the
>>>>>>> WindowsLookAndFeel:
>>>>>>>
>>>>>>> Button.focus:           ControlTextColor
>>>>>>> Checkbox.focus:         ControlTextColor
>>>>>>> RadioButton.focus:      ControlTextColor
>>>>>>> Slider.focus:           ControlDarkShadowColor
>>>>>>> TabbedPane.focus:       ControlTextColor
>>>>>>> ToggleButton.focus:     ControlTextColor
>>>>>>>
>>>>>>> So the change of setting for Button, Checkbox and RadioButton
>>>>>>> conforms
>>>>>>> to what is already used for TabbedPane and ToggleButton.
>>>>>>>
>>>>>> But doesn't conform to Slider.focus...
>>>>>>
>>>>> Are you recommending that Slider.focus should be changed to
>>>>> ControlTextColor too ?
>>>>>
>>>>  No, I meant that we cannot fix some bugs by copy-paste method.
>>>>
>>>>>    From it's name, it's not entirely obvious to me that
>>>>>>>> 'ControlTextColor'
>>>>>>>>
>>>>>>> is really the ideal setting to use here, but it's also clear that
>>>>>>> it's a
>>>>>>> far better setting to use than the current hard-coded 'black'.
>>>>>>>
>>>>>> Yes, of course. The last question is which color is correct. We can't
>>>>>> change one incorrect color to another incorrect color...
>>>>>>
>>>>> I guess I hope that some knowledgeable person might be able to suggest
>>>>> /
>>>>> corroborate / refute the choice of setting here.
>>>>>
>>>>> It seems worse to consider sticking with a hard-coded, un-configurable
>>>>> value that has been demonstrated to cause problems, than to use a
>>>>> setting whose value can at least be configured, in practice fixes the
>>>>> problem's symptoms, and is already used in most other similar contexts
>>>>>  within the same look&  feel.
>>>>>
>>>>>
>>>>> Suggestions for how to improve things further are always welcome.
>>>>>
>>>> Your points sounds good. But as I said: we can't change one incorrect
>>>> color to another incorrect color (doesn't matter configurable it or not). I
>>>> attached  the screenshot that shows that ControlTextColor is not always
>>>> equal to color of selection frame (to reproduce this image press the
>>>> Advanced button and change color of "3D objects" to red).
>>>>
>>>> Regards, Pavel
>>>>
>>>
>>>
>>>
>>>  --
>>> Best Regards,
>>> Sean Chou
>>>
>>>
>>>
>>
>>
>>  --
>> Best Regards,
>> Sean Chou
>>
>>
>>
>
>
>  --
> Best Regards,
> Sean Chou
>
>
>


-- 
Best Regards,
Sean Chou




-- 
Best Regards,
Sean Chou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120110/16d8cb5f/attachment.html>

From alexandr.scherbatiy at oracle.com  Tue Jan 10 10:55:29 2012
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 10 Jan 2012 14:55:29 +0400
Subject: <Swing Dev> [8] Review request for 6505523: NullPointerException in
 BasicTreeUI when a node is removed by expansion listener
Message-ID: <4F0C1921.6030200@oracle.com>

Hello,

This is a request to review the fix for the issue:
6505523 NullPointerException in BasicTreeUI when a node is removed by 
expansion listener
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6505523

The webrev is http://cr.openjdk.java.net/~alexsch/6505523/webrev.01/

The fix checks that the path bounds do not become null for the 
isActualPath() method between actions: mouse pressed, tree node deleted, 
mouse released.

The bounds are also checked in the ensureRowsAreVisible() method in the 
same way as it fixed for the issue
4909150 WindowsTreeUI can cause NullPointerException occasionally
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4909150

The test case for the issue is added.

Thanks,
Alexandr.



From pavel.porvatov at oracle.com  Tue Jan 10 12:45:23 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Tue, 10 Jan 2012 16:45:23 +0400
Subject: <Swing Dev> [8] Review request for 6505523:
 NullPointerException in BasicTreeUI when a node is removed by expansion
 listener
In-Reply-To: <4F0C1921.6030200@oracle.com>
References: <4F0C1921.6030200@oracle.com>
Message-ID: <4F0C32E3.5090502@oracle.com>

Hi Alexander,

Looks good.
> Hello,
>
> This is a request to review the fix for the issue:
> 6505523 NullPointerException in BasicTreeUI when a node is removed by 
> expansion listener
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6505523
>
> The webrev is http://cr.openjdk.java.net/~alexsch/6505523/webrev.01/
>
> The fix checks that the path bounds do not become null for the 
> isActualPath() method between actions: mouse pressed, tree node 
> deleted, mouse released.
>
> The bounds are also checked in the ensureRowsAreVisible() method in 
> the same way as it fixed for the issue
> 4909150 WindowsTreeUI can cause NullPointerException occasionally
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4909150
>
> The test case for the issue is added.
>
> Thanks,
> Alexandr.
>



From zhouyx at linux.vnet.ibm.com  Fri Jan 13 07:43:16 2012
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Fri, 13 Jan 2012 15:43:16 +0800
Subject: <Swing Dev> Request review for 7089914: Focus on image icons are
 not visible in javaws cache with high contrast mode
Message-ID: <CAOo=rxV4_LdLTj=KuwaMHD6fep_XBOdZn4Mr-wnTtP0663r0Zw@mail.gmail.com>

Hi all,

   This is for bug 7089914,
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7089914 .
OpenJDK uses black as focus color in windows LAF. However, in high contrast
mode, windows
uses white as focus color.
   In additional, the patch also modified WindowsRadioButtonUI.java so it
will reload its style
when system setting is changed.

   The webrev link is :
http://cr.openjdk.java.net/~zhouyx/7089914/webrev.02/

The previous discussions are:
http://mail.openjdk.java.net/pipermail/swing-dev/2011-September/001703.html
http://mail.openjdk.java.net/pipermail/swing-dev/2011-October/001794.html
http://mail.openjdk.java.net/pipermail/swing-dev/2011-December/001871.html

   Any comments on the this version? thanks.

-- 
Best Regards,
Sean Chou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120113/1e0e8190/attachment.html>

From anthony.petrov at oracle.com  Fri Jan 13 12:38:03 2012
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 13 Jan 2012 16:38:03 +0400
Subject: <Swing Dev> <AWT Dev> JFileChooser: Nullpointer navigating
 shortcut folder on Windows
In-Reply-To: <33133412.post@talk.nabble.com>
References: <33133412.post@talk.nabble.com>
Message-ID: <4F1025AB.6010209@oracle.com>

Hi Christiaan,

JFileChooser is a Swing component, and as such I'm forwarding this 
message to the swing-dev@ mailing list.

--
best regards,
Anthony

On 1/13/2012 2:42 PM, Christiaan wrote:
> Not sure if this is the right place to ask, but when you click on a shortcut
> folder in JFileChooser on Windows you will get a Nullpointer. 
> 
> There used to be a bug in the bug database
> (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6550546) which had the
> status "fix delivered" for jdk 7 b77. However, it is no longer there, and
> the bug still happens in 7u2. 
> 
> Following bug is still referring to it: 
> 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6672017
> 
> What happened and will it be fixed? 
> 
> kind regards, 
> Christiaan


From pavel.porvatov at oracle.com  Sat Jan 14 14:19:37 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Sat, 14 Jan 2012 18:19:37 +0400
Subject: <Swing Dev> <AWT Dev> JFileChooser: Nullpointer navigating
 shortcut folder on Windows
In-Reply-To: <4F1025AB.6010209@oracle.com>
References: <33133412.post@talk.nabble.com> <4F1025AB.6010209@oracle.com>
Message-ID: <4F118EF9.9020905@oracle.com>

Hi Christiaan,

The fix of the bug is here:
http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/c06c491eff67

I take a look at jdk8 sources and I see that the fix exists in the 
sources...  Is this bug reproducible on jdk8?

Regards, Pavel

> Hi Christiaan,
>
> JFileChooser is a Swing component, and as such I'm forwarding this 
> message to the swing-dev@ mailing list.
>
> -- 
> best regards,
> Anthony
>
> On 1/13/2012 2:42 PM, Christiaan wrote:
>> Not sure if this is the right place to ask, but when you click on a 
>> shortcut
>> folder in JFileChooser on Windows you will get a Nullpointer.
>> There used to be a bug in the bug database
>> (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6550546) which 
>> had the
>> status "fix delivered" for jdk 7 b77. However, it is no longer there, 
>> and
>> the bug still happens in 7u2.
>> Following bug is still referring to it:
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6672017
>>
>> What happened and will it be fixed?
>> kind regards, Christiaan



From pavel.porvatov at oracle.com  Mon Jan 16 10:46:48 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Mon, 16 Jan 2012 14:46:48 +0400
Subject: <Swing Dev> Request review for 7089914: Focus on image icons
 are not visible in javaws cache with high contrast mode
In-Reply-To: <CAOo=rxV4_LdLTj=KuwaMHD6fep_XBOdZn4Mr-wnTtP0663r0Zw@mail.gmail.com>
References: <CAOo=rxV4_LdLTj=KuwaMHD6fep_XBOdZn4Mr-wnTtP0663r0Zw@mail.gmail.com>
Message-ID: <4F140018.7070001@oracle.com>

Hi Sean,

There are several comments for your patch:

1. I found one bug. In Win 7 there are several differnet High Contrast 
themes. Under one of them ("High Contrast White") focus is not visible...

2. I also don't like synthetic property. Any desktop property has 
listener (see com.sun.java.swing.plaf.windows.DesktopProperty#pcl) and 
updated when correspondent value is changed. But your 
win.button.focusColor property is updated only while full property 
reloading.

3. Please don't add references to bugs in the code. Everybody can trace 
history of the code by VCS.

4. The changes in the class WindowsRadioButtonUI looks good. Is it 
possible to make your TestButton test an automatic one and add it to the 
fix?

Regards, Pavel

> Hi all,
>
>    This is for bug 7089914, 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7089914 .
> OpenJDK uses black as focus color in windows LAF. However, in high 
> contrast mode, windows
> uses white as focus color.
>    In additional, the patch also modified WindowsRadioButtonUI.java so 
> it will reload its style
> when system setting is changed.
>
>    The webrev link is : 
> http://cr.openjdk.java.net/~zhouyx/7089914/webrev.02/ 
> <http://cr.openjdk.java.net/%7Ezhouyx/7089914/webrev.02/>
>
> The previous discussions are:
> http://mail.openjdk.java.net/pipermail/swing-dev/2011-September/001703.html
> http://mail.openjdk.java.net/pipermail/swing-dev/2011-October/001794.html
> http://mail.openjdk.java.net/pipermail/swing-dev/2011-December/001871.html
>
> Any comments on the this version? thanks.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120116/49c70338/attachment.html>

From christiaan_db at hotmail.com  Mon Jan 16 10:36:35 2012
From: christiaan_db at hotmail.com (Christiaan)
Date: Mon, 16 Jan 2012 02:36:35 -0800 (PST)
Subject: <Swing Dev> <AWT Dev> JFileChooser: Nullpointer navigating
 shortcut folder on Windows
In-Reply-To: <4F1025AB.6010209@oracle.com>
References: <4F1025AB.6010209@oracle.com>
Message-ID: <33146702.post@talk.nabble.com>


Dear Anthony,
I do see the bug again in the bug database, so probably just a temporary
problem. I tried it with jdk 8 b21 but I still get this error. I do see a
bit of a difference with the reported bug in the database. I select the
desktop option in the file chooser and next I double click on the available
short cut folder. I get the following error:

java.lang.InternalError: Unable to bind C:\Users\cdesbouvrie\Desktop\Data -
Shortcut.lnk to parent
	at sun.awt.shell.Win32ShellFolder2$4.call(Win32ShellFolder2.java:414)

Complete stack trace:
java.lang.InternalError: Unable to bind C:\Users\cdesbouvrie\Desktop\Data -
Shortcut.lnk to parent
	at sun.awt.shell.Win32ShellFolder2$4.call(Win32ShellFolder2.java:414)
	at sun.awt.shell.Win32ShellFolder2$4.call(Win32ShellFolder2.java:398)
	at
sun.awt.shell.Win32ShellFolderManager2$ComInvoker.invoke(Win32ShellFolderManager2.java:533)
	at sun.awt.shell.ShellFolder.invoke(ShellFolder.java:514)
	at
sun.awt.shell.Win32ShellFolder2.getIShellFolder(Win32ShellFolder2.java:398)
	at sun.awt.shell.Win32ShellFolder2.access$200(Win32ShellFolder2.java:72)
	at sun.awt.shell.Win32ShellFolder2$16.call(Win32ShellFolder2.java:1088)
	at sun.awt.shell.Win32ShellFolder2$16.call(Win32ShellFolder2.java:1086)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
	at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
	at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
	at
sun.awt.shell.Win32ShellFolderManager2$ComInvoker$3.run(Win32ShellFolderManager2.java:502)
	at java.lang.Thread.run(Thread.java:722)

kind regards,
Christiaan
-- 
View this message in context: http://old.nabble.com/Re%3A-%3CSwing-Dev%3E-%3CAWT-Dev%3E-JFileChooser%3A-Nullpointer-navigating-shortcut-folder-on-Windows-tp33133976p33146702.html
Sent from the OpenJDK Swing Development mailing list archive at Nabble.com.



From christiaan_db at hotmail.com  Mon Jan 16 10:39:29 2012
From: christiaan_db at hotmail.com (Christiaan)
Date: Mon, 16 Jan 2012 02:39:29 -0800 (PST)
Subject: <Swing Dev> <AWT Dev> JFileChooser: Nullpointer navigating
 shortcut folder on Windows
In-Reply-To: <4F118EF9.9020905@oracle.com>
References: <4F1025AB.6010209@oracle.com> <4F118EF9.9020905@oracle.com>
Message-ID: <33146716.post@talk.nabble.com>


Dear Pavel, 
I do see the bug again in the bug database, so probably just a temporary
problem. I tried it with jdk 8 b21 but I still get this error. I do see a
difference with the reported bug in the database. I select the desktop
option in the file chooser and next I double click on the available short
cut folder (so I don't do anything in the drop down box as the bug
description). Not displaying the short cut folder as the bug fix shows
probably isn't really a good solution. I get the following error: 

java.lang.InternalError: Unable to bind C:\Users\cdesbouvrie\Desktop\Data -
Shortcut.lnk to parent 
        at
sun.awt.shell.Win32ShellFolder2$4.call(Win32ShellFolder2.java:414) 

Complete stack trace: 
java.lang.InternalError: Unable to bind C:\Users\cdesbouvrie\Desktop\Data -
Shortcut.lnk to parent 
        at
sun.awt.shell.Win32ShellFolder2$4.call(Win32ShellFolder2.java:414) 
        at
sun.awt.shell.Win32ShellFolder2$4.call(Win32ShellFolder2.java:398) 
        at
sun.awt.shell.Win32ShellFolderManager2$ComInvoker.invoke(Win32ShellFolderManager2.java:533) 
        at sun.awt.shell.ShellFolder.invoke(ShellFolder.java:514) 
        at
sun.awt.shell.Win32ShellFolder2.getIShellFolder(Win32ShellFolder2.java:398) 
        at
sun.awt.shell.Win32ShellFolder2.access$200(Win32ShellFolder2.java:72) 
        at
sun.awt.shell.Win32ShellFolder2$16.call(Win32ShellFolder2.java:1088) 
        at
sun.awt.shell.Win32ShellFolder2$16.call(Win32ShellFolder2.java:1086) 
        at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) 
        at java.util.concurrent.FutureTask.run(FutureTask.java:166) 
        at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) 
        at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) 
        at
sun.awt.shell.Win32ShellFolderManager2$ComInvoker$3.run(Win32ShellFolderManager2.java:502) 
        at java.lang.Thread.run(Thread.java:722) 

kind regards, 
Christiaan
-- 
View this message in context: http://old.nabble.com/Re%3A-%3CSwing-Dev%3E-%3CAWT-Dev%3E-JFileChooser%3A-Nullpointer-navigating-shortcut-folder-on-Windows-tp33133976p33146716.html
Sent from the OpenJDK Swing Development mailing list archive at Nabble.com.



From pavel.porvatov at oracle.com  Mon Jan 16 14:44:48 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Mon, 16 Jan 2012 18:44:48 +0400
Subject: <Swing Dev> <AWT Dev> JFileChooser: Nullpointer navigating
 shortcut folder on Windows
In-Reply-To: <33146716.post@talk.nabble.com>
References: <4F1025AB.6010209@oracle.com> <4F118EF9.9020905@oracle.com>
	<33146716.post@talk.nabble.com>
Message-ID: <4F1437E0.3020702@oracle.com>

Hi Christiaan,
> Dear Pavel,
> I do see the bug again in the bug database, so probably just a temporary
> problem. I tried it with jdk 8 b21 but I still get this error. I do see a
> difference with the reported bug in the database. I select the desktop
> option in the file chooser and next I double click on the available short
> cut folder (so I don't do anything in the drop down box as the bug
> description).
I tried the described steps with the SwingSet2 demo and cannot reproduce 
your problem.
My environment is:

Microsoft Windows [Version 6.1.7601]
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b21)
Java HotSpot(TM) Client VM (build 23.0-b09, mixed mode)

> Not displaying the short cut folder as the bug fix shows
> probably isn't really a good solution.
The solution is good, because native file chooser doesn't contain 
shortcuts in drop-down list as well. But of course other errors also 
should be fixed....
> I get the following error:
>
> java.lang.InternalError: Unable to bind C:\Users\cdesbouvrie\Desktop\Data -
> Shortcut.lnk to parent
>          at
> sun.awt.shell.Win32ShellFolder2$4.call(Win32ShellFolder2.java:414)
>
> Complete stack trace:
> java.lang.InternalError: Unable to bind C:\Users\cdesbouvrie\Desktop\Data -
> Shortcut.lnk to parent
>          at
> sun.awt.shell.Win32ShellFolder2$4.call(Win32ShellFolder2.java:414)
>          at
> sun.awt.shell.Win32ShellFolder2$4.call(Win32ShellFolder2.java:398)
>          at
> sun.awt.shell.Win32ShellFolderManager2$ComInvoker.invoke(Win32ShellFolderManager2.java:533)
>          at sun.awt.shell.ShellFolder.invoke(ShellFolder.java:514)
>          at
> sun.awt.shell.Win32ShellFolder2.getIShellFolder(Win32ShellFolder2.java:398)
>          at
> sun.awt.shell.Win32ShellFolder2.access$200(Win32ShellFolder2.java:72)
>          at
> sun.awt.shell.Win32ShellFolder2$16.call(Win32ShellFolder2.java:1088)
>          at
> sun.awt.shell.Win32ShellFolder2$16.call(Win32ShellFolder2.java:1086)
>          at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
>          at java.util.concurrent.FutureTask.run(FutureTask.java:166)
>          at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>          at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>          at
> sun.awt.shell.Win32ShellFolderManager2$ComInvoker$3.run(Win32ShellFolderManager2.java:502)
>          at java.lang.Thread.run(Thread.java:722)
>
> kind regards,
> Christiaan

Regards, Pavel


From Johannes.Lichtenberger at uni-konstanz.de  Mon Jan 16 16:42:15 2012
From: Johannes.Lichtenberger at uni-konstanz.de (Johannes.Lichtenberger)
Date: Mon, 16 Jan 2012 17:42:15 +0100
Subject: <Swing Dev> JSplitPane / heavyweight vs. lightweight components
Message-ID: <4F145367.4020907@uni-konstanz.de>

Hello,

I'm adding a JSplitPane to a JPanel within a frame, and the frame has a
JMenuBar added. I'm now adding a JPanel component which embeds a PApplet
component (processing from processing.org) which extends Applet to the
JSplitPane. It doesn't seem to work even though I've added

    /**
     * Handle mix of heavyweight ({@link PApplet}) and leightweight (
{@link JMenuBar}) components.
     */
    public void handleHLWeight() {
        final Container parent = mView.component().getParent();
        if (parent instanceof JComponent) {
            ((JComponent)parent).revalidate();
        }
        final Window window = SwingUtilities.getWindowAncestor(this);
        if (window != null) {
            window.validate();
        }
    }

to the embedded view which is for instance called within draw(), a
method which is called frameRate(int)-times per second.

Without the JSplitPane it seems fine, but now I'm adding another view
side by side and it doesn't work anymore :(

Well to recap the setup:

View extends JPane => is inserted in a JSplitPane.
View embeds a PApplet instance via (add(Component)).
JSplitPane is inserted in a JPane and added to the contentPane of a
JFrame instance together with a JMenuBar instance (via
setJMenuBar(JMenuBar)).

I'm using Java7.

johannes at luna:~/workspace/treetank$ java -version
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode)

The setup of the JSplitPane is as follows:

    /**
     * Setup of the {@link JSplitPane} reference.
     *
     * @param paramPane
     *            {@link JSplitPane} reference
     * @param paramTmpView
     *            {@link JComponent} reference to the left
     * @param paramView
     *            {@link JComponent} reference to the right
     */
    private void
        setupPane(final JSplitPane paramPane, final JComponent
paramTmpView, final JComponent paramView) {
        assert paramPane != null;
        assert paramTmpView != null;
        assert paramView != null;
        paramPane.setSize(new Dimension(mGUI.getWidth(), mGUI.getHeight()));
        paramPane.setAlignmentX(mGUI.getWidth() / 2f);
        paramPane.setAlignmentY(mGUI.getHeight() / 2f);
        paramPane.setDividerLocation(0.5);
        paramPane.setContinuousLayout(true);
        paramPane.setLeftComponent(paramTmpView);
        paramPane.setRightComponent(paramView);

paramPane.addPropertyChangeListener(JSplitPane.DIVIDER_LOCATION_PROPERTY, new
Listener(paramPane));
        final Container parent = paramPane.getParent();
        if (parent instanceof JComponent) {
            ((JComponent)parent).revalidate();
        }
        final Window window = SwingUtilities.getWindowAncestor(this);
        if (window != null) {
            window.validate();
        }
    }

I'm not sure, I thing the final code is useless with revalidate() and so on.

kind regards,
Johannes


From christiaan_db at hotmail.com  Mon Jan 16 17:08:27 2012
From: christiaan_db at hotmail.com (Christiaan)
Date: Mon, 16 Jan 2012 09:08:27 -0800 (PST)
Subject: <Swing Dev> <AWT Dev> JFileChooser: Nullpointer navigating
 shortcut folder on Windows
In-Reply-To: <4F1437E0.3020702@oracle.com>
References: <4F1025AB.6010209@oracle.com> <4F118EF9.9020905@oracle.com>
	<33146716.post@talk.nabble.com> <4F1437E0.3020702@oracle.com>
Message-ID: <33148941.post@talk.nabble.com>


Hi Pavel,
thanks for making me aware of this, I cannot reproduce it either with
SwingSet. We use a custom FileSystemView which has a fix for
javax.swing.jfilechooser.Windows FileSystemView. As it seems, using this
custom FileSystemView causes the exception. I will check and see if the fix
is still required with Java 7.

kind regards,
Christiaan
-- 
View this message in context: http://old.nabble.com/Re%3A-%3CSwing-Dev%3E-%3CAWT-Dev%3E-JFileChooser%3A-Nullpointer-navigating-shortcut-folder-on-Windows-tp33133976p33148941.html
Sent from the OpenJDK Swing Development mailing list archive at Nabble.com.



From pavel.porvatov at oracle.com  Tue Jan 17 09:30:17 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Tue, 17 Jan 2012 13:30:17 +0400
Subject: <Swing Dev> JSplitPane / heavyweight vs. lightweight components
In-Reply-To: <4F145367.4020907@uni-konstanz.de>
References: <4F145367.4020907@uni-konstanz.de>
Message-ID: <4F153FA9.2000007@oracle.com>

Hi Johannes,

Could you please provide a small test that can be run and which shows 
the problem?

Thanks, Pavel
> Hello,
>
> I'm adding a JSplitPane to a JPanel within a frame, and the frame has a
> JMenuBar added. I'm now adding a JPanel component which embeds a PApplet
> component (processing from processing.org) which extends Applet to the
> JSplitPane. It doesn't seem to work even though I've added
>
>      /**
>       * Handle mix of heavyweight ({@link PApplet}) and leightweight (
> {@link JMenuBar}) components.
>       */
>      public void handleHLWeight() {
>          final Container parent = mView.component().getParent();
>          if (parent instanceof JComponent) {
>              ((JComponent)parent).revalidate();
>          }
>          final Window window = SwingUtilities.getWindowAncestor(this);
>          if (window != null) {
>              window.validate();
>          }
>      }
>
> to the embedded view which is for instance called within draw(), a
> method which is called frameRate(int)-times per second.
>
> Without the JSplitPane it seems fine, but now I'm adding another view
> side by side and it doesn't work anymore :(
>
> Well to recap the setup:
>
> View extends JPane =>  is inserted in a JSplitPane.
> View embeds a PApplet instance via (add(Component)).
> JSplitPane is inserted in a JPane and added to the contentPane of a
> JFrame instance together with a JMenuBar instance (via
> setJMenuBar(JMenuBar)).
>
> I'm using Java7.
>
> johannes at luna:~/workspace/treetank$ java -version
> java version "1.7.0"
> Java(TM) SE Runtime Environment (build 1.7.0-b147)
> Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode)
>
> The setup of the JSplitPane is as follows:
>
>      /**
>       * Setup of the {@link JSplitPane} reference.
>       *
>       * @param paramPane
>       *            {@link JSplitPane} reference
>       * @param paramTmpView
>       *            {@link JComponent} reference to the left
>       * @param paramView
>       *            {@link JComponent} reference to the right
>       */
>      private void
>          setupPane(final JSplitPane paramPane, final JComponent
> paramTmpView, final JComponent paramView) {
>          assert paramPane != null;
>          assert paramTmpView != null;
>          assert paramView != null;
>          paramPane.setSize(new Dimension(mGUI.getWidth(), mGUI.getHeight()));
>          paramPane.setAlignmentX(mGUI.getWidth() / 2f);
>          paramPane.setAlignmentY(mGUI.getHeight() / 2f);
>          paramPane.setDividerLocation(0.5);
>          paramPane.setContinuousLayout(true);
>          paramPane.setLeftComponent(paramTmpView);
>          paramPane.setRightComponent(paramView);
>
> paramPane.addPropertyChangeListener(JSplitPane.DIVIDER_LOCATION_PROPERTY, new
> Listener(paramPane));
>          final Container parent = paramPane.getParent();
>          if (parent instanceof JComponent) {
>              ((JComponent)parent).revalidate();
>          }
>          final Window window = SwingUtilities.getWindowAncestor(this);
>          if (window != null) {
>              window.validate();
>          }
>      }
>
> I'm not sure, I thing the final code is useless with revalidate() and so on.
>
> kind regards,
> Johannes



From zhouyx at linux.vnet.ibm.com  Tue Jan 17 09:36:58 2012
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Tue, 17 Jan 2012 17:36:58 +0800
Subject: <Swing Dev> Request review for 7089914: Focus on image icons
 are not visible in javaws cache with high contrast mode
In-Reply-To: <4F140018.7070001@oracle.com>
References: <CAOo=rxV4_LdLTj=KuwaMHD6fep_XBOdZn4Mr-wnTtP0663r0Zw@mail.gmail.com>
	<4F140018.7070001@oracle.com>
Message-ID: <CAOo=rxU5JDeHXYNNsoa05VFaB6Wv+kqok4CWHBnnyLafBGGjtw@mail.gmail.com>

Hi Pavel,

   Thanks for your comments. About the 4th comment, do you mean a webrev
includes the changes in the class WindowsRadioButtonUI
and an automatic test case ?

On Mon, Jan 16, 2012 at 6:46 PM, Pavel Porvatov
<pavel.porvatov at oracle.com>wrote:

>  Hi Sean,
>
> There are several comments for your patch:
>
> 1. I found one bug. In Win 7 there are several differnet High Contrast
> themes. Under one of them ("High Contrast White") focus is not visible...
>
> 2. I also don't like synthetic property. Any desktop property has listener
> (see com.sun.java.swing.plaf.windows.DesktopProperty#pcl) and updated when
> correspondent value is changed. But your win.button.focusColor property is
> updated only while full property reloading.
>
> 3. Please don't add references to bugs in the code. Everybody can trace
> history of the code by VCS.
>
> 4. The changes in the class WindowsRadioButtonUI looks good. Is it
> possible to make your TestButton test an automatic one and add it to the
> fix?
>
> Regards, Pavel
>
>
>  Hi all,
>
>     This is for bug 7089914,
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7089914 .
> OpenJDK uses black as focus color in windows LAF. However, in high
> contrast mode, windows
> uses white as focus color.
>    In additional, the patch also modified WindowsRadioButtonUI.java so it
> will reload its style
> when system setting is changed.
>
>     The webrev link is :
> http://cr.openjdk.java.net/~zhouyx/7089914/webrev.02/
>
>  The previous discussions are:
> http://mail.openjdk.java.net/pipermail/swing-dev/2011-September/001703.html
> http://mail.openjdk.java.net/pipermail/swing-dev/2011-October/001794.html
> http://mail.openjdk.java.net/pipermail/swing-dev/2011-December/001871.html
>
>     Any comments on the this version? thanks.
>
>
>


-- 
Best Regards,
Sean Chou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120117/b5df7542/attachment.html>

From Johannes.Lichtenberger at uni-konstanz.de  Tue Jan 17 10:28:52 2012
From: Johannes.Lichtenberger at uni-konstanz.de (Johannes.Lichtenberger)
Date: Tue, 17 Jan 2012 11:28:52 +0100
Subject: <Swing Dev> Reinitializing an Applet
Message-ID: <4F154D64.3040605@uni-konstanz.de>

Hello,

I want to reinitialize an applet inside a JPanel (the view/class extends
JPanel). For example, I have the following method:

    /**
     * {@inheritDoc}
     */
    @Override
    public void refreshInit() {
        mDB = mNotifier.getGUI().getReadDB();
        boolean firstInit = mEmbed == null ? true : false;

        // Create instance of processing innerclass.
        if (!firstInit) {
            mEmbed.dispose();
        }
        mEmbed = new Embedded(this, mNotifier);
        if (firstInit) {
            add(mEmbed);
        } else {
            revalidate();
            repaint();
        }
        /*
         * Important to call this whenever embedding a PApplet.
         * It ensures that the animation thread is started and
         * that other internal variables are properly set.
         */
        mEmbed.init();
        mEmbed.refreshInit();
    }

mEmbed is an instance of a inner class which extends PApplet, the
processing core-class which itself extends Applet.

The thing is it doesn't reinitialize the new applet somehow properly and
the JMenuBar of the parent frame is greyed out but can be used nontheless.

The following code worked for extending JScrollPane:

    /**
     * {@inheritDoc}
     */
    @Override
    public void refreshInit() {
        mDB = mNotifier.getGUI().getReadDB();

        if (mEmbed != null) {
            mEmbed.mControl.getGUIInstance().mParent.dispose();
            mEmbed.mControl.getGUIInstance().resetGUI();
            mEmbed.mControl.resetControl();
            mEmbed.mEmbeddedView.resetEmbedded();
            mEmbed.mEmbeddedView = null;
            // mEmbed.dispose();
            mEmbed = null;
        }

        // Create instance of processing innerclass.
        mEmbed = new Embedded(this, mNotifier);
        setViewportView(mEmbed);
        /*
         * Important to call this whenever embedding a PApplet.
         * It ensures that the animation thread is started and
         * that other internal variables are properly set.
         */
        mEmbed.init();
        mEmbed.refreshInit();
    }

kind regards,
Johannes


From pavel.porvatov at oracle.com  Tue Jan 17 10:39:52 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Tue, 17 Jan 2012 14:39:52 +0400
Subject: <Swing Dev> Request review for 7089914: Focus on image icons
 are not visible in javaws cache with high contrast mode
In-Reply-To: <CAOo=rxU5JDeHXYNNsoa05VFaB6Wv+kqok4CWHBnnyLafBGGjtw@mail.gmail.com>
References: <CAOo=rxV4_LdLTj=KuwaMHD6fep_XBOdZn4Mr-wnTtP0663r0Zw@mail.gmail.com>
	<4F140018.7070001@oracle.com>
	<CAOo=rxU5JDeHXYNNsoa05VFaB6Wv+kqok4CWHBnnyLafBGGjtw@mail.gmail.com>
Message-ID: <4F154FF8.1050302@oracle.com>

Hi Sean,
> Hi Pavel,
>
>    Thanks for your comments. About the 4th comment, do you mean a 
> webrev includes the changes in the class WindowsRadioButtonUI
> and an automatic test case ?
You mailed some time ago the following:
------
And I also found a bug in WindowsRadioButtonUI which
blocks radiobutton and checkbox from reloading their styles,
its fix(override the uninstallDefaults ) is included in the webrev
as well.

A simple testcase which includes checkbox and radiobutton
is here
.....
------

I meant that automatic test for the WindowsRadioButtonUI changes will be 
great.

Thanks, Pavel
>
> On Mon, Jan 16, 2012 at 6:46 PM, Pavel Porvatov 
> <pavel.porvatov at oracle.com <mailto:pavel.porvatov at oracle.com>> wrote:
>
>     Hi Sean,
>
>     There are several comments for your patch:
>
>     1. I found one bug. In Win 7 there are several differnet High
>     Contrast themes. Under one of them ("High Contrast White") focus
>     is not visible...
>
>     2. I also don't like synthetic property. Any desktop property has
>     listener (see com.sun.java.swing.plaf.windows.DesktopProperty#pcl)
>     and updated when correspondent value is changed. But your
>     win.button.focusColor property is updated only while full property
>     reloading.
>
>     3. Please don't add references to bugs in the code. Everybody can
>     trace history of the code by VCS.
>
>     4. The changes in the class WindowsRadioButtonUI looks good. Is it
>     possible to make your TestButton test an automatic one and add it
>     to the fix?
>
>     Regards, Pavel
>
>
>>     Hi all,
>>
>>        This is for bug 7089914,
>>     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7089914 .
>>     OpenJDK uses black as focus color in windows LAF. However, in
>>     high contrast mode, windows
>>     uses white as focus color.
>>        In additional, the patch also
>>     modified WindowsRadioButtonUI.java so it will reload its style
>>     when system setting is changed.
>>
>>        The webrev link is :
>>     http://cr.openjdk.java.net/~zhouyx/7089914/webrev.02/
>>     <http://cr.openjdk.java.net/%7Ezhouyx/7089914/webrev.02/>
>>
>>     The previous discussions are:
>>     http://mail.openjdk.java.net/pipermail/swing-dev/2011-September/001703.html
>>     http://mail.openjdk.java.net/pipermail/swing-dev/2011-October/001794.html
>>     http://mail.openjdk.java.net/pipermail/swing-dev/2011-December/001871.html
>>
>>     Any comments on the this version? thanks.
>
>
>
>
> -- 
> Best Regards,
> Sean Chou
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120117/52d05791/attachment.html>

From pavel.porvatov at oracle.com  Tue Jan 17 10:49:39 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Tue, 17 Jan 2012 14:49:39 +0400
Subject: <Swing Dev> Reinitializing an Applet
In-Reply-To: <4F154D64.3040605@uni-konstanz.de>
References: <4F154D64.3040605@uni-konstanz.de>
Message-ID: <4F155243.8000605@oracle.com>

Hi Johannes,

It's hard to imagine what methods (like mEmbed.dispose()) do. Could you 
please provide a small test that can be run and which shows the problem?

Thanks, Pavel

> Hello,
>
> I want to reinitialize an applet inside a JPanel (the view/class extends
> JPanel). For example, I have the following method:
>
>      /**
>       * {@inheritDoc}
>       */
>      @Override
>      public void refreshInit() {
>          mDB = mNotifier.getGUI().getReadDB();
>          boolean firstInit = mEmbed == null ? true : false;
>
>          // Create instance of processing innerclass.
>          if (!firstInit) {
>              mEmbed.dispose();
>          }
>          mEmbed = new Embedded(this, mNotifier);
>          if (firstInit) {
>              add(mEmbed);
>          } else {
>              revalidate();
>              repaint();
>          }
>          /*
>           * Important to call this whenever embedding a PApplet.
>           * It ensures that the animation thread is started and
>           * that other internal variables are properly set.
>           */
>          mEmbed.init();
>          mEmbed.refreshInit();
>      }
>
> mEmbed is an instance of a inner class which extends PApplet, the
> processing core-class which itself extends Applet.
>
> The thing is it doesn't reinitialize the new applet somehow properly and
> the JMenuBar of the parent frame is greyed out but can be used nontheless.
>
> The following code worked for extending JScrollPane:
>
>      /**
>       * {@inheritDoc}
>       */
>      @Override
>      public void refreshInit() {
>          mDB = mNotifier.getGUI().getReadDB();
>
>          if (mEmbed != null) {
>              mEmbed.mControl.getGUIInstance().mParent.dispose();
>              mEmbed.mControl.getGUIInstance().resetGUI();
>              mEmbed.mControl.resetControl();
>              mEmbed.mEmbeddedView.resetEmbedded();
>              mEmbed.mEmbeddedView = null;
>              // mEmbed.dispose();
>              mEmbed = null;
>          }
>
>          // Create instance of processing innerclass.
>          mEmbed = new Embedded(this, mNotifier);
>          setViewportView(mEmbed);
>          /*
>           * Important to call this whenever embedding a PApplet.
>           * It ensures that the animation thread is started and
>           * that other internal variables are properly set.
>           */
>          mEmbed.init();
>          mEmbed.refreshInit();
>      }
>
> kind regards,
> Johannes



From christiaan_db at hotmail.com  Tue Jan 17 11:12:53 2012
From: christiaan_db at hotmail.com (Christiaan)
Date: Tue, 17 Jan 2012 03:12:53 -0800 (PST)
Subject: <Swing Dev> <AWT Dev> JFileChooser: Nullpointer navigating
 shortcut folder on Windows
In-Reply-To: <4F1437E0.3020702@oracle.com>
References: <4F1025AB.6010209@oracle.com> <4F118EF9.9020905@oracle.com>
	<33146716.post@talk.nabble.com> <4F1437E0.3020702@oracle.com>
Message-ID: <33153360.post@talk.nabble.com>


Hi Pavel,
just to update you on this, I can confirm java 7 fixes both traversing
short-cut folders as well as traversing local (the client machine setting up
the rdp connection) folders accessed through RDP. Great!

What does not work is traversing local short-cut folders accessed through
RDP (on the remote machine short-cut folders can be traversed!). No error is
thrown, it simply does not traverse it as soon as you double-click on it.

kind regards,
Christiaan
-- 
View this message in context: http://old.nabble.com/Re%3A-%3CSwing-Dev%3E-%3CAWT-Dev%3E-JFileChooser%3A-Nullpointer-navigating-shortcut-folder-on-Windows-tp33133976p33153360.html
Sent from the OpenJDK Swing Development mailing list archive at Nabble.com.



From Johannes.Lichtenberger at uni-konstanz.de  Tue Jan 17 11:42:18 2012
From: Johannes.Lichtenberger at uni-konstanz.de (Johannes.Lichtenberger)
Date: Tue, 17 Jan 2012 12:42:18 +0100
Subject: <Swing Dev> JSplitPane / heavyweight vs. lightweight components
In-Reply-To: <4F153FA9.2000007@oracle.com>
References: <4F145367.4020907@uni-konstanz.de> <4F153FA9.2000007@oracle.com>
Message-ID: <4F155E9A.60903@uni-konstanz.de>

On 01/17/2012 10:30 AM, Pavel Porvatov wrote:
> Hi Johannes,
> 
> Could you please provide a small test that can be run and which shows
> the problem?

Hi Pavel,

I'm currently not able to provide an SCCE as it invokes and depends on
many classes :( but I hope I can share the code on github very soon.

But maybe a JScrollPane or JPanel instance inside a JSplitPane with an
embedded applet should suffice. The other view is either the same (with
an embedded Applet or a "simple" JPanel.

kind regards,
Johannes



From Johannes.Lichtenberger at uni-konstanz.de  Tue Jan 17 12:16:30 2012
From: Johannes.Lichtenberger at uni-konstanz.de (Johannes.Lichtenberger)
Date: Tue, 17 Jan 2012 13:16:30 +0100
Subject: <Swing Dev> Reinitializing an Applet
In-Reply-To: <4F155243.8000605@oracle.com>
References: <4F154D64.3040605@uni-konstanz.de> <4F155243.8000605@oracle.com>
Message-ID: <4F15669E.60602@uni-konstanz.de>

On 01/17/2012 11:49 AM, Pavel Porvatov wrote:
> Hi Johannes,
> 
> It's hard to imagine what methods (like mEmbed.dispose()) do. Could you
> please provide a small test that can be run and which shows the problem?

Hello Pavel,

maybe [1] helps clarifying some issues. mEmbedded is an instance of
PApplet which extends Applet. I'm just embedding it into a JPanel or
JScrollPane instead of directly in a JFrame.

Now I want to create a new instance of the embedded Applet but at first
dispose the currently running applet (and thus the running Animation
Thread which is started from the PApplet (processing)).

At the time it somehow messes up as I'm creating a new embedded
instance, a new PApplet/Applet instance. I think the problem is how I
can dispose or destroy an instance and bind a new instance to mEmbedded.
In the first place everything works fine (except the
heavyweight/lightweight issue if I'm inserting the (P)Applet into a
JSplitPane on one side. Other than the the applet is initialized
properly and the heavyweight vs. lightweight issue also doesn't appear
when I'm adding the applet to a JPanel or JScrollPane which is added to
another JPanel which then is added to a JFrame instead of adding the
JPanel/JScrollPane to a JSplitPane. I think the JSplitPane has somehow
issues with heavyweight vs. lightweight components.

Other than that I suppose it boils down to how I can safely reinitialize
an Applet/bind the variable to a new Applet.

First nulling the mEmbedded instance doesn't work either, the new
instance somehow gets messed up and the JMenuBar is greyed out which is
added to the parent JFrame.

Within a JScrollPane however it's working with setViewPort(mEmbedded),
to the new instance, maybe the revalidation(), repaint() is not correct.

kind regards,
Johannes

[1]
http://processing.googlecode.com/svn/trunk/processing/build/javadoc/core/processing/core/PApplet.html



From anthony.petrov at oracle.com  Tue Jan 17 13:48:24 2012
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 17 Jan 2012 17:48:24 +0400
Subject: <Swing Dev> JSplitPane / heavyweight vs. lightweight components
In-Reply-To: <4F145367.4020907@uni-konstanz.de>
References: <4F145367.4020907@uni-konstanz.de>
Message-ID: <4F157C28.6020800@oracle.com>

Hi Johannes,

Does running your app with the -Djava.awt.smartInvalidate=true command 
line argument resolve anything? Please note that you have to execute 
this workaround revalidation mantra upon any changes performed by the 
user to the JSplitPane (i.e. on each moving of the split pane divider). 
Also, when running with the smartInvalidate=true, you don't need to call 
window.validate().

As to a simple test, please try to create a frame, put a split pane into 
it, and add a heavyweight AWT java.awt.Panel into it instead of a 
PApplet instance. This should work pretty much the same as your real 
app. If you can reproduce the problem with such a simple test, please 
post its source to the mailing list.

--
best regards,
Anthony

On 1/16/2012 8:42 PM, Johannes.Lichtenberger wrote:
> Hello,
> 
> I'm adding a JSplitPane to a JPanel within a frame, and the frame has a
> JMenuBar added. I'm now adding a JPanel component which embeds a PApplet
> component (processing from processing.org) which extends Applet to the
> JSplitPane. It doesn't seem to work even though I've added
> 
>     /**
>      * Handle mix of heavyweight ({@link PApplet}) and leightweight (
> {@link JMenuBar}) components.
>      */
>     public void handleHLWeight() {
>         final Container parent = mView.component().getParent();
>         if (parent instanceof JComponent) {
>             ((JComponent)parent).revalidate();
>         }
>         final Window window = SwingUtilities.getWindowAncestor(this);
>         if (window != null) {
>             window.validate();
>         }
>     }
> 
> to the embedded view which is for instance called within draw(), a
> method which is called frameRate(int)-times per second.
> 
> Without the JSplitPane it seems fine, but now I'm adding another view
> side by side and it doesn't work anymore :(
> 
> Well to recap the setup:
> 
> View extends JPane => is inserted in a JSplitPane.
> View embeds a PApplet instance via (add(Component)).
> JSplitPane is inserted in a JPane and added to the contentPane of a
> JFrame instance together with a JMenuBar instance (via
> setJMenuBar(JMenuBar)).
> 
> I'm using Java7.
> 
> johannes at luna:~/workspace/treetank$ java -version
> java version "1.7.0"
> Java(TM) SE Runtime Environment (build 1.7.0-b147)
> Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode)
> 
> The setup of the JSplitPane is as follows:
> 
>     /**
>      * Setup of the {@link JSplitPane} reference.
>      *
>      * @param paramPane
>      *            {@link JSplitPane} reference
>      * @param paramTmpView
>      *            {@link JComponent} reference to the left
>      * @param paramView
>      *            {@link JComponent} reference to the right
>      */
>     private void
>         setupPane(final JSplitPane paramPane, final JComponent
> paramTmpView, final JComponent paramView) {
>         assert paramPane != null;
>         assert paramTmpView != null;
>         assert paramView != null;
>         paramPane.setSize(new Dimension(mGUI.getWidth(), mGUI.getHeight()));
>         paramPane.setAlignmentX(mGUI.getWidth() / 2f);
>         paramPane.setAlignmentY(mGUI.getHeight() / 2f);
>         paramPane.setDividerLocation(0.5);
>         paramPane.setContinuousLayout(true);
>         paramPane.setLeftComponent(paramTmpView);
>         paramPane.setRightComponent(paramView);
> 
> paramPane.addPropertyChangeListener(JSplitPane.DIVIDER_LOCATION_PROPERTY, new
> Listener(paramPane));
>         final Container parent = paramPane.getParent();
>         if (parent instanceof JComponent) {
>             ((JComponent)parent).revalidate();
>         }
>         final Window window = SwingUtilities.getWindowAncestor(this);
>         if (window != null) {
>             window.validate();
>         }
>     }
> 
> I'm not sure, I thing the final code is useless with revalidate() and so on.
> 
> kind regards,
> Johannes


From anthony.petrov at oracle.com  Tue Jan 17 16:01:02 2012
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 17 Jan 2012 20:01:02 +0400
Subject: <Swing Dev> JSplitPane / heavyweight vs. lightweight components
In-Reply-To: <4F157F71.7090906@uni-konstanz.de>
References: <4F145367.4020907@uni-konstanz.de> <4F157C28.6020800@oracle.com>
	<4F157F71.7090906@uni-konstanz.de>
Message-ID: <4F159B3E.40407@oracle.com>

On 1/17/2012 6:02 PM, Johannes.Lichtenberger wrote:
> On 01/17/2012 02:48 PM, Anthony Petrov wrote:
>> Does running your app with the -Djava.awt.smartInvalidate=true command
>> line argument resolve anything? Please note that you have to execute
>> this workaround revalidation mantra upon any changes performed by the
>> user to the JSplitPane (i.e. on each moving of the split pane divider).
>> Also, when running with the smartInvalidate=true, you don't need to call
>> window.validate().
> 
> Great, that's it "-Djava.awt.smartInvalidate=true" solves the problem,
> thank you :-)

You're welcome!

--
best regards,
Anthony


From chrriis at gmail.com  Tue Jan 17 16:36:36 2012
From: chrriis at gmail.com (Christopher Deckers)
Date: Tue, 17 Jan 2012 17:36:36 +0100
Subject: <Swing Dev> JSplitPane / heavyweight vs. lightweight components
In-Reply-To: <4F159B3E.40407@oracle.com>
References: <4F145367.4020907@uni-konstanz.de> <4F157C28.6020800@oracle.com>
	<4F157F71.7090906@uni-konstanz.de> <4F159B3E.40407@oracle.com>
Message-ID: <CADFnS4RYB41Vm_E6YqWeEq-tKnArYO3qdNzYpn8hwk8Y0z+tNA@mail.gmail.com>

Anthony,

>> Great, that's it "-Djava.awt.smartInvalidate=true" solves the problem,

What was the reasoning of having the smart invalidate algorithm not
being the default?

Cheers,
-Christopher


From anthony.petrov at oracle.com  Tue Jan 17 16:45:30 2012
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 17 Jan 2012 20:45:30 +0400
Subject: <Swing Dev> JSplitPane / heavyweight vs. lightweight components
In-Reply-To: <CADFnS4RYB41Vm_E6YqWeEq-tKnArYO3qdNzYpn8hwk8Y0z+tNA@mail.gmail.com>
References: <4F145367.4020907@uni-konstanz.de>
	<4F157C28.6020800@oracle.com>	<4F157F71.7090906@uni-konstanz.de>
	<4F159B3E.40407@oracle.com>
	<CADFnS4RYB41Vm_E6YqWeEq-tKnArYO3qdNzYpn8hwk8Y0z+tNA@mail.gmail.com>
Message-ID: <4F15A5AA.1000101@oracle.com>

Hi Christopher,

On 1/17/2012 8:36 PM, Christopher Deckers wrote:
>>> Great, that's it "-Djava.awt.smartInvalidate=true" solves the problem,
> 
> What was the reasoning of having the smart invalidate algorithm not
> being the default?

The algorithm caused a number of regressions in Swing that were 
identified too late in the release cycle of JDK 7, and as such it was 
decided to make this functionality optional in order to not delay the 
release of JDK 7.

--
best regards,
Anthony


From chrriis at gmail.com  Tue Jan 17 16:50:57 2012
From: chrriis at gmail.com (Christopher Deckers)
Date: Tue, 17 Jan 2012 17:50:57 +0100
Subject: <Swing Dev> JSplitPane / heavyweight vs. lightweight components
In-Reply-To: <4F15A5AA.1000101@oracle.com>
References: <4F145367.4020907@uni-konstanz.de> <4F157C28.6020800@oracle.com>
	<4F157F71.7090906@uni-konstanz.de> <4F159B3E.40407@oracle.com>
	<CADFnS4RYB41Vm_E6YqWeEq-tKnArYO3qdNzYpn8hwk8Y0z+tNA@mail.gmail.com>
	<4F15A5AA.1000101@oracle.com>
Message-ID: <CADFnS4TaFWcyezX1jtyeuwA1=BQwHuceEKYM6oYzHMKEwXTY4Q@mail.gmail.com>

Anthony,

> The algorithm caused a number of regressions in Swing that were identified
> too late in the release cycle of JDK 7, and as such it was decided to make
> this functionality optional in order to not delay the release of JDK 7.

Thanks for the clarifications.
Does this means there is going to be some work in JDK 8 so that the
smart invalidation becomes the default?

Cheers,
-Christopher


From anthony.petrov at oracle.com  Tue Jan 17 17:00:37 2012
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 17 Jan 2012 21:00:37 +0400
Subject: <Swing Dev> JSplitPane / heavyweight vs. lightweight components
In-Reply-To: <CADFnS4TaFWcyezX1jtyeuwA1=BQwHuceEKYM6oYzHMKEwXTY4Q@mail.gmail.com>
References: <4F145367.4020907@uni-konstanz.de>
	<4F157C28.6020800@oracle.com>	<4F157F71.7090906@uni-konstanz.de>
	<4F159B3E.40407@oracle.com>	<CADFnS4RYB41Vm_E6YqWeEq-tKnArYO3qdNzYpn8hwk8Y0z+tNA@mail.gmail.com>	<4F15A5AA.1000101@oracle.com>
	<CADFnS4TaFWcyezX1jtyeuwA1=BQwHuceEKYM6oYzHMKEwXTY4Q@mail.gmail.com>
Message-ID: <4F15A935.1060409@oracle.com>

On 1/17/2012 8:50 PM, Christopher Deckers wrote:
>> The algorithm caused a number of regressions in Swing that were identified
>> too late in the release cycle of JDK 7, and as such it was decided to make
>> this functionality optional in order to not delay the release of JDK 7.
> 
> Thanks for the clarifications.
> Does this means there is going to be some work in JDK 8 so that the
> smart invalidation becomes the default?

I think Swing folks could elaborate on the current status of the issues.

--
best regards,
Anthony


From Alexander.Potochkin at oracle.com  Tue Jan 17 17:08:06 2012
From: Alexander.Potochkin at oracle.com (Alexander Potochkin)
Date: Tue, 17 Jan 2012 21:08:06 +0400
Subject: <Swing Dev> JSplitPane / heavyweight vs. lightweight components
In-Reply-To: <4F15A935.1060409@oracle.com>
References: <4F145367.4020907@uni-konstanz.de>
	<4F157C28.6020800@oracle.com>	<4F157F71.7090906@uni-konstanz.de>
	<4F159B3E.40407@oracle.com>	<CADFnS4RYB41Vm_E6YqWeEq-tKnArYO3qdNzYpn8hwk8Y0z+tNA@mail.gmail.com>	<4F15A5AA.1000101@oracle.com>
	<CADFnS4TaFWcyezX1jtyeuwA1=BQwHuceEKYM6oYzHMKEwXTY4Q@mail.gmail.com>
	<4F15A935.1060409@oracle.com>
Message-ID: <4F15AAF6.70308@oracle.com>

Hello Christopher

>> Does this means there is going to be some work in JDK 8 so that the
>> smart invalidation becomes the default?
> I think Swing folks could elaborate on the current status of the issues.

I wish we could have turned it on by default,
but it caused regressions in the users' code
so we made it optional to preserve the backward compatibility

Thanks
alexp

>
> -- 
> best regards,
> Anthony



From chrriis at gmail.com  Tue Jan 17 20:47:30 2012
From: chrriis at gmail.com (Christopher Deckers)
Date: Tue, 17 Jan 2012 21:47:30 +0100
Subject: <Swing Dev> JSplitPane / heavyweight vs. lightweight components
In-Reply-To: <4F15AAF6.70308@oracle.com>
References: <4F145367.4020907@uni-konstanz.de> <4F157C28.6020800@oracle.com>
	<4F157F71.7090906@uni-konstanz.de> <4F159B3E.40407@oracle.com>
	<CADFnS4RYB41Vm_E6YqWeEq-tKnArYO3qdNzYpn8hwk8Y0z+tNA@mail.gmail.com>
	<4F15A5AA.1000101@oracle.com>
	<CADFnS4TaFWcyezX1jtyeuwA1=BQwHuceEKYM6oYzHMKEwXTY4Q@mail.gmail.com>
	<4F15A935.1060409@oracle.com> <4F15AAF6.70308@oracle.com>
Message-ID: <CADFnS4R+V=uenc+ifnJoJdpQuXhjhTgN8bRAEx5CaXd5Wy+ViA@mail.gmail.com>

Hi Alex,

>>> Does this means there is going to be some work in JDK 8 so that the
>>> smart invalidation becomes the default?
>
> I wish we could have turned it on by default,
> but it caused regressions in the users' code
> so we made it optional to preserve the backward compatibility

User's code is broken whenever it is not on and native components are
used. It is hard to figure out this property.

When I upgraded our codebase to Java 7  (at work), I had issues at
certain places (empty arrays were returned instead of nulls for
example) but I was happy to fix those places and have the newest Java
and more importantly a more coherent logic of the runtime. Are you
implying that these new behaviors are regressions and should have had
corresponding properties to be active
(-Djava.awt.emptyArraysInsteadOfNull=true)?

Are there so many regressions that it outweighs the benefits of having
smart invalidation by default? Why not have a
"-Djava.awt.dumbInvalidate=true" for those regressions instead?

Note that this topic is of interest for me because I ship a library
that contains native components. I am sure that I will occasionaly
lose time and effort with users before finding out dumb invalidation
was the culprit.

Cheers,
-Christopher


From Alexander.Potochkin at oracle.com  Thu Jan 19 15:00:33 2012
From: Alexander.Potochkin at oracle.com (Alexander Potochkin)
Date: Thu, 19 Jan 2012 19:00:33 +0400
Subject: <Swing Dev> JSplitPane / heavyweight vs. lightweight components
In-Reply-To: <CADFnS4R+V=uenc+ifnJoJdpQuXhjhTgN8bRAEx5CaXd5Wy+ViA@mail.gmail.com>
References: <4F145367.4020907@uni-konstanz.de> <4F157C28.6020800@oracle.com>
	<4F157F71.7090906@uni-konstanz.de> <4F159B3E.40407@oracle.com>
	<CADFnS4RYB41Vm_E6YqWeEq-tKnArYO3qdNzYpn8hwk8Y0z+tNA@mail.gmail.com>
	<4F15A5AA.1000101@oracle.com>
	<CADFnS4TaFWcyezX1jtyeuwA1=BQwHuceEKYM6oYzHMKEwXTY4Q@mail.gmail.com>
	<4F15A935.1060409@oracle.com> <4F15AAF6.70308@oracle.com>
	<CADFnS4R+V=uenc+ifnJoJdpQuXhjhTgN8bRAEx5CaXd5Wy+ViA@mail.gmail.com>
Message-ID: <4F183011.9030609@oracle.com>

Hello Christopher
>> I wish we could have turned it on by default,
>> but it caused regressions in the users' code
>> so we made it optional to preserve the backward compatibility
> User's code is broken whenever it is not on and native components are
> used. It is hard to figure out this property.
>
> When I upgraded our codebase to Java 7  (at work), I had issues at
> certain places (empty arrays were returned instead of nulls for
> example) but I was happy to fix those places and have the newest Java
> and more importantly a more coherent logic of the runtime. Are you
> implying that these new behaviors are regressions and should have had
> corresponding properties to be active
> (-Djava.awt.emptyArraysInsteadOfNull=true)?

I don't think that those problems with arrays are related to Swing/AWT,
we always do our best to preserve backward compatibility

(when we don't, our customers quickly remind us about that)

>
> Are there so many regressions that it outweighs the benefits of having
> smart invalidation by default? Why not have a
> "-Djava.awt.dumbInvalidate=true" for those regressions instead?

There were enough serious regressions that prevented us from enabling 
the new invalidation mechanism.
The existing mode is not "dumb invalidate", it is just the validation 
we've had from the beginning.

>
> Note that this topic is of interest for me because I ship a library
> that contains native components. I am sure that I will occasionaly
> lose time and effort with users before finding out dumb invalidation
> was the culprit.

I pretty understand your feelings and,
by the way, I spent descent amount of time trying to keep the new 
validation
and backward compatibility at the same time, alas it doesn't seem to be 
possible

Thanks
alexp

>
> Cheers,
> -Christopher



From pavel.porvatov at oracle.com  Fri Jan 20 10:53:31 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Fri, 20 Jan 2012 14:53:31 +0400
Subject: <Swing Dev> JFileChooser - Red color.
In-Reply-To: <CAFUf_XM+GmujWxBY10W=bnwzALjt_tWPRoRUu259_AcmLjJp9A@mail.gmail.com>
References: <CAFUf_XM+GmujWxBY10W=bnwzALjt_tWPRoRUu259_AcmLjJp9A@mail.gmail.com>
Message-ID: <4F1947AB.9030204@oracle.com>

Hello,

There is no simple way to do that

Regards, Pavel
> I want to set Brown color to my JFileChooser.
>
> I could not find any method which can set color for JFileChooser.
>
> Please guide me how can I set color to JFileChooser.
>
> Thanks,
> S



From pavel.porvatov at oracle.com  Fri Jan 20 11:37:03 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Fri, 20 Jan 2012 15:37:03 +0400
Subject: <Swing Dev> A proposal for a behavior change about mnemonic key
In-Reply-To: <CAOo=rxVKTitGnAkZPVSU678FLotuiokapMHs2yF-RDzZJ+WWpg@mail.gmail.com>
References: <AANLkTimDaioEK4oLkeqtRBPUCt4yPCZ0r3yHi=waisOg@mail.gmail.com>
	<BANLkTi=yLQgf_c1J6ahVqenC+aHCJWh=kg@mail.gmail.com>
	<CAOo=rxVvLQWxvLFZErt3xFTJokyHtfzetfbN3Rn=4DFPpVgmcA@mail.gmail.com>
	<B56FF905-2911-41DB-935D-A2026AD1D137@gmail.com>
	<CAOo=rxUNj5aCAbDKDo3i6rq-uEet4KdMKwy_iu4nRWdvE+oB6A@mail.gmail.com>
	<4E6E2CC9.5080100@oracle.com>
	<CAOo=rxUiLukv5rZbUG6QpSCorTwiNdCkvS3w3B1OV3WTW3us8w@mail.gmail.com>
	<4E6F290E.9010701@oracle.com>
	<CAOo=rxU1d=vvzDiRk=-PG1_JbtTgUNmE0QF2cuPtEH3bhTNQ+g@mail.gmail.com>
	<4E70C568.6050105@oracle.com>
	<CAOo=rxXGNy9qA5GoJ0y+0Cb6jTxvho1jNPgrp4hTGLHeR+wCUA@mail.gmail.com>
	<4E79F306.3040406@oracle.com>
	<CAOo=rxVZZfCZjKRakzhQ9RxzQPC5bM1gUkDS-j6EORUoj91ybg@mail.gmail.com>
	<4E903584.9030808@oracle.com>
	<CAOo=rxXASaRnoPrgFgQ8daW9jLKdec=Cu_LJOt94ENUgNuNiRg@mail.gmail.com>
	<4ECD33FC.10404@oracle.com>
	<CAOo=rxVKTitGnAkZPVSU678FLotuiokapMHs2yF-RDzZJ+WWpg@mail.gmail.com>
Message-ID: <4F1951DF.4010403@oracle.com>

Hi Sean,
> Hi Pavel,
>
> About the LAF, I didn't quite get you. Do you mean we should ask users 
> to press "esc" before next mnemonic key event takes effect when using 
> gtk LAF?
> Or, do you mean we should implement the focus transfer code in each LAF?
>
> Previously, I thought this patch is just a small enhancement to 
> current implementation and the enhancement benefits all LAFs.
I meant that native look and feels (like Windows and GTK LAFs) should 
have behavior of native system. As I wrote there are a couple 
differences between these LAFs:
----------------
1. When Alt+i is pressed several times:
In Windows focus moves between items
In Ubuntu focus stays at the initially selected item

2. When sequence Alt+i and Escape pressed several times
In Windows the first menu item is selected
In Ubuntu after every sequence the next item is selected
----------------

As I understand your current implementation correspondent to WindowsLAF, 
right? We can add the new functionality in cross platform look and feel, 
so we could use your patch for Metal and Nimbus as well. But Motif and 
GTK should use different strategy. I'd suggest to use your new behavior 
only for Windows, Nimbus and Metal, but doesn't touch Motif and GTK .

Regards, Pavel
>
>
> On Thu, Nov 24, 2011 at 1:57 AM, Pavel Porvatov 
> <pavel.porvatov at oracle.com <mailto:pavel.porvatov at oracle.com>> wrote:
>
>     Hi Sean,
>
>     We still doesn't have consensus about native LAF behavior. As
>     noticed Mario "I believe that native look and feel should mandate
>     the different  keybindings". I agree with him and I'd like to not
>     extend the new behavior on all LAFs.
>
>     I also glanced at the fix and have one comment: you should use
>     getModifiersEx method instead of getModifiers (see javadoc for the
>     InputEvent#ALT_MASK field for details)
>
>     Regards, Pavel
>
>>     Hi all,
>>
>>         I modified the patch and added the testcase, please see
>>     attachment.
>>
>>         However, the testcase works on windows, but does not work
>>     right on linux. That's
>>     the reason for the Manualbug7108342.java file. When I test it
>>     manually, it works. And
>>     because of this problem, I haven't tested it with jtreg.
>>
>>         Following is the scenario of testcase:
>>         The test has three buttons with Mnemonic key "b", at start
>>     up, focus is on button1,
>>     when alt+b is pressed, focus goes to button3, and if pressed
>>     again, it goes to button2,
>>     and then button1, etc.
>>
>>         When the testcase runs on linux, only button3 and button1 get
>>     focused, and there
>>     are 18 focus events recorded instead of 9. I'm not sure what's
>>     the problem with it.
>>     When I press alt+b manually(using Manualbug7108342.java), it
>>     works well.
>>
>>         Does anyone have some comments about the patch or the testcase ?
>>
>>     On Sat, Oct 8, 2011 at 7:35 PM, Pavel Porvatov
>>     <pavel.porvatov at oracle.com <mailto:pavel.porvatov at oracle.com>> wrote:
>>
>>         Hi Sean,
>>>         Hi Pavel,
>>>
>>>            Your observation is right, but I can't agree with the
>>>         conclusion. Windows and
>>>         GTK behave differently about how to close an opened menu.
>>>         Under GTK, press
>>>         "alt" can not close an opened menu, so, the "esc" is used to
>>>         close it; while
>>>         windows performs more friendly, when mnemonic key is pressed
>>>         again, the first
>>>         opened menu is closed automatically. This is totally about
>>>         how to close an
>>>         opened menu, and it doesn't change the fact that menus with
>>>         same mnemonic
>>>         key are iterated.
>>>
>>>            On the other side, swing implementation doesn't follow
>>>         GTK's behavior about
>>>         how to close the menu at all. Open the swingset2 and you can
>>>         find its behavior
>>>         is the same with windows. Press "alt+f" and then press
>>>         "alt+l" will open the
>>>         "look and feel" menu instead of GTK's "alt+f", "esc", and
>>>         "alt+l".
>>>
>>>            So, I think GTK's behavior about "use esc to close an
>>>         opened menu" is not
>>>         user friendly and we can ignore it, while GTK's "iterate
>>>         over menus with same
>>>         mnemonic key" is better than current java implementation and
>>>         we can add
>>>         this feature. And if a user wants to use GTK's key sequence
>>>         "alt+f", "esc",
>>>         "alt+l", it is also functional.
>>>
>>>            So I think this enhancement will help keep the behavior
>>>         same with both these
>>>         platforms, how do you think?
>>         Sounds reasonable and I don't object now to the decision.
>>         Does anybody have ideas (e.g. objections) about the new
>>         functionality?
>>
>>         I glanced at your patch and have the following comments:
>>         1. Could you please file CR about the problem
>>         2. A test is needed (I think it's possible to write an
>>         automatic one)
>>         3. Could you please correct the new code to obey our code
>>         standards (aligning, spacing, mandatory braces in if/else
>>         conditions and others)
>>
>>         If possible send patch as a webrev, please.
>>
>>         Thanks, Pavel
>>
>>
>>>
>>>         2011/9/21 Pavel Porvatov <pavel.porvatov at oracle.com
>>>         <mailto:pavel.porvatov at oracle.com>>
>>>
>>>             Hi Sean,
>>>
>>>             I found out that Windows and GTK works in different ways
>>>             (I used your apps):
>>>
>>>             1. When Alt+i is pressed several times:
>>>             In Windows focus moves between items
>>>             In Ubuntu focus stays at the initially selected item
>>>
>>>             2. When sequence Alt+i and Escape pressed several times
>>>             In Windows the first menu item is selected
>>>             In Ubuntu after every sequence the next item is selected
>>>
>>>             In such case we should use different strategies for
>>>             different platforms...
>>>
>>>
>>>             Regards, Pavel
>>>
>>>>             Hi Pavel,
>>>>
>>>>                 I just tested linux gtk platform.  With gtk2+,
>>>>             ubuntu linux with kernel 2.6.38, xfce, x86_32.
>>>>             I set four menus with mnemonic "i". Press "alt+i" will
>>>>             travel through four menus. The difference
>>>>             is that each menu must be closed with "esc" before
>>>>             "alt+i" opens the next one.
>>>>
>>>>                 So press "alt+i" opens "File", and press "esc" to
>>>>             close it;
>>>>                 then press "alt+i" opens "Edit", and press "esc" to
>>>>             close it;
>>>>                 ... for next menu with mnemonic "i"
>>>>
>>>>             I attached the test application and its ui file. If it
>>>>             is blocked, please use
>>>>             this link:
>>>>             https://docs.google.com/leaf?id=0B8kRxsymP7imOGU1NjhiM2ItMGQ5Ni00NWNhLWJmMDQtZjZiZmQzN2U4ZGUw&hl=en_US
>>>>             <https://docs.google.com/leaf?id=0B8kRxsymP7imOGU1NjhiM2ItMGQ5Ni00NWNhLWJmMDQtZjZiZmQzN2U4ZGUw&hl=en_US>
>>>>
>>>>             Ubuntu x86_32 should work.
>>>>
>>>>
>>>>             So, I think both windows and linux gtk have supported
>>>>             traversal of same mnemonic keyed
>>>>             items already.
>>>>
>>>>
>>>>             2011/9/14 Pavel Porvatov <pavel.porvatov at oracle.com
>>>>             <mailto:pavel.porvatov at oracle.com>>
>>>>
>>>>                 Hi Sean,
>>>>>                 Hi Pavel,
>>>>>
>>>>>                     Let's see if this time works. The attachement
>>>>>                 just contains the exe file written by C#, the
>>>>>                 application is very simple, I just drag a menu to
>>>>>                 the default WinForm in VS2003.
>>>>>                     Please change the extension from exe1 to exe
>>>>>                 after unzip as gmail doesn't allow exe file to be
>>>>>                 sent.
>>>>                 Yes, I see. And what about other platforms/lafs?
>>>>                 Your patch affects behavior of all lafs. So we must
>>>>                 be sure, that such behavior is correct for every
>>>>                 supported platform...
>>>>
>>>>                 Regards, Pavel
>>>>
>>>>>
>>>>>                 2011/9/13 Pavel Porvatov
>>>>>                 <pavel.porvatov at oracle.com
>>>>>                 <mailto:pavel.porvatov at oracle.com>>
>>>>>
>>>>>                     Hi Sean,
>>>>>
>>>>>                     I think the attached sample was removed
>>>>>                     because I didn't get any attachments...
>>>>>
>>>>>                     Regards, Pavel
>>>>>
>>>>>>                     Hi Pavel,
>>>>>>
>>>>>>                        I found C# Form application treats
>>>>>>                     Mnemonics in menu in this way. I attached the
>>>>>>                     sample
>>>>>>                     application. Press alt+i will iterate over
>>>>>>                     three menu.
>>>>>>
>>>>>>                     2011/9/13 Pavel Porvatov
>>>>>>                     <pavel.porvatov at oracle.com
>>>>>>                     <mailto:pavel.porvatov at oracle.com>>
>>>>>>
>>>>>>                         Hi Sean,
>>>>>>>                         Hi,
>>>>>>>
>>>>>>>                            Thanks.
>>>>>>>
>>>>>>>                            So is there any one can give me a
>>>>>>>                         suggestion about what shall I
>>>>>>>                         do if we want these feature ?  Thanks again.
>>>>>>                         First of all you should file a bug (RFE
>>>>>>                         actually). BTW: before reviewing the fix
>>>>>>                         I'd like to ask about OS behavior when
>>>>>>                         there are several components with the
>>>>>>                         same mnemonic. How Windows XP/Vista/7 and
>>>>>>                         Linux (Gnome/KDE) manage the described
>>>>>>                         situation?
>>>>>>
>>>>>>                         Regards, Pavel
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>                         2011/7/6 Jean-Remi Desjardins
>>>>>>>                         <jeanremi.desjardins at gmail.com
>>>>>>>                         <mailto:jeanremi.desjardins at gmail.com>>
>>>>>>>
>>>>>>>                             I think that sounds like a great idea!
>>>>>>>
>>>>>>>                             Regards,
>>>>>>>                             Jean-R?mi Desjardins
>>>>>>>
>>>>>>>                             Sent from my iPhone (so don't expect
>>>>>>>                             me to be too verbose)
>>>>>>>
>>>>>>>                             On 2011-07-06, at 5:42 AM, Sean Chou
>>>>>>>                             <zhouyx at linux.vnet.ibm.com
>>>>>>>                             <mailto:zhouyx at linux.vnet.ibm.com>>
>>>>>>>                             wrote:
>>>>>>>
>>>>>>>>                             Hi,
>>>>>>>>
>>>>>>>>                                Is there anybody interested in
>>>>>>>>                             this feature? Or any other comments?
>>>>>>>>
>>>>>>>>                             2011/4/21 Sean Chou
>>>>>>>>                             <zhouyx at linux.vnet.ibm.com
>>>>>>>>                             <mailto:zhouyx at linux.vnet.ibm.com>>
>>>>>>>>
>>>>>>>>                                 Hi,
>>>>>>>>
>>>>>>>>                                    I have a simple patch to
>>>>>>>>                                 demo the new behavior. With the
>>>>>>>>                                 patch, the focus will go
>>>>>>>>                                 through the radiobuttons with
>>>>>>>>                                 mnemonic key Y when alt+y is
>>>>>>>>                                 pressed instead of select the last.
>>>>>>>>
>>>>>>>>
>>>>>>>>                                 The patch is as follows:
>>>>>>>>
>>>>>>>>                                 diff -r 554adcfb615e src/share/classes/javax/swing/KeyboardManager.java
>>>>>>>>                                 --- a/src/share/classes/javax/swing/KeyboardManager.java	Wed Mar 16 15:01:07 2011 -0700
>>>>>>>>                                 +++ b/src/share/classes/javax/swing/KeyboardManager.java	Thu Mar 17 14:57:14 2011 +0800
>>>>>>>>                                 @@ -251,6 +251,93 @@
>>>>>>>>                                                    }
>>>>>>>>                                                } else if ( tmp instanceof Vector) { //more than one comp registered for this
>>>>>>>>                                                    Vector v = (Vector)tmp;
>>>>>>>>                                 +
>>>>>>>>                                 +                 /* The below code is added to make sure the focus is not always
>>>>>>>>                                 +                    transferred to the last component in the vector when
>>>>>>>>                                 +                    more than one component have the same mnemonic
>>>>>>>>                                 +                 */
>>>>>>>>                                 +	              if ((e.getModifiers()&  Event.ALT_MASK) == Event.ALT_MASK) {
>>>>>>>>                                 +                      /* Mnemonic key should transfer the focus only, do not select.
>>>>>>>>                                 +                       * The following code works in this way:
>>>>>>>>                                 +                       * 1. If only one component in the vector is visible, fireBinding on it.
>>>>>>>>                                 +                       * 2. If multi-components in the vector are visible, move the focus to next component.
>>>>>>>>                                 +                       *    2.1 If the next component is not a JAbstractButton, fireBinding on it.
>>>>>>>>                                 +                       *    2.2 If the next component is a JMenu, which is a JAbstractButton, fireBinding
>>>>>>>>                                 +                       *        on it to open the menu.
>>>>>>>>                                 +                       *    2.3 If the next component is another JAbstractButton like JRadioButton. Request
>>>>>>>>                                 +                       *        focus on it instead of fireBinding. To AVOID SELECTION&  CLICK of the button.
>>>>>>>>                                 +                       * 3. If the code is triggered by release event, fireBinding on current focus component
>>>>>>>>                                 +                       *    instead of move focus.
>>>>>>>>                                 +                       * 4. Further consideration: there may be more swing control like JMenu, or customized
>>>>>>>>                                 +                       *    controls, which may break this behavior.
>>>>>>>>                                 +                       */
>>>>>>>>                                 +                      // This has alt as it's modifier so this could be a mnemonic
>>>>>>>>                                 +                      Component focusOwner = KeyboardFocusManager.getCurrentKeyboardFocusManager().getFocusOwner();
>>>>>>>>                                 +                      {
>>>>>>>>                                 +                      // If only one visible component, invoke it.
>>>>>>>>                                 +                      int visibleComponentCounter = 0;
>>>>>>>>                                 +                      int nextFocus = 0;
>>>>>>>>                                 +                      for (int i =  0; i<  v.size(); i++){
>>>>>>>>                                 +                          JComponent c = (JComponent) v.elementAt(i);
>>>>>>>>                                 +                          if (c.isShowing()&&  c.isEnabled()){
>>>>>>>>                                 +                    	         visibleComponentCounter++ ;
>>>>>>>>                                 +                    		      nextFocus = i;
>>>>>>>>                                 +                    	     }
>>>>>>>>                                 +                      }
>>>>>>>>                                 +                      if (visibleComponentCounter == 1){
>>>>>>>>                                 +                    	     JComponent tmpc = (JComponent) v.elementAt(nextFocus);
>>>>>>>>                                 +                    	     fireBinding(tmpc, ks, e, pressed);
>>>>>>>>                                 +                          if (e.isConsumed())
>>>>>>>>                                 +                        	  return true;
>>>>>>>>                                 +                      }
>>>>>>>>                                 +                      // If multi-components are visible, do not select the button, just move the focus.
>>>>>>>>                                 +                      for (int counter = v.size() - 1; counter>= 0; counter--) {
>>>>>>>>                                 +                          JComponent c = (JComponent) v.elementAt(counter);
>>>>>>>>                                 +                          if (c.isShowing()&&  c.isEnabled()) {
>>>>>>>>                                 +                              if ((c == focusOwner)
>>>>>>>>                                 +                                       || (c instanceof JLabel&&  ((JLabel) c).getLabelFor() == focusOwner)) {
>>>>>>>>                                 +                                  if (e.getID() == KeyEvent.KEY_RELEASED){
>>>>>>>>                                 +                                	     nextFocus = counter;
>>>>>>>>                                 +                                	     break;
>>>>>>>>                                 +                                  }
>>>>>>>>                                 +                            	    nextFocus = (counter - 1 + v.size()) % v.size();
>>>>>>>>                                 +                                  break;
>>>>>>>>                                 +                              }
>>>>>>>>                                 +                          }
>>>>>>>>                                 +                      }
>>>>>>>>                                 +                      for (; nextFocus>= 0; nextFocus--) {
>>>>>>>>                                 +                          JComponent c = (JComponent) v.elementAt(nextFocus);
>>>>>>>>                                 +                          if (c.isShowing()&&  c.isEnabled()) {
>>>>>>>>                                 +                              break;
>>>>>>>>                                 +                          }
>>>>>>>>                                 +                      }
>>>>>>>>                                 +                      if (nextFocus>= 0) {
>>>>>>>>                                 +                          JComponent tmpc = (JComponent) v.elementAt(nextFocus);
>>>>>>>>                                 +                          // Next is the hack for this accessibility:
>>>>>>>>                                 +                          // For general Buttons, do not press them, but request focus only.
>>>>>>>>                                 +                          // For special buttons like JMenu, needs press.
>>>>>>>>                                 +                          // If it is not a button, let the component handles by itself.
>>>>>>>>                                 +                          if (!(tmpc instanceof javax.swing.AbstractButton)){
>>>>>>>>                                 +                        	   fireBinding(tmpc, ks, e, pressed);
>>>>>>>>                                 +                              if (e.isConsumed())
>>>>>>>>                                 +                            	    return true;
>>>>>>>>                                 +                          }
>>>>>>>>                                 +                          if (tmpc instanceof JMenu ) {
>>>>>>>>                                 +                              fireBinding(tmpc, ks, e, pressed);
>>>>>>>>                                 +                              tmpc.requestFocusInWindow();
>>>>>>>>                                 +                              if (e.isConsumed())
>>>>>>>>                                 +                                  return true;
>>>>>>>>                                 +                          } else {
>>>>>>>>                                 +                              boolean result = tmpc.requestFocusInWindow();
>>>>>>>>                                 +                              e.consume();
>>>>>>>>                                 +                              return result;
>>>>>>>>                                 +                          }
>>>>>>>>                                 +                      }
>>>>>>>>                                 +                      // If it is not handled here, default behavior is selecting the last.
>>>>>>>>                                 +                      }
>>>>>>>>                                 +                 }
>>>>>>>>                                 +
>>>>>>>>                                 +
>>>>>>>>                                                    // There is no well defined order for WHEN_IN_FOCUSED_WINDOW
>>>>>>>>                                                    // bindings, but we give precedence to those bindings just
>>>>>>>>                                                    // added. This is done so that JMenus WHEN_IN_FOCUSED_WINDOW
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                                 2011/4/1 Sean Chou
>>>>>>>>                                 <zhouyx at linux.vnet.ibm.com
>>>>>>>>                                 <mailto:zhouyx at linux.vnet.ibm.com>>
>>>>>>>>
>>>>>>>>                                     Hi all,
>>>>>>>>
>>>>>>>>                                        In daily use, we may
>>>>>>>>                                     encounter a problem of
>>>>>>>>                                     mnemonic key: there may be
>>>>>>>>                                     several
>>>>>>>>                                     controls want the same key
>>>>>>>>                                     to be set as mnemonic key.
>>>>>>>>                                     It is not common but it
>>>>>>>>                                     does exist.
>>>>>>>>
>>>>>>>>                                        Current openjdk
>>>>>>>>                                     implementation allows users
>>>>>>>>                                     to set a same mnemonic key for
>>>>>>>>                                     different controls; but
>>>>>>>>                                     during the execution, when
>>>>>>>>                                     the mnemonic key is pressed,
>>>>>>>>                                     the last control always
>>>>>>>>                                     gets the action. Users are
>>>>>>>>                                     not able to touch other
>>>>>>>>                                     controls with
>>>>>>>>                                     that mnemonic key. This may
>>>>>>>>                                     confuse them.
>>>>>>>>
>>>>>>>>                                        If all the controls with
>>>>>>>>                                     the same mnemonic key can
>>>>>>>>                                     be accessed through, for
>>>>>>>>                                     example, when the mnemonic
>>>>>>>>                                     key is pressed, the focus
>>>>>>>>                                     is moved to the last control,
>>>>>>>>                                     and when the mnemonic key
>>>>>>>>                                     is pressed again, the focus
>>>>>>>>                                     is moved to the second control
>>>>>>>>                                     with that mnemonic, it will
>>>>>>>>                                     give user the choice to
>>>>>>>>                                     select other controls.
>>>>>>>>
>>>>>>>>                                        Here is an example for
>>>>>>>>                                     the case:
>>>>>>>>
>>>>>>>>                                     package test;
>>>>>>>>
>>>>>>>>                                     import java.awt.BorderLayout;
>>>>>>>>                                     import java.awt.Container;
>>>>>>>>                                     import javax.swing.ButtonGroup;
>>>>>>>>                                     import javax.swing.JFrame;
>>>>>>>>                                     import
>>>>>>>>                                     javax.swing.JRadioButton;
>>>>>>>>
>>>>>>>>                                     public class TestFocus
>>>>>>>>                                     extends JFrame {
>>>>>>>>                                     public TestFocus() {
>>>>>>>>                                     Container pane =
>>>>>>>>                                     getContentPane();
>>>>>>>>                                     pane.setLayout(new
>>>>>>>>                                     BorderLayout());
>>>>>>>>                                     JRadioButton btn1,btn2,btn3;
>>>>>>>>                                     btn1 = new JRadioButton("Yes");
>>>>>>>>                                     btn1.setMnemonic('Y');
>>>>>>>>                                     btn2 = new JRadioButton("Yup");
>>>>>>>>                                     btn2.setMnemonic('Y');
>>>>>>>>                                     btn3 = new JRadioButton("No");
>>>>>>>>                                     btn3.setMnemonic('N');
>>>>>>>>                                     btn3.setSelected(true);
>>>>>>>>                                     ButtonGroup group = new
>>>>>>>>                                     ButtonGroup();
>>>>>>>>                                     group.add(btn1);
>>>>>>>>                                     group.add(btn2);
>>>>>>>>                                     group.add(btn3);
>>>>>>>>                                     pane.add(btn1,BorderLayout.NORTH);
>>>>>>>>                                     pane.add(btn2,BorderLayout.CENTER);
>>>>>>>>                                     pane.add(btn3,BorderLayout.SOUTH);
>>>>>>>>                                     setSize(200,200);
>>>>>>>>                                     setVisible(true);
>>>>>>>>                                     setDefaultCloseOperation(EXIT_ON_CLOSE);
>>>>>>>>                                     }
>>>>>>>>                                     public static void
>>>>>>>>                                     main(String[] args) {
>>>>>>>>                                     new TestFocus();
>>>>>>>>                                     }
>>>>>>>>                                     }
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                                     -- 
>>>>>>>>                                     Best Regards,
>>>>>>>>                                     Sean Chou
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                                 -- 
>>>>>>>>                                 Best Regards,
>>>>>>>>                                 Sean Chou
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                             -- 
>>>>>>>>                             Best Regards,
>>>>>>>>                             Sean Chou
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                         -- 
>>>>>>>                         Best Regards,
>>>>>>>                         Sean Chou
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>                     -- 
>>>>>>                     Best Regards,
>>>>>>                     Sean Chou
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                 -- 
>>>>>                 Best Regards,
>>>>>                 Sean Chou
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>             -- 
>>>>             Best Regards,
>>>>             Sean Chou
>>>>
>>>
>>>
>>>
>>>
>>>         -- 
>>>         Best Regards,
>>>         Sean Chou
>>>
>>
>>
>>
>>
>>     -- 
>>     Best Regards,
>>     Sean Chou
>>
>
>
>
>
> -- 
> Best Regards,
> Sean Chou
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120120/2ac5c9c0/attachment.html>

From pavel.porvatov at oracle.com  Tue Jan 24 10:59:45 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Tue, 24 Jan 2012 14:59:45 +0400
Subject: <Swing Dev> Translating JFileChooser as per the logged in
	language
In-Reply-To: <1323858338.39527.YahooMailNeo@web94713.mail.in2.yahoo.com>
References: <1323858338.39527.YahooMailNeo@web94713.mail.in2.yahoo.com>
Message-ID: <4F1E8F21.6020601@oracle.com>

Hi Radhika,

You should put localized resources into UIManager. For example, to 
localize open button use something like the following:
UIManager.put("FileChooser.openButtonText", "Some text for the Open button")

There are lot of examples in the Internet, e.g. take a look here:
http://stackoverflow.com/questions/3671868/how-can-i-add-localization-to-jfilechooser-for-a-locale-that-is-not-supported-by

Regards, Pavel
> Hello All,
> We are developing an application in which the user can login in 
> different languages.
> We are using JFileChooser in the application. I find that the 
> JFileChooser is displayed in the language of the locale than the 
> logged in language.
> Is there a way to change the UI properties of JFileChooser as per the 
> logged in language even though the locale is same?
> Please let me know.
> Thanks in advance.
> Regards,
> Radhika

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120124/6afc34a0/attachment.html>

From pavel.porvatov at oracle.com  Tue Jan 24 11:34:21 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Tue, 24 Jan 2012 15:34:21 +0400
Subject: <Swing Dev> How to add start and end time values
In-Reply-To: <CAK94idv-Nm4QbEE1_ePRAU09j=-WA2Qmr4V_cdUwcRLXCNqGqQ@mail.gmail.com>
References: <CAK94idv-Nm4QbEE1_ePRAU09j=-WA2Qmr4V_cdUwcRLXCNqGqQ@mail.gmail.com>
Message-ID: <4F1E973D.2000704@oracle.com>

Hi Sanjaya,

You should use something like this:

                 SpinnerDateModel model = new SpinnerDateModel(new 
Date(), null, null, Calendar.HOUR_OF_DAY);
                 JSpinner spinner = new JSpinner(model);
                 JSpinner.DateEditor editor = new 
JSpinner.DateEditor(spinner, "hh:mm");
                 spinner.setEditor(editor);

To set range you can use SpinnerDateModel#setStart/setEnd methods.

Regards, Pavel
> Hi all,
>     I want to keep two spinners in my UI which displays only the
> time.(example 13:30) not the time with date.I also want to make the
> 1st spinner available for selecting any time value between 00:00 to
> 23:59.But I want to restrict the spinner 2 in such a way that only
> time values after the selected value of first time spinner will be
> allowed to select.
> As example if I select 14:00 in spinner1 then I want to select the
> time of spinner2 which is after 14:00 before 23:59.How can I restrict
> spinner2.What kind of spinner should I use?
> Any help please
> Thank you
> Sanjaya



From pavel.porvatov at oracle.com  Mon Jan 30 12:42:59 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Mon, 30 Jan 2012 16:42:59 +0400
Subject: <Swing Dev> How to add start and end time values
In-Reply-To: <CAK94idvd5q29DEKqFBD9oEc+tVAmE9RwMsre6yjMg8VGyfzMrQ@mail.gmail.com>
References: <CAK94idv-Nm4QbEE1_ePRAU09j=-WA2Qmr4V_cdUwcRLXCNqGqQ@mail.gmail.com>
	<4F1E973D.2000704@oracle.com>
	<CAK94idvd5q29DEKqFBD9oEc+tVAmE9RwMsre6yjMg8VGyfzMrQ@mail.gmail.com>
Message-ID: <4F269053.7010602@oracle.com>

Hi Sanjaya,

The setStart method works fine for Date. Try the following example:

         SwingUtilities.invokeLater(new Runnable() {
             @Override
             public void run() {
                 JFrame frame = new JFrame();

                 Calendar calendar = Calendar.getInstance();

                 calendar.setTimeInMillis(0);
                 calendar.set(Calendar.HOUR_OF_DAY, 2);

                 SpinnerDateModel model = new SpinnerDateModel(new Date(),
                         calendar.getTime(), null,
                         Calendar.HOUR_OF_DAY);
                 JSpinner spinner = new JSpinner(model);
                 JSpinner.DateEditor editor = new 
JSpinner.DateEditor(spinner, "HH:mm");
                 spinner.setEditor(editor);

                 frame.add(spinner, BorderLayout.NORTH);
                 frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
                 frame.setSize(400, 300);
                 frame.setVisible(true);
             }
         });

Regards, Pavel
> Hi Pavel,
>      Thank you for the reply.But It doesn't support when I am trying to
> set the start time.model.setStart(Comparable comparable) doesn't
> support for a time.But for Date.Can you explain me bit using an
> example?
>
> Thank you very much
> Regards
> Sanjaya
>
> On Tue, Jan 24, 2012 at 5:04 PM, Pavel Porvatov
> <pavel.porvatov at oracle.com>  wrote:
>> Hi Sanjaya,
>>
>> You should use something like this:
>>
>>                 SpinnerDateModel model = new SpinnerDateModel(new Date(),
>> null, null, Calendar.HOUR_OF_DAY);
>>                 JSpinner spinner = new JSpinner(model);
>>                 JSpinner.DateEditor editor = new JSpinner.DateEditor(spinner,
>> "hh:mm");
>>                 spinner.setEditor(editor);
>>
>> To set range you can use SpinnerDateModel#setStart/setEnd methods.
>>
>> Regards, Pavel
>>> Hi all,
>>>     I want to keep two spinners in my UI which displays only the
>>> time.(example 13:30) not the time with date.I also want to make the
>>> 1st spinner available for selecting any time value between 00:00 to
>>> 23:59.But I want to restrict the spinner 2 in such a way that only
>>> time values after the selected value of first time spinner will be
>>> allowed to select.
>>> As example if I select 14:00 in spinner1 then I want to select the
>>> time of spinner2 which is after 14:00 before 23:59.How can I restrict
>>> spinner2.What kind of spinner should I use?
>>> Any help please
>>> Thank you
>>> Sanjaya
>>