Re: Animated NSSplitView headache
Re: Animated NSSplitView headache
- Subject: Re: Animated NSSplitView headache
- From: Alvaro Costa Neto <email@hidden>
- Date: Fri, 10 Feb 2012 11:21:37 -0200
Hi Luc, how are you?
When the user drags the divider and collapses it, the split view retains the view's frames before the collapse and that's probably something that is giving you some problems. In this sense, there are two different behaviors going on when a collapse happen:
1) If the user drags the divider and collapses the subview, it's size will have the minimum allowed width/height and it's hidden property will become "TRUE";
2) If an animated collapse happens, the subview's frame will have zero width/height and it's hidden property will be also "TRUE" because you are hiding it when the collapse animation finishes.
To detect when the split view has manually collapsed one of it's subviews, watch via KVO the subview's "hidden" property. When it changes to "TRUE" and the subview's frame is not zero sized, it means the user collapsed by dragging the divider. If it becomes true and the subview's frame is zero sized, it means the collapse animation has finished.
One probable cause of headache is the uncollapse algorithm: before doing the uncollapse, always make sure that the collapsed subview's frame has zero width/height. This may not be true if the user has manually dragged the divider and collapsed the subview.
To finish it up, only reenable the autosize mechanisms when the subview has finished uncollapsing. This will prevent the autosize algorithms from calculating negative sized frames.
Hope that helps! Abraços,
Alvaro Costa Neto
Em 10/02/2012, às 07:53, Luc Van Bogaert escreveu:
> Hi,
>
> I'm really very close to having a working NSSplitView with animated "collapse" & "uncollapse" of the subviews, but there still is a problem when one of the subviews is first collapsed by dragging the divider over the subview's minimal size as controlled by the delegate.
>
> When I expand such a collapsed subview, the behavior I'm seeing is really unpredictable. The subview will be expanded and redrawn just fine for 10 or 20 consecutive times or so, but then all of a sudden the expand will fail. There *seems* to be a pattern that after the app is started, it either works fine, or it fails. When it works, it usually stays like that. But after a restart of the app, there's really no way I could predict the behavior.
>
> When it fails, it seems as if the autoresize mechanism in the expand view is not working correctly, and its subview extends beyond one side of the expanded view. After that, there's no way the layout 'restores' itself back to normal. When I close the app and restart, everything works fine again, or not…
>
> Because this is so unpredictable, I haven't been able to find the cause of the problem, and I'm hoping someone here has a suggestion on how to solve this problem. Maybe there's a problem with timing or synchronization, but I wouldn't know how to find out if there was. Maybe, I should somehow disable the layout mechanism during animation, and I've tried something in this area already, but so far without success. So, any suggestions would really be appreciated.
>
> As for my implementation: in general, prior to the animation, I'm disabling the split view delegate and the autoresizing of its subviews. I'm setting the target frames for both views, and then use the animator proxies. Afterwards, I'm restoring the delegate and the autoresizing behaviour back to their original values. Again, this all works if the subviews were not first collapsed by dragging the divider.
>
> --
> Luc Van Bogaert.
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden