Re: nested grps and controls: how to get what you expect to
Posted: Thu Apr 13, 2017 7:31 pm
The screenshot helps, thanks. I'm not sure why you're getting that behavior except that same-named controls have always produced unexpected results. Logically I'd expect consistency so it does look like a bug in a way, but the easiest solution is not to use same-named controls. The engine uses a complex path to identify a target and something in this setup is causing the engine to take a detour.
By the way, a recent posting to the mailing list from Mark Waddingham says that hit testing is done "front to back" (which is what I'd expect) and implies top layers are tested first, followed by lower layers. Klaus' test seems to show otherwise, so there may be a difference between hit testing (clicks) and script references. That doesn't sound right though.
By the way, a recent posting to the mailing list from Mark Waddingham says that hit testing is done "front to back" (which is what I'd expect) and implies top layers are tested first, followed by lower layers. Klaus' test seems to show otherwise, so there may be a difference between hit testing (clicks) and script references. That doesn't sound right though.
Rendering requires a linear back to front scan of each control, painting each one which is within the visible rect of the window the card sits in.
<snip>
Hit testing is similar, although the process is from front to back, and stops as soon as a control says it is the target of the mouse / user interaction event.