On Fri, 6 Oct 2023 05:10:18 GMT, Tejesh R <[email protected]> wrote:
> Invoking `setEnabled(false)` on an instance of `JFileChooser` the
> sub-components are unaffected since the sub-components didn't set/unset
> enabled explicitly. The fix address the issue and sets the Enabled flag to
> each sub-components. Along with setting the property to each sub components,
> the action listeners like mouseClick(Double too) and scroll actions has to be
> processed based on enabled/disabled property similar to other components.
> Since `JFilechooser` implementation varies based on LookAndFeel, the same had
> to be taken care for affected LookAndFeel also.
> Note: `JFrame` being top level container handles frame disable using native
> method which couldn't be the case for `JFileChooser`. For
> `showDialog/showOpenDialog/showSaveDialog` the fix could be to set the one
> the enabled property for created single Dialog. But when an instance of
> `JFileChooser` is created and added to Frame (Without Dialog been created),
> disabling the `FileChooser` alone had to be done by handling each
> sub-components and listeners separately.
src/java.desktop/share/classes/javax/swing/JFileChooser.java line 2082:
> 2080: }
> 2081:
> 2082: @Override
No javadoc .. are you hoping to get away without a CSR ?
I think a CSR would be a good idea anyway because after 25 years of Swing
ignoring this
on a JFileChooser, you are going to support it. And if an app had set it and
not realised then
it'll see a change.
So I'm not going to suggest javadoc but I am going to suggest a PR for
compatibility concerns.
Then there's always the option to back it out if there's an issue.
src/java.desktop/share/classes/sun/swing/FilePane.java line 1957:
> 1955: JComponent source = (JComponent)evt.getSource();
> 1956:
> 1957: if(!source.isEnabled()) {
if (
src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java
line 374:
> 372: viewMenuButton.addMouseListener(new MouseAdapter() {
> 373: public void mousePressed(MouseEvent e) {
> 374: if(!getFileChooser().isEnabled()) {
if (
And since you aren't explicit about it, can you say what is the user experience
of the native filechooser widget that's used .. isn't it still active ? Can you
really disable it by ignoring these events ?
src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java
line 387:
> 385: viewMenuButton.addKeyListener(new KeyAdapter() {
> 386: public void keyPressed(KeyEvent e) {
> 387: if(!getFileChooser().isEnabled()) {
if (
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/16068#discussion_r1353260593
PR Review Comment: https://git.openjdk.org/jdk/pull/16068#discussion_r1353257064
PR Review Comment: https://git.openjdk.org/jdk/pull/16068#discussion_r1353257162
PR Review Comment: https://git.openjdk.org/jdk/pull/16068#discussion_r1353257332
