In response to F0lak
F0lak wrote:
I can't see any reason scrolling would be needed for a button or label.

Nor can I, but my luck is when I plan on something not being used, someone tries it anyway. :)
Fair enough! haha.

I know I don't know a lot about this sort of thing, but couldn't you just detect mouse scrolls client-side, then figure out what's under the mouse, then if that element accepts mouse, see what/if anything it has coded to do?

Could it maybe be written into DM similar to the other mouse procs in that it explicitly states it generates extra communication, but it's ignored if not defined in soft code?
Basically the approach I'd use is similar to that, yes. If MouseWheel() were defined, I'd have a flag for the .dmb that would say so. Then if it's used over any control that doesn't expect to handle mouse wheel events internally (browsers, output, etc.) I could just send it as a normal mouse command. Like with move/over, I'd probably pull the old wheel command if one was pending, and adjust the delta.
Sounds like you've got it all figured out. :)

What else would we have to discuss before this could be added to your big ol' list?
In response to F0lak
F0lak wrote:
I can't see any reason scrolling would be needed for a button or label.

I wouldn't count on that one. Some people do some pretty crazy things with labels, they may decide they want that too haha. It doesn't mean it needs to be supported though, that would be so few people, and they would have other options.

I personally would only use it on map, and if it were available; output and maybe browser. I always hate the scroll bars in output, which urges us into browsers, but I'm not good with javascript yet so that is troublesome. Then you've got games that need to do on-screen chat, and it's hard to make the chat live up to output because of the mouse wheel scroll issues.

Another approach might be to make MouseWheel() independent of the individual controls of the game, and instead leave it up to the developer to narrow down which control has focus.
In response to Multiverse7
Multiverse7 wrote:
Another approach might be to make MouseWheel() independent of the individual controls of the game, and instead leave it up to the developer to narrow down which control has focus.

I don't see a good way to handle that without the aforementioned checkbox.
Lummox JR resolved issue with message:
MouseWheel() has been added to client and atoms. It takes two forms:

client.MouseWheel(object, delta_x, delta_y, location, control, params)
atom.MouseWheel(delta_x, delta_y, location, control, params)

As of this release, only delta_y is supported. A full "notch" down scroll is delta_y=-120, and a full "click" up scroll is delta_y=120. Wheel messages will not be sent if the mouse is over a browser or a scrollable control.
Four long years, but all the sweeter in the end. Thanks dev team! Thanks Lummox JR!

WHOO!


*uses it to scale the map in a way I shouldn't*
Not really a big deal since I imagine we can just do it with maptext now, but it might be pretty cool to extend the can-scroll setting into outputs and make it so that if it's disabled wheel messages will be sent on them for custom chat scroll bars.

If that takes more than even a tiny bit of work it's not worth it though. Especially since I suspect this wouldn't even come into play on the webclient.
Page: 1 2 3 4