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):
// The nib is for this test is very simple:
// Name: "Nib.nib"
// Single window in Nib "Window". non compositing.
// Single item in that window - Tabs control
// with at least two panes.
// Signature = CommandID = 'Tabs'
// ID = 0
//
// Uncomment SizeControl below to see what happens on resize
#include <Carbon.h>
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) HideControl(pane);
}
err = GetIndexedSubControl(tabs, value, &pane);
ShowControl(pane);
}
static const EventTypeSpec _tabsEvents[] = {
{ kEventClassCommand, kEventCommandProcess }
};
static pascal OSStatus TabsHandler(EventHandlerCallRef callRef,
EventRef event, void *tabs)
{
HICommand hiCommand;
OSStatus err;
err = GetEventParameter(event, kEventParamDirectObject,
typeHICommand, NULL, sizeof(hiCommand), NULL, &hiCommand);
if (hiCommand.commandID == 'Tabs') SwitchTabs((ControlRef)tabs);
return eventNotHandledErr;
}
int main(void)
{
IBNibRef nibRef;
WindowRef window;
ControlRef tabs;
OSStatus err;
Rect r;
const ControlID kTabsID = { 'Tabs', 0 };
err = CreateNibReference(CFSTR("Nib"), &nibRef);
err = CreateWindowFromNib(nibRef, CFSTR("Window"), &window);
err = GetControlByID(window, &kTabsID, &tabs);
err = InstallEventHandler(GetControlEventTarget(tabs),
NewEventHandlerUPP(TabsHandler), GetEventTypeCount(_tabsEvents),
_tabsEvents, tabs, NULL);
SwitchTabs(tabs);
// Uncomment to see what happens on resize
//
// GetControlBounds(tabs, &r);
// SizeControl(tabs, (r.right - r.left)*0.9, (r.bottom - r.top)*1.1);
ShowWindow(window);
RunApplicationEventLoop();
return 0;
}
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
