1. Posted by meorawr on Sat, 25 Jun 2011 23:14:20

    I found some interestingly weird behaviour when playing around with ScrollFrame elements earlier, which causes child frames with mouse input enabled to fire their events even if the mouse isn't actually over them.

    The issue crops up when you're using a ScrollFrame inside of a ScrollFrame, and can be replicated with the below code examples.

    This example shows the issue, it creates the following frame heirarchy; ScrollFrame > Frame (set as ScrollChild) > ScrollFrame > Frame (ScrollChild) > Buttons (x100).

    The issue is that all of the mouse related events for the 100 buttons will fire if you mouseover them even if they're not showing because they're obscured/hidden due to not being within the visible region of the second ScrollFrame - so for example moving your mouse around just underneath the boundaries of the second ScrollFrame will fire events for the buttons despite them not showing. If that's still confusing, this screenshot shows that my chat frame printed "Entered 9" even though button 9 isn't visible.

    At first I thought I had something wrong in my own code but the issue seems to then completely disappear if you simply remove the first ScrollFrame and use this code instead.

    I'm pretty sure this is an API bug, but I'm just wondering if anyone else knows of this and, hopefully, has a workaround or a rather large stick to hit me over the head with to say "you forgot to do x!!!" :)

    Edit: And if you're wondering why I would ever want nested ScrollFrames, the issue cropped up because I have a configuration GUI set up inside of a ScrollFrame which has a custom Dropdown widget - The list of items on that Dropdown uses a ScrollFrame to prevent a super long list.

  2. Posted by jnwhiteh on Sun, 26 Jun 2011 08:56:57

    I'm really not sure, to be honest. I'll se if I can figure something out.

  3. Posted by meorawr on Sun, 26 Jun 2011 20:04:33

    Yeah, I hate using ScrollFrames in general. They seem to be an overcomplicated way of doing things, as opposed to just implementing a SetClippingRect function onto frames in general.

    I'll probably rewrite the Dropdown code to not use a ScrollFrame to avoid the issue, going to see if it's still present on the 4.2 client though once it copies to the right drive and patches up.

    Edit: Yeah, issue still there in 4.2.