Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : MSFT Internet Explorer vs. NSCP Navigator -- Ignore unavailable to you. Want to Upgrade?

To: Keith Hankin who wrote (16875)	1/29/1998 11:19:00 PM
From: nommedeguerre	Read Replies (1) \| Respond to of 24154

Keith, >>I still don't see how it is possible for 2nd mouse button support for a context-sensitive menu is possible unless if supported within the application itself. Since Mac software is written with only 1 mouse button in mind, I don't see how it is possible. For one thing, there would have to be some sort of event type that the application can pick up that indicates not only that the mouse button was pressed, but at what pixel position, then the pixel position would need to be somehow translated to what object is exposed at that position, and then it would need to translate this into some sort of method call on an object. Even assuming that this problem is solved, this must be written into the application and cannot be scripted or mapped from outside. A week on the Apple is not enough for me to give an absolute example but I will give the best hypothetical mechanism that might show how it is possible. The mouse driver that comes with a multi-button mouse would generate an event message to an event-handler which was bound to the mouse driver. The event contains the position of the mouse when pressed, the button that was pressed (button press, button release, double-click, single-click, etc.), and the application frame window which was active under the cursor. The event handler could use the application frame to determine how to translate the button action into a keyboard event that the application recognizes and which performs the desired action. Example: Lets assume pressing F5 in an Application XYZ causes Menu ABC to pop-up and you want this action performed when the right mouse-button is pressed. The event-handler would receive an event from the mouse that the right button was pressed inside the Application XYZ frame at pixel x,y. The event-handler recognizes that any Application XYZ right mouse-button event will generate a keyboard event for an F5 keypress. The keypress event is sent to Application XYZ as if F5 had been pressed. Application XYZ then pops-up the Menu ABC. The pixel position is not important for this example. To the user it would appear that the right mouse-button press caused the Menu ABC to pop up. Example: If pressing ALT-S on a word in a text editor causes that word to be spell-checked and you want this mapped to the middle mouse-button then that is no problem either. We can assume that when the application receives an ALT-S it queries the system as to which pixel the mouse is currently pointing at. It then translates the pixel-position into a word object and calls the spell-check routine, etc. All we need to do is be able to recognize frames of a type frame.editor.text (or some such name) and then translate the middle mouse-button event into an ALT-S keyboard event. For instance, if an event for frame.editor.filemenu shows up it might be remapped to an ALT-F keyboard event. An event for frame.editor.exit might be remapped to an ALT-X keyboard event. Every little button, scrollbar, text window, checkbox, etc. on most windowing systems is identifiable in an event message. I'm not saying this is how it is done on the Mac but it is one way it could happen. A unique decoder would exist for each piece of software. Kinda jumbled but maybe it will make a little sense. Take it easy, Norm