Mimic enabled property?

[trevordevore]

I want a widget that doesn't process mouse clicks. Is there way to mimic the enabled property when it is set to false?

[LCMark]

@trevordevore: We have this on the list - http://quality.runrev.com/show_bug.cgi?id=14500.

Given that subtlety with 'effectiveness' of the disabled property, we intend to make it so that when 'disable' no interaction events will propagate to the widget; and we will add syntax to be able to fetch its current state so that rendering can reflect the disabled state.

[LCMark]

@trevordevore: Seems I thought the engine worked more correctly than it did with enablement! Turns out there is nothing clever about it at the moment - http://quality.runrev.com/show_bug.cgi?id=14881.

So you can provide the correct behavior in a widget without any support (albeit at the expense of code!) - just ignore mouse events! We will make this easier though as outlined above.

[trevordevore]

@runrevmark - ah, the behavior described in the bug report has always annoyed me. The issue I have is that I want mouse events to pass THROUGH the widget to the control beneath. That isn't currently possible, right?

[LCfraser]

It should be, but we've not hooked up the key events yet.

The plan is that there is an "OnBoundsCheck" or similar event that would allow the widget to report that part (or all) of it is transparent to mouse events - the primary use-case in mind was non-rectangular controls but it would also have been usable for emulating click transparency, had we plumbed them in.

I shall make sure it gets added to our TODO list.

[LCMark]

@trevordevore: Ah - I wondered if that's what you meant - do mouse events really pass through disabled controls in LC?!? I never realised that... Talk about wrong from any reasonable point of view - another anomaly report methinks!

Anyway, ignoring deficiencies in the engine - @livecodefraser and I figured out a method for this. Widgets will be able to have a HitTest event which determines whether they are under the current position being considered. This is distinct from their bounding box. Additionally, there will be an event for computing the Bounds of the widget which is distinct from its rect - allowing painting outside the rect of the widget.

[trevordevore]

@runrevmark - Probably wrong for a normal control. When creating custom controls back in the pre-widget days it was an easy way to aggregate controls but have one control process the mouse clicks. This was useful in situations where a custom control had multiple hotspots that could trigger actions. In my current case, I wanted to overlay some text on a widget that only needs the text once in a while. Having mouse events pass through would have allowed me to consolidate the mouseUp handler in the primary widget. Easy enough to work around though.

The proposed changes sound great @runrevmark and @LCfraser.

[malte]

@trevordevore: Ah - I wondered if that's what you meant - do mouse events really pass through disabled controls in LC?!? I never realised that... Talk about wrong from any reasonable point of view - another anomaly report methinks!

Anomaly, maybe, but one I know for sure I have exploited more than once...

[LCMark]

Yes - perhaps a little bit of an over-reaction on my part - we're trying to add widget support as cleanly as possible in the engine, by touching as little code as possible so I was concerned that getting widgets to work in the way we had intended would require more invasive changes to existing controls. As it turns out I was tilting at windmills - the effect of the disabled property is entirely defined at the individual control level.

I do (now!) remember it coming up in the dim and distant past on the lists. The ability to have controls be 'transparent to interaction events' is useful - but it should really be separate from the 'disabled' state as they are unrelated. After all, the 'disabled' state affects the way controls are rendered whereas just making it so that they pass any mouse (touch etc.) events through shouldn't have that effect.

Widget's will allow transparency to events via control over a 'HitTest' event (you just always return 'false'); so we can separate out the disabled property and event transparency easily.

[LCMark]

@trevordevore:

I've filed http://quality.runrev.com/show_bug.cgi?id=14899 for custom hit-testing (to provide 'event transparent widgets')

I've filed http://quality.runrev.com/show_bug.cgi?id=14900 for custom bound computations (to allow widgets to paint in a region that overflows their rect).

[monte]

To support HitTest() will we have a command to work out the alpha of a specified point?

[LCMark]

@monte: Can you expand on any specific use-cases you have in mind?

We can certainly add a primitive to get the pixel color at a particular point in an image, and by extension of a canvas (you can create your own canvas and render to it as well as just to 'this canvas' in OnPaint - see the 'canvas' library example in the extensions/libraries folder in the github repo).

[monte]

I'm thinking that for objects with intricate edges that rather than calculate where the edge is it might be nice to hit test the alpha and if it's above a given threshold return true for the hit.

[LCMark]

@monte: Cool - that is what I thought you might be thinking, just thought I'd check though.

Once we've implemented OnHitTest (and added a little bit more canvas syntax!) you'll be able to do this in a couple of ways.

If your widget is using an image to define its shape, then you'll be able to fetch the alpha of a pixel in the image itself and use that to determine things. (Needs syntax)

If your widget is more complex, then you can create a 1x1 pixel canvas, translate appropriately and then ask the engine to render the widget into it. Then you can just test the alpha of that 1 pixel. (Needs syntax)

The only issue we might have here is that of efficiency - HitTest is called on every mouseMove so it has to be relatively quick (albeit at user interface speed) - but that will depend largely on the complexity of the widget's rendering. Further down the we might want to toy with the idea of a 'Shape' abstraction - each widget would have a 'Shape' which would be managed by the engine. You'd do something like 'reshape' to tell the engine its shape has changed, and then the engine will call an event handler to ask your widget to generate the shape. If you don't have that event handler, it would just call OnPaint and assume the shape was defined by the alpha of the resulting canvas.

[monte]

Hmm... @LCMark I had been thinking the drawn canvas might be something we could test but I just remembered @LCFraser saying the canvas only exists during OnPaint. Could we maintain a mask from the canvas as an instance variable?