Or rather, my JWindow does. Howdy, y'all! (would rather not post my code in full just because it's so huge... will post salient parts) (also might should have posted in the intermediate forum because of complexity, but I might be missing something simple and this is where most of the other focus questions are...) Here's the setup: I've got a several-part-program. A programselector comes up and you can change variables and pick which test you want to run. Once you pick one, it opens a Base class (extends JWindow implements KeyListener, WindowListener). The base class runs one of a number of different kinds of programs, whatever you selected in the programselector. The mouse works fine, and that's the primary operator for working the test, but there's supposed to be keyboard shortcuts to skip questions on the test or quit the test entirely and bring the programselector back up, and right now they aren't working. I developed some test code to try to figure out what's happening:
And consistently get "Displayable, visible, focusable, lacks focus". I've tried putting this block in the Base constructor, in the Base setup, in the subprograms during the mouseclicks (so you know that window's active!), in the programselector after the Base has been called, sometimes in all of the above! (with slightly different println messages to distinguish where they are) I've also tried the "windowActivated -> runnable" trick in Base to request focus when the window is activated, but after adding a println to that method I realized that either the window isn't ever activated or I'm missing something. Here's what I wrote in Base: (I added the getFocus method because, for whatever reason, JBuilder 2005 recognized requestFocus in some places but not in the windowActivated block)
So a window needs to be displayable, focusable, visible, and what else? Thanks for your time,
(P.S. That fly is both totally great and totally gross!)
I'm gonna move your topic to our Swing forum, where you'll likely get a better response. But first, I'm gonna point out our JavaRanch Naming Policy, with which I'm afraid your name does not comply. I have to ask you change your display name to comply (we are looking for a real-sounding first and last name; although we encourage the use of your actual name, it just has to be something that could be your actual name.)
Piscis Babelis est parvus, flavus, et hiridicus, et est probabiliter insolitissima raritas in toto mundo.
(as for names... I was wondering why I didn't see any oddball names...)
Originally posted by Michael Dunn: > Or rather, my JWindow does.
use an undecorated JFrame
JFrame f = new JFrame(); f.setUndecorated(true);
Would like a bit more reference for where to put this... Are you saying that Base should be a JFrame instead of a JWindow? Or I should make a JFrame inside Base, do the appropriate graphics in there, and requestFocusInWindow on that? (or requestfocus... I think requestfocusinwindow only works if the window has focus, which is where I'm having trouble to begin with...) Basically, what should I do with this JFrame?
"...If any of these conditions is not met, then neither this Window nor any of its subcomponents can become the focus owner."
i.e. you must have an owning frame/dialog visible on the screen, and if you're using java 1.5 - the focus subsystem behaves differently to 1.4 (the above link says 1.5, but it's only an update from 1.4)
> Basically, what should I do with this JFrame? an undecorated frame will appear the same as a JWindow, but far easier to control
So Base is now a JFrame implements keylistener (dropped the windowlistener). On first run, the focus messages came back positive. (Well, some came back negative, but that might have been them being applied to copies of Base rather than Base). On second run, I tried out the keys and they worked (and subsequently added the new keys I was hired to add...)
So yeah, thanks much. I'm not sure I fully understand the JFrame/JWindow difference... I kind of get the thing about the window's parent needing to be focused, except I think it might have been an orphan (more fun with trying to patch other peoples' code...).