On Feb 23, 2007, at 10:16 AM, [EMAIL PROTECTED] wrote: > On Feb 23, 2007, at 15:18 UTC, GregO wrote: > >> So I'm trying to implement a magnify cursor on a canvas that changes >> to a MagnifySmaller cursor when the user is holding down the option/ >> alt key, but have not found an event that fires when that key is >> pressed. How do I get it to change (short of expecting the user to >> move the mouse to see the change). I realize that I could use a >> timer, but I'm trying to bundle this all into one class if possible. > > You've considered all your options. The user pressing or releasing a > modifier key, by itself, is not an event. So the only way to > detect it > is to periodically check for it. > > But there is a way you can create a Timer in code, and bind it to > yourself (er, your Canvas class) such that you get notification > when it > fires. It's not exactly ideal, but may be good enough for your > purposes. The trick is that Timer is a subclass of ActionBinder, > which > defines an addActionNotificationReceiver method (as well as a > corresponding "remove" method). So, if you make your class implement > the actionNotificationReceiver interface, then you can do something > like this: > > tim = New Timer // where tim is a property of this class > tim.addActionNotificationReceiver self > tim.Mode = Timer.ModeMultiple > tim.Period = 500 > tim.Enabled = true > > Now, whenever Tim the Timer fires, your PerformAction method (which is > what the actionNotificationReceiver interface defines) is called. > > The reason I say this is not ideal is that if you have more than one > timer (or other ActionBinder) to bind, you have no way of telling > which > one is calling your PerformAction method. It'd be better if > PerformAction had a "source as ActionBinder" parameter, so if you have > multiple sources of actions, you can take different action > depending on > which one's invoking the method. But, c'est la vie, no? It's still a > pretty neat trick, and often useful. > If you really (for whatever reason) do need multiple timers, the best bet is to create a Timer subclass - this will expand your options considerably.
1) The timer subclass can define a property of type <reference-to- yourclassname> and a setter method which would be called from the method that instantiates the timer. The timer could then make a callback in its Action() event to a known, public method in your class. This would eliminate the need to worry about the implementation-specific detail that Timers are subclasses of ActionBinder 2) The timer subclass can define a property to serve as a unique id that - again - your calling code can set in the method that instantiates the timers. Then the callback can distinguish among the timers (assuming one of the parameters is either a <reference-to- timer-subclass> or the unique id. The only disadvantage is you have to drag the timer subclass along wherever you go, but you could make it part of the default new project RB gives you when you start up. Just start RB and allow it to give you a new, blank project. Add (import) whatever classes, modules, and windows you want, then save as "Default New Project.rb" and save this in the "Stationery" folder inside the application folder where you installed RB. I know this works up to RB2006r2 (Mac), and RB5.5 (Mac/Win). Be careful of external references, though!!! :) > Cheers, > - Joe > > -- > Joe Strout -- [EMAIL PROTECTED] > Verified Express, LLC "Making the Internet a Better Place" > http://www.verex.com/ > > _______________________________________________ > Unsubscribe or switch delivery mode: > <http://www.realsoftware.com/support/listmanager/> > > Search the archives: > <http://support.realsoftware.com/listarchives/lists.html> _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
