I have been trying to solve a nasty problem with the multiline text widget in AceGUI-3.0. The problem is that the clickable area for the editbox seems to extend outside of the viewable area. This causes several issues. The worst is that if you click on something below or above the editbox, the editbox actually receives this mouse click and reacts accordingly (causing cursor position to be changed, scrolling occurs, and oddly enough part of the text gets selected).
I believe I've nailed the issue down to a more general problem with scroll-frames nested within other scroll-frames. This is unfortunately quite common in a generic UI like AceConfigDialog. I've attached a test program that shows the problem quite visually. Take a look at the screenshots below from the test program. The green and red areas are debugging frames positioned on top of the outer container and the inner editbox - both of which are scrollchilds of a scrollframe.
The first screenshot shows the editbox scrolled to the center such that the entire contents fits within the outer container. You will notice from this and the other screenshots that the editbox is in fact as high it needs to be to hold all of its content. I guess the scrollframe takes care of only showing the part that's inside the viewable area.
Next screenshots shows the editbox scrolled to the top. Notice how it invisibly extends below the scrollframe. Also notice that the lower scrollbutton in the outer scrollframe is now active.
This becomes even more evident when you now try to scroll the outer area. This should not be possible since the viewable area of the inner scrollframe fits fully within the outer scrollframe. Alas, it seems the outer scrollframe considers all of the editbox when computing the size of its scrollchild.
The last screenshot shows a similar situation but with the editbox scrolled to the bottom.
It seems like a clear bug with nested scrollframes. Does anyone have any insight into this? In particular, I'd love to find a workaround. I fear that multiline editboxes simply aren't feasible in AceConfigDialog if no workaround is found. :(
Alright, as promised, I looked at it. I found no workarounds. This is because when an <EditBox> has the multiline property set to true, it always auto resizes itself to the maximum height (this part is irrelevant of scrollframes). Now throw in the fact that a <ScrollFrame> will always :ClearAllPoints() and then :SetPoint("TOPLEFT", offsetx, offsety) its scrollchild whenever a scrollchild changes or you scroll something, you end up with the behavior in the test addon. - Yes you can check the values, it cleared my setpoints.
Thanks for confirming. I think it's important to note two things.
First, the bug is not actually restricted to editboxes. Try changing the editbox to a regular frame and give it an appropriate height larger than the viewable area. It shows the exact same behaviour.
Second, it is not only a visual problem. The part of the inner scrollchild that overlaps with the outer visible scroll area also receives mouse events. That is the really problematic that I've been struggling to solve. It has some really nasty effects since you are clicking something that shouldn't really be there so to speak.
The problem with the scrollframe resizing to fit the scrolled editbox can be worked around, I don't use the blizzard scrollframe templates for the AceGUI scrolling, only for the scroll bars themselves. Managing the size of the scrollchild and the range of scrolling can be done yourself to have better control.
For the problem of the editbox getting mouse events outside the scroll frame, does an EditBox obey :SetHitRectInsets() ? It might be a way to manage which part of the editbox is clickable ourselves if scrollframes aren't fixed. I can't test from here but will when I get home if noone else has.
AFAIK, a multiline editbox doesn't respect the SetHeight() method at all. So I think it will be difficult to control the scrolling yourself that way. I tried using SetHitRectInsets() but didn't notice any effects from that either.