Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New JInternalFrame does not have keyboard focus #90

Closed
Sciss opened this issue Feb 22, 2014 · 7 comments
Closed

New JInternalFrame does not have keyboard focus #90

Sciss opened this issue Feb 22, 2014 · 7 comments
Assignees

Comments

@Sciss
Copy link
Contributor

Sciss commented Feb 22, 2014

When using internal frames and I open a new JInternalFrame, that new frame is visibly shown to have the focus (has the blue outline), but the keyboard focus is still in the previous component (e.g. the internal frame which had focus before). Only after a component in the new internal frame requests focus, the keyboard focus is actually transferred.

@mgarin mgarin added the bug label Feb 24, 2014
@mgarin mgarin added this to the Small issues milestone Feb 24, 2014
@mgarin mgarin self-assigned this Feb 24, 2014
@mgarin
Copy link
Owner

mgarin commented Feb 24, 2014

Can you show a small example?
To be exact - can you show how you open new JInternalFrame?

And one more question - you are testing on Open JDK 7, right? There are many Swing issues on Open JDK as i know, so some components might behave incorrectly and should be modified to work properly.

@Sciss
Copy link
Contributor Author

Sciss commented Feb 24, 2014

I tried to create a small example, but it doesn't exhibit this particular behaviour. So I'll have to dig deeper...

@mgarin
Copy link
Owner

mgarin commented Feb 24, 2014

That is why i asked for a small example :)
I didn't notice such behavior anywhere in my apps so far.

It is possible that something pulls focus back when new frame is opened.

@mgarin
Copy link
Owner

mgarin commented Mar 11, 2014

Any news?
Did you find the cause of this issue?

@Sciss
Copy link
Contributor Author

Sciss commented Mar 11, 2014

Ok, so I think the issue is when the minimize etc. flags are activated, then when a new JInternalFrame is opened, the minimize button has initial focus. Below is an example that shows this behaviour. When the second frame is opened, pressing space bar activates the minimize button. At least here I have a visual feedback, in my original setup the button didn't get "depressed", so it was more unclear what happened.

I am not sure that minimize/maximize should actually be focusable or participate in the keyboard focus cycle. In any case, there is no indication that these widgets do have the focus (no focus ring or such is painted).

I think that even if you stick to these widgets being focusable, they should not have initial focus in the new window (which seems to be the case).

Best, .h.h.

(This is Scala code but it translates 1:1 to Java)

    package testing

    import javax.swing.{JPanel, JMenuItem, JMenu, JMenuBar, JDesktopPane, JLabel, AbstractAction, JButton, JInternalFrame, JFrame, UIManager}
    import com.alee.laf.WebLookAndFeel
    import java.awt.{BorderLayout, GraphicsEnvironment, EventQueue}
    import java.awt.event.ActionEvent

    object KeyboardTest extends App with Runnable {
      EventQueue.invokeLater(this)

      def run(): Unit = {
        WebLookAndFeel.install()

        val f = new JFrame()
        f.setBounds(GraphicsEnvironment.getLocalGraphicsEnvironment.getMaximumWindowBounds)
        val desk = new JDesktopPane
        f.setContentPane(desk)
        f.setVisible(true)

        val if1 = new JInternalFrame(null, true, true, true, true)
        val but = new JButton(new AbstractAction("Foo") {
          def actionPerformed(e: ActionEvent): Unit = {
            println("Aqui")
            val if2 = new JInternalFrame(null, true, true, true, true)
            desk.add(if2)

            val p = new JPanel {
              add(new JLabel ("Baz"), BorderLayout.NORTH)
              add(new JButton("Baz"), BorderLayout.SOUTH)
            }

            if2.getContentPane.add(p)
            if2.pack()
            if2.setLocation(200, 300)

            if2.setVisible(true)
            if2.toFront()
          }
        })
        desk.add(if1)

        if1.getContentPane.add(but)
        if1.pack()
        if1.setVisible(true)
        if1.toFront()
      }
    }

@mgarin
Copy link
Owner

mgarin commented Mar 11, 2014

Indeed, it seems that focusable buttons cause this issue.
I will simply make them non-focusable with the next update and the issue should be fixed.

mgarin added a commit that referenced this issue Apr 1, 2014
…ange options

#105 - WebButton decoration is now handled a bit differently when it is inside WebButtonGroup
#72 #79 #104 - Fixed window transparency update method for later versions of JDK 7
#96 - WebButtonGroup "add" methods fix and proper style updates for various cases
#95 - WebScrollPane method to hide scroll bar buttons added
#93 - WebPopupPainter bottom side corner fix
#91 - Small code refactoring
#90 - WebInternalFrame buttons made non-focusable
#55 - "OptionPane.isYesLast" is now set to true for Mac OS X
StyleManager initialization is not required anymore for Web-styled components creation
StyleManager now supports custom component painters
StyleManager now has a better support for custom settings
StyleManager skin file parsing improvements
9-patch-based painters added for JLabel and JPanel components
JLabel painter support added
WebVerticalLabel painter support added
WebBreadcrumbLabel painter support added
WebBreadcrumbPanel painter support added
WebAsyncTree root sorting/filtering do not cause an exception anymore
NinePatchEditor image rotation features added
WebButtonUI margin fix for hidden sides case
NinePatchIcon cache initialization fix
Improved text representation for UniqueNode
WebListUI rollover cell highlight fix
Default SettingsProcessors small bugfixes
Demo application heavy animation switch fix
Version files updated
@mgarin
Copy link
Owner

mgarin commented Apr 3, 2014

Should be fixed now with v1.27 update.
I also strongly recommend reading notes about StyleManager before updating.

@mgarin mgarin closed this as completed Apr 3, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants