Mac OSX has builtin support for mice with a scroll wheel. But a carbon app has to set up an event handler. You install the handler with a reference to the window and a pointer to some chunk of data. Then when the handler is called it gives you that pointer. The necessary API stuff is in CarbonEvents.h. I am attaching an exerpt from Apple's SimpleText sample that shows how they use it.
I noticed a change with the wheel API with the OSX seed I just received. When you check the axis parameter in the event handler, you should check for it being kEventMouseWheelAxisY, not kEventMouseWheelAxisX.
moving my osx bugs to 0.9.2
new patch looks heinous, but is pretty straightforward. making scrollbar hack only non-carbon and hooking up carbonEvents for scrollwheel. had to refactor a bit of the event handler to unify the two models, but nothing tricky. needs r/sr/a for branch.
r=beard. i changed nsMacWindow::ScrollEventHandler to add err checking for the calls to ::GetEventParam so we won't scroll with garbage values if any of them fail.
+ nsMacWindow* self = NS_REINTERPRET_CAST(nsMacWindow*, userData); + self->mMacEventHandler->Scroll ( axis, delta, mouseLoc ); maybe a paranoid check for null here? Otherwise sr=sfraser
now on both trunk and branch.
Fizzilla 2001070216 from contrib/fizzillacfm. You might want it to scroll more on each scroll event. It looks like each tick on the wheel gets about one line of text. omniweb seems to scroll 4 lines per tick. On my Logitech wheelmouse, fizz took 47 wheel turns to scroll thru macsurfer.com, where omniweb took 14. One idea: you could use some primitive acceleration logic, like scroll 1 or 2 lines on the first scroll event, but on subsequent events (within a short period) it would scroll 4 or more lines.