Absolutely!
This is a bit different, objects can be buttons, so they need to be updated if they are hovered, clicked and dragged.
My mouse listener picks forwards a pick ray to the registered objects as well as the mouse state.
sure - but still, using InputHandler instead of directly using MouseInput probably would have been good. InputHandler abstracts from the different devices and would allow you to use a joystick instead of a mouse without changing much in your own code. GameControlManager is on top of the InputHandlers again and makes it even easier (exchange/flip mouse axes, buttons, joystick etc.).
Still think its a bug per http://www.jmonkeyengine.com/jmeforum/index.php?topic=5285.msg42339#msg42339
can someone confirm that the synchronized block is getting the wrong lock
theprism said:
can someone confirm that the synchronized block is getting the wrong lock
confirmed - and fixed, thanks
darkfrog said:
@Irrisor, actually, GameControlManager doesn't use InputHandler.
uh, I thought it would. I just had a look at it and it's not even event-based. :( Can't recommend anyone to use that then. We really should revamp this old KeyBindingManager and the GameControlsManager... if I only had the time to do it :(
Why should it be event based? Personally I think it's an advantage to have it the way it is. The system is designed not to capture events but to check the status of a "control". This offers many advantages since at any given time you can simply check to see the value of that control. There may be some scenarios that GameControlManager isn't best for, but even in those circumstances I've got event style Controllers that replicate that functionality on top of GameControlManager.
Besides, every event driven controller is implemented on top of a polling controller with a device manager. In the end, (at least in Linux), everything is a file, including devices. 
Rant follows! Ended up being much longer than expected…and may not fully grasp the current discussion, as I only skimmed.
From my experience with synchronization issues and events, Darkfrog is right. Synchronizing on the creation of an event does nothing but block the waiting thread, which can cause serious issues. Putting events into a queue, and then handling all of those events at a certain time in your game update is a better solution imo.
I had to consider my options when making my multiplayer networking client/server framework, and imo queuing is the way to go for this.
In regards to synchronization issues with the queue, if you want to rework things (like I have to make my own framework), you can either synchronize access to the queue, or try a class called ConcurrentLinkedQueue, which would be very suitable for this. If you want the synchronization handled for you, stay away from the synchronized collections and such, as all they do is provide a means of letting you know when your list could possibly have issues, and are not guaranteed to always throw exceptions when there are concurrent modifications.
In addition, from personal experience, events can really bog down a system that updates many times a second. We had used events for out Unmanned Ground Vehicle Ground Station, and we were wondering why we had comms coming in that were more than a few seconds old…when I wrote my own method to perform these tasks, it became real-time.
In summary:
Events are cool and useful, but it really depends on how quick you have to do things and what you're doing. Synchronization can be a pain, even when you do know what you're doing. Consider the tradeoffs!
Oh, I forgot to add in regards to my rant…just a clarification if it wasn't clear enough:
Just about everything I was talking about deals with a system that receives input in another thread, and handling it elsewhere in a main thread.