 Documentation |
| Documentation |
| public interface MouseHandlerConstants // This interface contains the definitions // Needed for the HyperMouse.class MOUSE_ENA EXIT REMOTE_MOUSE_ENA HAVE_GADGET GADGET_GRABBED LEFTGRAB_ENA //To left mouse grab the Gadget //set this bit in gadget.onClick() MOUSE_LMBD // set when respective buttons are pressed MOUSE_RMBD GET_COORDS // If you Set this bit all mouse clicks // are saved in the file "hyperview.dat" // very handy if you want to save a bunch // of screen coordinates. // Direct AWT equates. Post and pre JDK1.1 // Event model See below. MOUSE_FIRST = 500; MOUSE_CLICKED = MOUSE_FIRST; // Pre JDK1.1 MOUSE_PRESSED = 1 + MOUSE_FIRST; //Event.MOUSE_DOWN MOUSE_RELEASED = 2 + MOUSE_FIRST; //Event.MOUSE_UP MOUSE_MOVED = 3 + MOUSE_FIRST; //Event.MOUSE_MOVE MOUSE_ENTERED = 4 + MOUSE_FIRST; //Event.MOUSE_ENTER MOUSE_EXITED = 5 + MOUSE_FIRST; //Event.MOUSE_EXIT MOUSE_DRAGGED = 6 + MOUSE_FIRST; //Event.MOUSE_DRAG Note: The Mouse Handler encodes the Event into a HyperKey.class Object. The reason for this is so the AWT-Event Thread can release the actual key Eent ASAP. This means the Listener (which receives all the events from the parent Container) doesn't fail because of code that is too slow to process the Event. The Event coded HyperKey is a static array so there is no issue with having the MouseHandler causing critical saturation/overflow of the underlying AWT-Event Thread. Further different operating systems handle events differently. Without encoding the Events they can in fact be handled differently on different operating systems. ie: a non problematic mouse click on Windows could take 10 seconds on Linux. The MouseHandler.class encoding elimitates this potential pitfall. |