Bump.
Bump for justice.
LummoxJR wrote:

This sounds interesting, but it needs to be fleshed out a little more. The mouse wheel message is sent to whatever control the mouse pointer is currently over, so this would have to be implemented in a way that didn't interfere with that.

Well, since the last word on the subject was that it needed to be fleshed out a little better to prevent interference with the built-in mousewheel stuff...

Map control changes:

When over the map control, this isn't a problem at all. We can just include a new checkbox for the map control similar to the "Send right clicks to mouse procs". "Send mousewheel actions to mouse procs".

If the client detects a mousewheel action, it calls client.MouseWheel(), which will then do whatever it is that Click()/MouseDown()/MouseUp() do to detect which object gets atom.MouseWheel() called on it.


Other control changes:

Another checkbox would have to be implemented for all controls that consume the MouseWheel event. "Send mousewheel actions to mouse procs" should by default inherit the value of the window's mousewheel control when the elements are created.


The mousewheel proc:

client/MouseWheel(object,location,control,params)

default action: Call object.MouseWheel()
returns: Returning 1 allows the interface control to consume the mouse event. Returning 0 consumes the mouse event, and doesn't pass the scrolling action to control.

object is null if the mouse isn't over an atom within a map control.

control is the interface control directly beneath the mouse when the client triggered the scroll event.


atom/MouseWheel(location,control,params)

default action: none

returns: 1 if the scroll action should be processed by the client's interface control. 0 if the action should not be processed by the client's interface control.

Do not define this unless you need it, as it causes extra overhead that should otherwise be avoided.


params for both should be:

x_velocity = the horizontal velocity of the scroll action
y_velocity = the vertical velocity of the scroll action.

For the x/y velocity, the scroll action is positive if scrolling up, and negative if going down. Since most mousewheels these days allow the wheel to be tilted left/right, we shouldn't leave out x velocity.

I think, however, that on the map, or an object in a statpanel/grid, clicking and holding the scrollwheel should function as normal as a middleclick and drag. Meanwhile, clicking and holding elsewhere on the interface could trigger a scroll action on the control that started the action.


The upside of this approach, is that it allows the developer to change the behavior/timing of mousewheel actions on other controls, meanwhile, it still acts similarly enough to other Mouse procs that it would fit right in with the set that we currently have.
You're my hero~
@Jittai: This is what we're hoping to do with feature requests as part of our feature request cleanup project, to make it more than just a simple: "Please add this" and more of a "please add this, and this is how it should work", so that Lummox can actually read these threads and get ideas for how to add things, and how people want to use the software, not just what they want it to do for them.

If you could help get the ball rolling on that, and take a look through any feature requests you want to see and do a writeup like the one I just did, I'm sure it'll help stimulate development on these features a bit more than just "++++++++++++++++".
Perhaps for future threads there should be a template like there is on bug reports? It seems like you almost wrote a reference page for the feature or at least used it as template.
A template would be very awesome. I'm glad this is seriously being considered for implementation as there's a lot of nifty stuff you could do with the mousewheel.

Thanks very much for the fleshed out write-up. I'm terrible with explanations, but you captured exactly what I was bringing to the table.

Keep on rockin'
I can't say that it's being seriously considered. I just want to format it in a way that Lummox could potentially read it and get some ideas for how to implement. Seems to me that makes him take requests more seriously.

I don't speak for Lummox or Tom when it comes to features and bugfixes. I'm closer to one of you guys than I am one of them when it comes to totem pole.
Bumping for great justice.

@Lummox: I wrote a proposal for how it should be handled, per your request back in 2010:

http://www.byond.com/ forum/?post=112967&page=3#comment10234137
Bumping some more for great justice.
Bump. Ter's write out covers the issues; I feel like this is a much needed technical feature.
Figure it's about time for another bump. Hope this can be added soon. Pretty sure Ter13 already covered all the information for it a few comments up.
Going to bump this again. I've ran into a design issue this is the most intuitive solution to. I'd rather wait on this being done then have to come up with something else that wouldn't feel as right.
I have to say I'm not a huge fan of the idea of using a checkbox for each control to say whether it wants to consume mouse wheel actions or send them to client/MouseWheel(), but otherwise I'm on board and would like to seriously consider this for 508.

So if client/MouseWheel() was a thing, what are some other ways that a control could say it does or does not want the event? Or should it simply be assumed that browser controls, grids, stats, output, multi-line input, and scrollable panes always expect to handle the wheel themselves?
I'd be happy just being able to have MouseWheelUp, MouseWheelDown, and MouseWheelClick be assigned to macros, personally. I'd imagine only the map element needs to capture it, as other controls usually end up with scrollbars in some from or another.
In response to Nadrew
I think mouse wheel clicks would tend to register as middle clicks.
While i've browsed through a good amount of this a while back, i haven't gone too deep so i'll just leave my opinion on what seems to be being discussed here: that being that i'd prefer mouse wheel stuff to also work on things with scrollbars, i mean, if we can why not? as for ideas, my first thought was it seems the same as already given (to specify mouse wheel operation per interface control)... but i'll think on this a little more when i have some time and hopefully come up with something more acceptable.
In response to Turboskill
It seems though as if it's far more sensible for something scrollable to handle the wheel message itself, and scroll, than to pass that to the server. And doing both would be a bad idea.
I'm pretty sure browsers can use javascript for mouse wheel manipulation, and usually that's just for things like custom chat windows so if the map has it then it makes it easy to just do chat properly on screen.

So I think map handling would be enough for most of what people, including myself, want this feature for.
I think it would just be assumed that controls that typically scroll (I haven't done a lot with interfaces in awhile, so I wouldn't know enough to list more than the obvious): browser, output... And then the map on top of that, would be the only things that would need to register scrolling.

I can't see any reason scrolling would be needed for a button or label.
Page: 1 2 3 4