Jeremy, For your first issue, I think the problem is that the new Frame doesn't contain any focusable Components, and Frames themselves are not focusable.
Pivot directs key presses to the focused Component if there is one, and it is both visible and enabled (from memory, so might not be 100% accurate) The following lengthy thread meanders a little, but discusses a number of related issues regarding focus, Frames & Displays. (Note the 2nd page) http://apache-pivot-users.399431.n3.nabble.com/KeyListeners-on-ImageView-td2600622.html#a2633507 If your Frame will not contain any focusable Components, you could create your own subclass of Frame which *is* focusable, and then pass focus to it when it is visible. If it will, then you should be able to pass focus to a focusable Component within the Frame. I have seen similar artifacts as shown in your second issue, but haven't had the need to dig into the problem to investigate. There seem to be a multitude of JVM flags & properties which can be set to influence painting, but this is not an area where I have any expertise. Probably the first thing to do is to supply as much information as possible regarding your OS, JVM, system properties etc and perhaps someone who is more knowledgeable can suggest some tweaks to try out. If possible, try to replicate the artifacts on another machine, or better still, another OS. Chris On 20 April 2011 02:51, Jeremy Jongsma <[email protected]> wrote: > I'm running into a couple issues in my app, and am wondering if these > are bugs or if I am doing something incorrectly: > > Screencast (18 secs): http://www.youtube.com/watch?v=t598VGgHIIk > > 1) ListView doesn't seem to give up keyboard focus when a new Frame > opens (at 8 secs in the above screencast). After the frame opens, arrow > keys still control the ListView. It still does this after explicitly > clicking the new Frame. > > 2) Painting seems laggy when using ScrollPane. There are a lot of > visual artifacts when scrolling through the list view; at around 4 > seconds in the screencast above, you can frequently see double-selected > rows. More concerning is that at 11 seconds, it is actually shifting a > piece of the Frame above it (which is not even a descendant of the first > Frame) until the next repaint happens. > > -j > >
