On 3/12/05 8:15 AM, Mike Kluev didst favor us with:
>> 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.
This may just be a bug in IB. It wouldn't be the only Tab control bug in IB.
>> 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).
Yes, 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.
I don't know what you mean by "internal detail" in this case. The user panes
are a part of IB's tab control implementation.
>>> 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.
When you finish discussing this with yourself, file a bug. But with limited
engineering resources, bugs that only occur in older technologies aren't
going to get the highest priorities. It took me a while to accept it, but
things just aren't always going to be the way they should be in Mac OS X.
Older technologies which are "supported" but not "recommended" are often
going to get less than optimal attention.
>>> 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.
I've been reading this thread since the beginning, but haven't participated
because you have your e-mail system set up to bounce my messages for having
potentially offensive content (something I still consider childish on your
part, but oh well). But now that you're responding to yourself, in the hope
of ending this thread I'll ask, have you considered using the insets given
in the Apple Human Interface Guidelines for items in tab controls? Top: 10,
bottom: 18, sides: 16. And are you keeping the content of the tabs within
these guidelines?
(On an aside, are there separate interface guidelines for non-humans such as
Klingons, vampires, and Tok'ra? :-)
>>> Do you guys use something else to solve this drawing issue?
I suspect many people never see it, even in non-composited windows. Others
use composited windows where you say it isn't a problem. Many of us have
described a different approach to building tabs from nib windows which
doesn't use the tab control's built-in user panes.
>
> 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,
Thanks.
> 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.
It's unlikely that every Carbon application is experiencing this. Either
way, file a bug and attach a simple test case. While you're at it, file a
separate request in Radar for kThemeMetricTabContentInsetLeft,
kThemeMetricTabContentInsetRight, kThemeMetricTabContentInsetBottom, and
kThemeMetricTabContentInsetTop constants and another bug against the lack of
specific documentation about the correct insets.
Larry
_______________________________________________
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
