A modest proposal for a new property

[Richard Gaskin]

For many images with alpha layers the returned values would be a complex 
set of points, and for some discontiguous.

If the purpose for obtaining that collection of points is to determine 
whether a click at a specific location would be inside or outside the 
control's region(s), that would require a lot of calculations, taking 
non-trivial development time to write and a fair bit of CPU time to 
execute in script.

It may be simpler and more efficient to let the engine do that 
calculation using existing functions built into the engine.

See the Dictionary entries for:

- "within" function - describes how the clickable region is calculated
    and will serve the majority of use-cases well.

- "intersect" function - which goes further to allow the scripter to
    optionally define an alpha channel threshold.

-- 
  Richard Gaskin
  Fourth World Systems


Quentin Long wrote:

> In the past few List digests, there's been some discussion of practical issues regarding when a click does or doesn't count as clicking *on* a particular item. So, here's a proposed addition to LiveCode…
> 
> =============
> 
> Name: clickableRegion
> 
> Recognized abbreviation: clickReg
> 
> "clickableRegion" is a proposed property of anything in a stack that might a user might reasonably be expected to click on—controls, that is. We're talking buttons, fields, graphics, images, yada yada yada.
> 
> The clickableRegion of a control is a return-delimited list of points that define a region of the screen. Since clickableRegion is a property of a control, the engine's internal representation of these points should probably use the location of the control as the origin (the 0,0 point) for the clickableRegion's points.
> 
> Any click whose clickLoc is within the area defined by a control's clickableRegion, will be treated by the engine as if it were a click on that control.
> 
> The default value of a control's clickableRegion should be determined by that control's visible-on-screen pixels—for fields, this should be the field's rectangle; for graphics, this should be the points of the graphic; and so on and so forth.
> 
> The clickableRegion property should be both get-able and set-able. If you clear the clickableRegion (such as by setting it to ""), it should revert back to its default value.
> 
> Since clickableRegion can be set to arbitrary values, it may well happen that 2 or more controls have overlapping clickableRegions. This may not be a problem if the engine can simply make use of whatever magic it does when it handles clickLocs which fall within the rects of 2+ overlapping buttons. If the engine's existing 'click-disambiguation' machinery does not suffice to determine which control an ambiguous click is meant for, go with the control that has the highest-value layer property.
> 
> =============
> 
> Thoughts/comments/complaints?