Mojox Mouse Event destroyed

[Abe _King_Participant]

I was working on making my own component and decided to make my own kind of system for reading in what elements were clicked. The problem is as that as soon as elements are inside that eat the mouse event the container which is also supposed to be registering some clicks doesn’t work.

Maybe there is a way to work with existing mojox components that don’t take over the input flow? Or a way to remove their default behavior without having to make an entirely new class?

Perhaps making an extension that overrides how inputs work is the only real route to go? But that doesn’t seem too practical. . .Does anyone know a good way to work around this?

I believe in html the approach would be to capture the event and “prevent default” . . . or just let the event bubble through somehow. Maybe the event system in mojox needs a slight adjustment? Say we don’t to listen for events on a label, why should the label consume events if there’s nothing even listening for them? Hopefully I’m making sense.

TDLR; how do I go about listening for mouse events in a container even when a child element has consumed the event?

[Mark SiblyKeymaster]

What are you trying to achieve here though?

If the user clicks on a button and *something else* happens, isn’t that confusing?

What is the ‘real world’ use for this? Not the hypothetical ‘I want to be able to intercept events’ use, but the practical “I want to create a widgets that does XYZ’?

[edit]One thing I was thinking of doing originally was to add a ‘top down’ event filter system.

So before a view gets sent an event, all its parent views get a chance to filter the event first, using something like, say, OnFilterMouseEvent( event:MouseEvent ) etc. If a parent eats the event, the event is never sent to the child view, ie: it’s default prevented in a sense (although I never really got my head around how preventDefault worked in JS, I just used it as and when instructed to by stack overflow – I found the JS event system confusing and I don’t want to emulate it).

Here, I was thinking mainly of a GUI editor app where you want to go into a ‘mode’ to drag GUI elements around. I sort of forgot it about it because auto-layout solves most layout problems (or should anyway) and writing a GUI editor would have been a waste of time.

[Abe _King_Participant]

(Tl;DR at bottom )
@admin It’s mostly about control over the flow of the application. I didn’t really expect a label to be blocking mouse inputs from me and was thinking, wouldn’t it be better to let that be an optional feature instead of ingrained?

The real world use I’d say would be flexibility. I have a lot more control over my own application if I can decide what elements I add into a container are blocking or not . . .

My particular use-case was trying to imitate a bit of the API from ListView my own way. I wanted it to be able to use any element that extends a view and then, instead of having to specifically know if the (or which) element being added can have a click being listened to, be able to register clicks based on cells rather than what specific element is added in.

I feel like this would reduce the amount of extra code and structuring.

IE:

Monkey

Function Example1() Local tileGrid:=New TGrid tileGrid.onClick( Lambda( cell:Int, view:View ) Print "position: " + cell End ) For Local i:=0 Until 100 tileGrid.add( New Label ) Next End ' The children here are taking over the event! Function Example2() Local tileGrid:=New TGrid ' add elements here For Local i:=0 Until 100 Local label:=New Label Label.clicked=Lambda() Print "position: " + i End tileGrid.add( label ) Next End

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

Function Example1() Local tileGrid:=New TGrid tileGrid.onClick( Lambda( cell:Int, view:View ) Print "position: " + cell End ) For Local i:=0 Until 100 tileGrid.add( New Label ) Next End   ' The children here are taking over the event! Function Example2() Local tileGrid:=New TGrid ' add elements here For Local i:=0 Until 100 Local label:=New Label Label.clicked=Lambda() Print "position: " + i End tileGrid.add( label ) Next End

Now for a small detail, you can tell there are already some minor issues in comparison . . . The second example adds a lot of extra memory overhead with all of those closures. The second version also means that if I start doing some re-ordering of my tileGrid the index saved inside of my closure is useless. I can work around that to an extent by making a helper function get the index from the mouse position on a click but it’s an extra cognitive overhead. There is also, of course, the problem that I may want to use the entire view as a whole but having certain items in the view that, undesirably, consume an event will force me to split up an action into two different listeners because the lower level listener stops the primary one . . .

I like to think of GUI composed as a group of pieces which work together instead of having precedence over each other. The problem for me might not be that we need more control over the bubbling, but that we need more composable elements which combine together more seamlessly. For example; A button would be a view which can be clicked and handle some events, you’d give it text and an icon by adding those components as children and further simply listen to that button.

– Sorry now, think I’m just rambling at this point!

TL;DR: We’ll have more control over the flow of the GUI and therefore be able to bend MojoX at a higher level to do more for us without actually creating specific iterations of each component.

TL;DR 2: Instead, maybe create more composable elements that allow us to generate a structure of layouts and ways to handle interactions with the declarative parts separated from the imperative parts.

Edit: And of course, don’t let me forget, thanks for the reply!!

[Mark SiblyKeymaster]

I wanted it to be able to use any element that extends a view and then, instead of having to specifically know if the (or which) element being added can have a click being listened to, be able to register clicks based on cells rather than what specific element is added in.

I’m not 100% comfortable with this because it means the behaviour of the added view may not be consistent. Many views wont work properly if you’re stealing mouse events – in fact, only views that have (or could have) a simple Clicked:Void() signal will really work (as expected) with a view like your TGrid.

That said, have a play with View.AcceptsKeyEvents and View.AcceptsMouseEvents – just remembered these even existed! Set these to false and views will send key/mouse events to parent views.

As for ‘composable’ guis, the idea is nice in theory but in my experience they are kind of a PITA in practice. Having a button (and other view types) that can have both text and an icon is just incredibly convenient, esp. if your ‘hand coding’ GUIs. And beyond buttons, what else really needs to (or can) be composed (apart from layouts)? Fancier buttons I guess…

[Abe _King_Participant]

Thanks for the help, Mark! Hmm. . . Maybe I’m overthinking this then. Although it would be nice to emulate how ListView works, by being able to listen to clicks from the container rather than each element, it may just be best to ignore this functionality.

This was just considered bad practice in JS when adding a listener for each element rather than use one that kind of figures out which one it’s working with. I’ll probably end up scrapping that idea then and just go with a more natural flow for mojox. Still getting used to it though. . .

[Mark SiblyKeymaster]

it would be nice to emulate how ListView works, by being able to listen to clicks from the container rather than each element

Well, AcceptsMouseEvents sort of lets you play with this idea, although I think FilterMouseEvent() would be the nicer way to do it –  you’d be able to filter only some mouse events (not all) plus you wouldn’t have to change state of child view.

I think what you’re really thinking here is why is there a specialized ListView.Item class, why don’t ListViews just contain ‘Views’.

The reasons for this are actually mostly practical – an Item is lighter weight than a View, useful if you want lists of 10000 items (although less useful than it once was); an Item can also be highly customized, eg: TreeView.Item can be expanded/collapsed – but it is a valid question and in theory it is possible to write a more ‘pure’ gui like this. It’s harder though (try it!) and most/all guis I’ve used like Qt, cocoa, windows etc use ‘specialized’ ListView.Item types in a similar way so it’s not just me…

But I’ll keep thinking on this one ‘coz it’s interesting, and while I think emulating a ListView is pointless (just use a ListView!) it does mean you can’t use, say, a GridView to contain items ListView style…

[Author]

Posts