on 5/03/2005 1:15 Pm, Mike Kluev at email@hidden wrote:
> on 2/03/2005 7:13 Pm, Eric Schlegel at email@hidden wrote:
>
>> On Mar 1, 2005, at 10:35 PM, Mike Kluev wrote:
>>
>> on 1/03/2005 9:23 Am, Eric Schlegel at email@hidden wrote:
>>
>>> On Mar 1, 2005, at 9:34 PM, Mike Kluev wrote:
>>>
>>>> When I programmatically resize tabs control that was created in
>>>> interface builder e.g. to make it smaller, I observe drawing
>>>> artifacts
>>>> on switching tabs (extra area outside tabs control is erased, tabs
>>>> themselves are getting erased and not updated properly) . Looks like
>>>> those userPanes created by IB runtime, corresponding to each tab pane
>>>> (aka "Tab Items" in IB user interface) are not resized appropriately.
>>>> Whose responsibility is it to resize those user panes (e.g. by means
>>>> of kEventControlBoundsChanged event installed on the tabs control
>>>> target), mine or IB runtime? If the latter I'll file a bug.
>>>
>>> Yours.
>>
>> Actually, maybe I should take this back. It looks like in the Panther
>> version of IBCarbonRunte, 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.
>
>>>> 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?
>>
>> 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.
>
> The sample app that demonstrates the bug is very simple (included
> with the bug):
I found a very simple workaround.
static void SwitchTabs(ControlRef tabs)
{
ControlRef pane;
UInt16 i, count;
SInt16 value;
OSStatus err;
value = GetControlValue(tabs);
err = CountSubControls(tabs, &count);
for (i = 1; i <= count; i++) {
err = GetIndexedSubControl(tabs, i, &pane);
if (i != value) {
SetControlVisibility(pane, false, false);
// HideControl(pane);
}
}
err = GetIndexedSubControl(tabs, value, &pane);
// ShowControl(pane);
SetControlVisibility(pane, true, false);
DrawOneControl(tabs);
}
_______________________________________________
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
