Sizing strangeness in the land of NSDrawer
-
Hello list denizens.
I've just created some UI with an NSDrawer attached to a regular
window. I've done this before a while back and everything worked
fine. I thought everything was fine this time too: the drawer opens
on command, has the correct initial size, and behaves mostly normally
except when I try to resize the main window (with the drawer open).
The main window resizes just fine, but leaves the drawer exactly where
is was (i.e. no effect on its size or position - i.e. because it is on
the RHS of the window, it is left as an island if the window is made
smaller horizontally, and covered up if the window is made bigger.
When the window is resized (for instance, leaving the drawer
isolated), it will move the drawer (as an island at a fixed offset)
around with it when subsequently moved. If you grab the draw to
resize it (i.e. pull it 'out' further by the right hand edge), it will
suddenly snap back to where it should be on the right side of the
window.
The NSDrawer appears to have everything it needs, but there most be
something internally preventing the parent window's resizing from
getting propagated (... or something).
I have no delegate set on the NSDrawer, only contentView and
parentView outlets are connected and working. I just want default
sizing behaviour, so don't have a need for the delegate notification
(and assume everything should default without it). I do have some
minimum size constraints set on the NSDrawer object (set in IB 3), and
these are reasonable and correctly adhered to when the drawer is
opened and used.
My Main Window is not (to my knowledge) special. There ought to be
nothing that prevents normal messages going about their business -
it's just a regular NSView hierachy. I am using Core Animation layers
in the hierarchy, and have a few sibling views therein deliberately
overlapping others (causing a warning in IB). Could it be that some
issue propagating subview resizing in the Main Window would somehow
prevent continuous resize messages from reaching the drawer's outer
window? That seems like a non-sequitur as the main window ought to be
able to separately indicate its outer frame size changes to the
drawer, irrespective of what is going on within its bounds.
Anyway, I'm stumped (for the moment) and thought I'd fish on the list
for ideas!
-- Lwe -
Turn on garbage collection and see if it starts working.
-Steve
On Oct 25, 2008, at 9:06 PM, Luke Evans wrote:> Hello list denizens.
>
> I've just created some UI with an NSDrawer attached to a regular
> window. I've done this before a while back and everything worked
> fine. I thought everything was fine this time too: the drawer opens
> on command, has the correct initial size, and behaves mostly
> normally except when I try to resize the main window (with the
> drawer open). The main window resizes just fine, but leaves the
> drawer exactly where is was (i.e. no effect on its size or position
> - i.e. because it is on the RHS of the window, it is left as an
> island if the window is made smaller horizontally, and covered up if
> the window is made bigger. When the window is resized (for
> instance, leaving the drawer isolated), it will move the drawer (as
> an island at a fixed offset) around with it when subsequently
> moved. If you grab the draw to resize it (i.e. pull it 'out'
> further by the right hand edge), it will suddenly snap back to where
> it should be on the right side of the window.
>
> The NSDrawer appears to have everything it needs, but there most be
> something internally preventing the parent window's resizing from
> getting propagated (... or something).
>
> I have no delegate set on the NSDrawer, only contentView and
> parentView outlets are connected and working. I just want default
> sizing behaviour, so don't have a need for the delegate notification
> (and assume everything should default without it). I do have some
> minimum size constraints set on the NSDrawer object (set in IB 3),
> and these are reasonable and correctly adhered to when the drawer is
> opened and used.
>
> My Main Window is not (to my knowledge) special. There ought to be
> nothing that prevents normal messages going about their business -
> it's just a regular NSView hierachy. I am using Core Animation
> layers in the hierarchy, and have a few sibling views therein
> deliberately overlapping others (causing a warning in IB). Could it
> be that some issue propagating subview resizing in the Main Window
> would somehow prevent continuous resize messages from reaching the
> drawer's outer window? That seems like a non-sequitur as the main
> window ought to be able to separately indicate its outer frame size
> changes to the drawer, irrespective of what is going on within its
> bounds.
>
> Anyway, I'm stumped (for the moment) and thought I'd fish on the
> list for ideas!
>
> -- Lwe -
Typo, I meant.... turn off garbage collection and see if it starts
working.
oops....
-Steve
On Oct 25, 2008, at 9:06 PM, Luke Evans wrote:> Hello list denizens.
>
> I've just created some UI with an NSDrawer attached to a regular
> window. I've done this before a while back and everything worked
> fine. I thought everything was fine this time too: the drawer opens
> on command, has the correct initial size, and behaves mostly
> normally except when I try to resize the main window (with the
> drawer open). The main window resizes just fine, but leaves the
> drawer exactly where is was (i.e. no effect on its size or position
> - i.e. because it is on the RHS of the window, it is left as an
> island if the window is made smaller horizontally, and covered up if
> the window is made bigger. When the window is resized (for
> instance, leaving the drawer isolated), it will move the drawer (as
> an island at a fixed offset) around with it when subsequently
> moved. If you grab the draw to resize it (i.e. pull it 'out'
> further by the right hand edge), it will suddenly snap back to where
> it should be on the right side of the window.
>
> The NSDrawer appears to have everything it needs, but there most be
> something internally preventing the parent window's resizing from
> getting propagated (... or something).
>
> I have no delegate set on the NSDrawer, only contentView and
> parentView outlets are connected and working. I just want default
> sizing behaviour, so don't have a need for the delegate notification
> (and assume everything should default without it). I do have some
> minimum size constraints set on the NSDrawer object (set in IB 3),
> and these are reasonable and correctly adhered to when the drawer is
> opened and used.
>
> My Main Window is not (to my knowledge) special. There ought to be
> nothing that prevents normal messages going about their business -
> it's just a regular NSView hierachy. I am using Core Animation
> layers in the hierarchy, and have a few sibling views therein
> deliberately overlapping others (causing a warning in IB). Could it
> be that some issue propagating subview resizing in the Main Window
> would somehow prevent continuous resize messages from reaching the
> drawer's outer window? That seems like a non-sequitur as the main
> window ought to be able to separately indicate its outer frame size
> changes to the drawer, irrespective of what is going on within its
> bounds.
>
> Anyway, I'm stumped (for the moment) and thought I'd fish on the
> list for ideas!
>
> -- Lwe -
Hi Steve,
Thanks for the reply.
Ouch, yes, you're right, it works perfectly with GC turned off, and
misbehaves with "Required" or "Supported".
This will be a major bummer if there's no workaround (I guess it will
be bye-bye NSDrawer).
So the obvious next question: is there a work around, or was I always
supposed to be doing something special to make this work at all
(though that doesn't seem right to me)?
-- Lwe
On 25-Oct-08, at 6:47 PM, Steven Riggs wrote:> Typo, I meant.... turn off garbage collection and see if it starts
> working.
>
> oops....
> -Steve
>
> On Oct 25, 2008, at 9:06 PM, Luke Evans wrote:
>
>> Hello list denizens.
>>
>> I've just created some UI with an NSDrawer attached to a regular
>> window. I've done this before a while back and everything worked
>> fine. I thought everything was fine this time too: the drawer
>> opens on command, has the correct initial size, and behaves mostly
>> normally except when I try to resize the main window (with the
>> drawer open). The main window resizes just fine, but leaves the
>> drawer exactly where is was (i.e. no effect on its size or position
>> - i.e. because it is on the RHS of the window, it is left as an
>> island if the window is made smaller horizontally, and covered up
>> if the window is made bigger. When the window is resized (for
>> instance, leaving the drawer isolated), it will move the drawer (as
>> an island at a fixed offset) around with it when subsequently
>> moved. If you grab the draw to resize it (i.e. pull it 'out'
>> further by the right hand edge), it will suddenly snap back to
>> where it should be on the right side of the window.
>>
>> The NSDrawer appears to have everything it needs, but there most be
>> something internally preventing the parent window's resizing from
>> getting propagated (... or something).
>>
>> I have no delegate set on the NSDrawer, only contentView and
>> parentView outlets are connected and working. I just want default
>> sizing behaviour, so don't have a need for the delegate
>> notification (and assume everything should default without it). I
>> do have some minimum size constraints set on the NSDrawer object
>> (set in IB 3), and these are reasonable and correctly adhered to
>> when the drawer is opened and used.
>>
>> My Main Window is not (to my knowledge) special. There ought to be
>> nothing that prevents normal messages going about their business -
>> it's just a regular NSView hierachy. I am using Core Animation
>> layers in the hierarchy, and have a few sibling views therein
>> deliberately overlapping others (causing a warning in IB). Could
>> it be that some issue propagating subview resizing in the Main
>> Window would somehow prevent continuous resize messages from
>> reaching the drawer's outer window? That seems like a non-sequitur
>> as the main window ought to be able to separately indicate its
>> outer frame size changes to the drawer, irrespective of what is
>> going on within its bounds.
>>
>> Anyway, I'm stumped (for the moment) and thought I'd fish on the
>> list for ideas!
>>
>> -- Lwe
>
>
