Bwalkin BWToolkit → 1.2.5

Comments and changes to this ticket

• 

  Brandon Walkin August 28th, 2009 @ 01:57 AM

  • State changed from “new” to “accepted”

  I think this issue has to do with the Anchored Button Bar setting itself as the Split View's delegate.

• 

  Brandon Walkin August 30th, 2009 @ 01:04 AM

  Attaching a screenshot of a duplicate issue from the old issue tracker.

  • Unprocessed: bwalkin_-_BWToolkit_-_issues_-_BWSplitView_with_BWAnchoredButtonBar_Ignores_SubView_Size_Limits_.png 419.6 KB
• 

  Brandon Walkin August 30th, 2009 @ 01:09 AM

  • Title changed from “Splitview's subview min/max ignored if autosizing disabled” to “Split View with Anchored Button Bar ignores min / max when autosizing is disabled”
• 

  Brandon Walkin October 3rd, 2009 @ 05:06 PM

  • Title changed from “Split View with Anchored Button Bar ignores min / max when autosizing is disabled” to “Split view with anchored button bar ignores min / max settings”
• 

  Brandon Walkin October 18th, 2009 @ 01:49 AM

  • State changed from “accepted” to “highpriority”
  • Milestone set to “1.2.5”

• You flagged this item as spam.
  

  Jacob Gorban October 28th, 2009 @ 04:33 AM

  I've found several reasons why this happens and again I have succeeded to fix it for my program's case but I must say that I find that your current architecture is somewhat flawed which prohibits easy solution. Plus there's a bug or maybe an unfinished feature there. I just don't know the code's history.

  First, in the Anchored Button Bar class there's an ivar for a delegate. I assume you wanted it to be the original delegate of the BWSplitView. You use this delegate in every NSSplitView delegate methods that you implement. But, not once do you actually set any value to this ivar. Thus, it's always nil and all delegate methods that you implement return default values and ignore any real delegates that the split view might have.

  I've tried setting it to BWSplitView's delegate but this creates an infinite loop since it's the BWSplitView itself, which calls for it's second delegate, which is the button bar which again calls the SplitView etc.

  I think you wanted to use the second delegate so I said I'll take the second delegate of BWSplitView before Anchored Button bar registers itself as the second delegate, so the delegate methods can be transferred from SplitView through Button bar into the developer's external custom delegate methods.

  Yet, this didn't help with this bug at all. The reason, as I said, looks like a difficult one to solve. Since Button Bar puts itself as the (second) delegate of BWSplitView and implements ALL delegate methods, the default implementation of BWSplitView for the same delegates methods (like setting the min and max values) of BWSplitView are not used. Instead they are forwarded to the Anchor Bar, which tries to forward it yet again to another delegate (which in your case even isn't set) and then simply returns the proposed value (proposed by NSSplitView, not BWSplitView).

  Now that I think of it some more, maybe you should transfer the proposed value as BWSplitView would propose it and not how NSSplitView proposes. Meaning, first to let BWSplitView calculate it's limits and then forward it to Anchor Button Bar, which will return it back.

  Currently, in my application I simply removed all but one delegate methods of Button Bar (which registers the dragging Rect) since I don't use any custom delegates. In this case, BWSplitView doesn’t forward all the other methods and returns its own calculation, so I have Min/Max and dragging anchor.

  I hope this helps you to develop a general working solution for this problem.

• 

  Brandon Walkin October 28th, 2009 @ 04:46 AM

  I think I might just special case BWAnchoredButtonBar delegates of the split view so they only get called for drag handle rects.

• You flagged this item as spam.
  

  Jacob Gorban October 28th, 2009 @ 05:01 AM

  I think I might just special case BWAnchoredButtonBar delegates of the split view so they only get called for drag handle rects.

  This also could be a solution.

  Yet you still need a way to forward all other delegate methods to the developer's delegate object.
  But you've already lost it as NSSplitView's delegate is BWSplitView itself and second delegate is now Anchor Button Bar.
  Looks like you either need a third delegate or create communication between button bar and split view using other, new methods, which are not of the regular delegate chain and not set button bar as split view's delegate in the first place.

• 

  Brandon Walkin November 4th, 2009 @ 04:54 AM

  • State changed from “highpriority” to “fixcommitted”

  Fixed by special casing BWAnchoredButtonBar. This solution should work for almost everyone since developers will generally not need to override the particular delegate calls that the split view doesn't send to the button bar's delegate. Most of that functionality is available in the BWSplitView inspector.

  http://bitbucket.org/bwalkin/bwtoolkit/changeset/f164b18c9667/

• 

  Brandon Walkin June 4th, 2010 @ 12:45 PM

  • State changed from “fixcommitted” to “fixreleased”

  [bulk edit]