Forum

Check for pressed mouse buttons and get PositionInWorldSpace in a reactive Foreach

Hello there,

I’m getting a behavior I cannot figure out when dealing with mouse notifications in a Foreach (Ractive) (this gamma 2019.2 0081).

I’m trying to output an Observable when a certain shape is hovered and clicked with a specific mouse button. I’m using PositionInWorldSpace and Buttons node inside the Foreach, but soon as I plug the Buttons node, PositionInWorldSpace stops reporting mouse position. See here, all works fine before adding Buttons, but it falls into an unrecoverable state even after it’s been deleted.

reactive_positioninworldspace

I see both nodes don’t handle the same type of notification, but isn’t it what OfType is supposed to allow here ?

Thanks for yer helpppp

OfType will only handle one type, not multiple. PositionInWorldSpace and Buttons don’t share a specific subtype, so the OfType cannot infer a proper type, it would work if both have the same subtype. I think it should work if you annotate the input pin to a common super type (e.g. MouseNotification) and then cast the notifications. it also works without the OfType, of course.

Hey, thanks for the answer,

Still no luck though, annotating the input pin and casting the notifications causes “Object reference not set to […]”

image

Also, not using OfType works (no red link) but only if the input pin is not annotated. Buttons still turns pink though.

I would assume the Position (NotificationWithPosition) and Buttons (MouseButtonNotification) are in fact two separate notifications and therefore you do not get them both at once in one “iteration” of the ForEach.

So one solution might be to cache the last received Position and use that when you actually get the Button notification. The CastAs nodes also output Success, so use that to decide which operations to perform.

Now given that ForEach (Reactive) is stateful, you are free to use Pads or maybe the S+H node.

48

yes, because a mouse move notification is not a button notification. that’s two separate things. only one of the two cases will work at a time. as domj said. so i’d create two ForEach regions and pass a reference to a common interaction state into both regions so each notification can update a common state.

or have one region with all notifications and update the interaction state depending on the notification type.

Thanks for the pointers guys, will try to go that way !

Any chance there could be a warning in the patch, or at least a statement in the documentation about those notifications not happening in the same iteration? Does not feel intuitive since they can be connected to the same input.

Not sure if a warning specific to MouseNotifications makes sense as this is something that is quite common and is rather about the general OOP features of inheritance and interfaces which allow a single object to be considered as multiple types. Namely all of its supertypes (the types it extends - not explicitly possible to do in VL but in other .NET languages it is completely normal) and all of the interface types it implements.

So in this case both NotificationWithPosition, MouseButtonNotification are also MouseNotification - their shared part - but each also provides something extra.

Anyways, here’s a fully Reactive approach to combine the two notifications without any explicit CastAs nodes or state management. You can fairly easily modify this to fire only when the click happens inside of a given rectangle. Just filter the notifications using another Where.


ReactiveMouseClick-v2.vl (41.2 KB)

1 Like

As for the connecting to the same input, this works only if you’re using the CastAs - which will try to cast from any type to any other, returning the Default on failure.

49

In 2019.2.0140 I can only do this if I force the connection by holding space. Because there is no type resolution that would give me something that I can plug to both of these nodes. And when you force something, you kind of need to know what you’re doing.

It does feel though that there should be some error/warning after doing this as there seems to be some implicit incompatible type cast going on.

24

wow, that’s an interesting read, thanks for providing that one!