On 11/03/2005 09:42 Pm, David McLeod <email@hidden> wrote:
> On Mar 5, 2005, at 2:15 AM, Mike Kluev wrote:
>> on 2/03/2005 7:13 Pm, Eric Schlegel at email@hidden wrote:
>>> Actually, maybe I should take this back. It looks like in the Panther
>>> version of IBCarbonRuntime, we use an HILayout to set up the user
>>> panes so they automatically resize to match the tab control. If that's
>>> not working, then you should definitely file a bug about it.
>>
>> I verified control bounds of those user panes (aka in IB as "Tab
>> Items"). The bounds are not updated when tabs control resized.
>>
>>> I don't know if we even have a bug about this. It does sound like
>>> a bug to me, so you should probably file it.
>>
>> I've tried it on 10.3.7 (7S215). The drawing glitch (even without
>> resizing tabs control) is reproducible with non compositing window
>> but it is not reproducible with compositing window. The bounds of
>> user panes are not updated in either case (as you said they should;
>> but given that it works correctly with compositing window, should
>> they really?).
>>
>> rdar://4038088.
>
> HILayouts don't operate in non-composited windows.
Looks like you imply those userpanes should be resized in composited
window. They are not on 7S215, but everything works correctly in
composited window...
> Eric's original
> post is correct. You need to take care of resizing the user panes in
> your non-composited windows.
Even if I do not resize tab control? Not so good.
Why should the size of userpane (that supposedly doesn't draw
itself) matter here at all? I understand that it might clip its
subcontrols if too small, but why can't it be set to something
like <-10000, -10000, +10000, +10000> and never change?
> Unfortunately, the IB runtime might
> still be installing HILayouts in the non-composited case with
> possible uncertain results. We need to look into that.
Thanks.
I still not sure how to best deal with it. In particular if to
go the "resize it yourself" route what insets should I use and
should I hardcode them (see below).
>> Thanks. I was frightened to mess with those internal user panes
>> whose existence in itself is uncertain, because it is implementation
>> detail of IB runtime.
My view on this is that it is not ok to depend on internal
detail like this unless we know it won't change.
>>> BTW, even if I *do not* resize tabs control, it still has some minor
>>> drawing artifacts on switching tabs, presumably due to the same issue:
>>> those userpanes sizes match the size of tab control itself, so when
>>> the user pane is erased it wipes that nice rounded tab frame (left
>>> right and bottom sides of tabs control frame are affected).
>>
>> So even if I do not resize tabs control it is not considered a bug
>> that tabs control is not drawn correctly right out of the box?
While someone would say it is just another reason to use compositing,
it still looks a bug for me.
>> OK, what should be correct rectangle for that IB runtime's user
>> item? If I do this, what should be correct inset values?
>>
>> GetControlBounds(tab, &r);
>> r.top += topInset;
>> r.bottom -= bottomInset;
>> r.left += leftInset;
>> r.right -= rightInset;
>> SetControlBounds(all those user panes of tab, &r);
>>
>> Experiments show that left/right/bottom insets should be 2, though
>> I am not sure if it is ok to hardcode this and if that could be
>> changed in future OS version. Should I calculate insets based on
>> some GetThemeMetric?
Still don't know.
>> Do you guys use something else to solve this drawing issue?
Maybe to re-embed all sub control directly into tab control itself
and get rid of those userpanes? Or issue DrawOneControl call every
now and then trying to fix it? I'll repeat myself, but drawing glitch
happens even if you don't resize tab control, so this should affect
all Carbon apps that use IB's tab control in non composited window.
Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
This email sent to email@hidden
