• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Focus Lost throws error

 
Ranch Hand
Posts: 124
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,
I am getting a very annoying error as a result of using a focus listener on one of my textfields.
I have a focus listener on a textfield that causes an update elsewhere on my GUI when it loses focus.
My problem occurs when the focus event is fired because I select one of my menu items. When the cursor is still in the textfield and i select a menu then a focus event is fired. This focus event is temporary. When i select the "close" menu item i remove the two panels that had been added to the main frame. However once the close event is completed the application fires a focus event on the text box where the cursor had been. The result is that the focusLost event then tries to access an object that has been set to null as a result of removing what was displayed on the GUI and i get a nullpointer exception.
I am wondering if there is any way of preventing focus returning to my text box and firing the focus event? How is the JVM informed when components are no longer present on the GUI and as a result should not be sent events. I am assuming that the focus event is being fired due to my textfield being held in memory as the GUI component currently in focus and to which focus should return after the event generated by the menu interaction has finished?
Thanks,
John
 
John Ryan
Ranch Hand
Posts: 124
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry guys, Im still having trouble with this one so i just thought id bump it up a bit. Maybe someone has an idea..
 
Ranch Hand
Posts: 508
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't understand how a focusLost event on a textfield can trigger the appearance or disappearance of other ui components - logically. does this really make sense? should the appearance/disappearance of these components not depend on the _value_ of the field? a documentlistener or keylistener would be more appropriate in that case.
or you want to leave it to the user to decide when he/she is finished entering a value in the field. an actionlistener would be sufficient in that case.
maybe it would help if you could explain why you want to listen to a focusevent in the first place.
(as a FocusEvent is a lowlevel event and thus gets fired more often than document or action events which already implement some basic ui logic).
Chantal
 
John Ryan
Ranch Hand
Posts: 124
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Chantal Ackermann:
I don't understand how a focusLost event on a textfield can trigger the appearance or disappearance of other ui components - logically. does this really make sense? should the appearance/disappearance of these components not depend on the _value_ of the field? a documentlistener or keylistener would be more appropriate in that case.
or you want to leave it to the user to decide when he/she is finished entering a value in the field. an actionlistener would be sufficient in that case.
maybe it would help if you could explain why you want to listen to a focusevent in the first place.
(as a FocusEvent is a lowlevel event and thus gets fired more often than document or action events which already implement some basic ui logic).
Chantal



Maybe i wasnt very clear but the focus event does not trigger the removal of any GUI components. When the textfield loses focus a value displayed in another textfield is updated. I decided to use a focusEvent as i figured that this would be fired less often than a Document event. For example if i use the Document event to update the value displayed in another text field then this event would be triggered each time a new character was entered or removed. By using the focus event i prevent these extra events and the other text field value is only updated once.
I wouldnt say my problem is specific to my application. It can be as simple as this. Create a JFrame which contains a panel with a single text field. Add a focusListener to this textfield. On the focusLost event you set a value in an object ( myObject )that is used throught the application.
You have a single menu with a single menu item whose only functionality is to remove the panel( which includes the textfield) from the JFrame. On the removal of the Panel myObject is also set equal to null.
Now put the focus in the textfield and then select close from the menu. After the close event has been completed the JVM returns focus to the text field (which is no longer displayed) and the focus event is fired again. As a result the focusLost event tries to access an object which is now null. I suppose the most obvious solution is to check that this object is not null but im more interested in knowing why the JVM returns focus to a component that is no longer part of the JFrame.
I wrote a class that tests and reproduces this problem.


In the above code i could check that the value of m_myDummyClass is not null when the focusLost event is executed but this does not really answer my question......
[ December 04, 2002: Message edited by: John Ryan ]
[ December 04, 2002: Message edited by: John Ryan ]
[ December 04, 2002: Message edited by: John Ryan ]
[ December 04, 2002: Message edited by: John Ryan ]
 
Ranch Hand
Posts: 2823
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The order of the events is not set. It just happens that that is the last event that is processed. It decided to do the event from the menu first.
 
John Ryan
Ranch Hand
Posts: 124
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Paul Stevens:
The order of the events is not set. It just happens that that is the last event that is processed. It decided to do the event from the menu first.


Okay Paul but the focusLost event is actually executed three times. It is first executed when i select the menu. Then the event on the menu selection is fired. After tracing through my test code it seems like the focusLost event is again fired when the panel is removed from the frame. It would seem that the easiest way to solve my problem would be to remove the panel first and then set m_myDummyObject to null in the next line. However even when i do this the focusEvent is executed for a third time. I thought this might be because of the repaint but it doesnt seem to be. Do you know what could be causing this third focus event
[ December 05, 2002: Message edited by: John Ryan ]
 
Chantal Ackermann
Ranch Hand
Posts: 508
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
sorry, I'm a little slow... :roll:
does the component disappear forever (for the rest of the runtime) or does it appear again at some later point. in the latter case, I'd use CardLayout. The component wouldn't be removed but made invisible. thus, you wouldn't have to recreate it at some later time, but rather reuse it (performance). Moreover, I think the GUI would be "more aware" that the component isn't visible anymore and would set the focus to another one. And even if this wouldn't work - no NullPointerException should be thrown, and you could request focus for the component you wish to.
Chantal
 
John Ryan
Ranch Hand
Posts: 124
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Chantal Ackermann:
sorry, I'm a little slow... :roll:
does the component disappear forever (for the rest of the runtime) or does it appear again at some later point. in the latter case, I'd use CardLayout. The component wouldn't be removed but made invisible. thus, you wouldn't have to recreate it at some later time, but rather reuse it (performance). Moreover, I think the GUI would be "more aware" that the component isn't visible anymore and would set the focus to another one. And even if this wouldn't work - no NullPointerException should be thrown, and you could request focus for the component you wish to.
Chantal


Hi Chantal,
The code i provided is not my actual implementation but just a quick test so i wouldnt pay much attention to the layout etc. Im actually using a GridBagLayout in the implementation. When i remove the panel that holds the textfield i am removing it for good ( so hiding would not be appropriate ) and adding a totally new panle to the GUI. So really the main question is why there are three focusLost events triggered by the action of selecing a menu and removing the panel from the JFrame...........
 
reply
    Bookmark Topic Watch Topic
  • New Topic