NSViewController subclass return type
Hi all, Is there an appropriate way to subclass NSViewController to return a custom view class or is casting the return of view or loadView the only way? Is it even worth using on OS X since there are so few built in methods? Is it more practical to just load views from nibs without NSViewController? thanks, John ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSViewController subclass return type
On Jul 10, 2013, at 11:18 PM, dangerwillrobinsondan...@gmail.com wrote: Hi all, Is there an appropriate way to subclass NSViewController to return a custom view class or is casting the return of view or loadView the only way? I'm not following here. It's generally bad form to override a method for the sole purpose of changing its return type. Just cast the returned value got the appropriate type. Is it even worth using on OS X since there are so few built in methods? Is it more practical to just load views from nibs without NSViewController? NSViewController does correct memory management of all top level object in the job, including breaking retain cycles caused by Cocoa Bindings. It's also an NSResponder subclass, though it doesn't get inserted into the responder chain automatically. If you'd like to see NSViewController become more than marginally useful, please file Radars. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSViewController subclass return type
On Jul 10, 2013, at 23:18 , dangerwillrobinsondan...@gmail.com wrote: Is there an appropriate way to subclass NSViewController to return a custom view class or is casting the return of view or loadView the only way? You can just re-declare the 'view' property in a subclass to have the desired return type. In the implementation, you can provide an override that simply calls super, or you can cheat slightly by using '@dynamic view' in the subclass to make it use the superclass implementation. Is it even worth using on OS X since there are so few built in methods? Is it more practical to just load views from nibs without NSViewController? There's not a lot in it, but NSViewController has code for managing ownership of the top-level view objects, it has a convenient 'representedObject' property, and of course it implements 'loadView'. It's probably worth using even for these minor benefits. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSViewController subclass return type
On Jul 11, 2013, at 8:27 AM, Quincey Morris quinceymor...@rivergatesoftware.com wrote: On Jul 10, 2013, at 23:18 , dangerwillrobinsondan...@gmail.com wrote: Is there an appropriate way to subclass NSViewController to return a custom view class or is casting the return of view or loadView the only way? You can just re-declare the 'view' property in a subclass to have the desired return type. In the implementation, you can provide an override that simply calls super, or you can cheat slightly by using '@dynamic view' in the subclass to make it use the superclass implementation. Except that view is a read/write property, and this is a type error, because of this situation: UIVCSubclass *s = [[UIVCSubclass alloc] init...]; UIViewController *vc = s; [vc setView:[[[UIView alloc] init] autorelease]; Tom Davie ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSViewController subclass return type
On Jul 10, 2013, at 11:26 PM, Kyle Sluder wrote:
On Jul 10, 2013, at 11:18 PM, dangerwillrobinsondan...@gmail.com wrote:
Hi all,
Is there an appropriate way to subclass NSViewController to return a custom
view class or is casting the return of view or loadView the only way?
I'm not following here. It's generally bad form to override a method for the
sole purpose of changing its return type. Just cast the returned value got
the appropriate type.
What I do a lot, in my own classes and NSFoo subclasses, is this pattern.
- (MyView *)myView
{
return (MyView *)[self view]
}
and an assert that it really is the right type is useful too.
Is it even worth using on OS X since there are so few built in methods? Is
it more practical to just load views from nibs without NSViewController?
NSViewController does correct memory management of all top level object in
the job, including breaking retain cycles caused by Cocoa Bindings. It's also
an NSResponder subclass, though it doesn't get inserted into the responder
chain automatically.
Yes. Life is *so much simpler* when you let the Cocoa code handle nib memory
management. The code we tossed when NSViewController came along was not pretty.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: NSViewController subclass return type
On Jul 10, 2013, at 23:26 , Kyle Sluder k...@ksluder.com wrote: It's generally bad form to override a method for the sole purpose of changing its return type. Just cast the returned value got the appropriate type. The trouble is that a cast is (generally) a bug waiting to happen, because it masks the type being cast from. There's really no unobjectionable solution, so it's a matter of preference which good form gets violated. On Jul 10, 2013, at 23:58 , Tom Davie tom.da...@gmail.com wrote: Except that view is a read/write property, and this is a type error, because of this situation: UIVCSubclass *s = [[UIVCSubclass alloc] init...]; UIViewController *vc = s; [vc setView:[[[UIView alloc] init] autorelease]; It's not a practical problem for NSViewController, because the view is normally only set at loading time, and there's no verification of the view class at that time anyway. In the unlikely event that code like this needed to exist, then it would make sense to override the view property setter and check the view class at runtime. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSViewController subclass return type
On Jul 11, 2013, at 4:50 PM, Lee Ann Rucker lruc...@vmware.com wrote:
On Jul 10, 2013, at 11:26 PM, Kyle Sluder wrote:
On Jul 10, 2013, at 11:18 PM, dangerwillrobinsondan...@gmail.com wrote:
Hi all,
Is there an appropriate way to subclass NSViewController to return a custom
view class or is casting the return of view or loadView the only way?
I'm not following here. It's generally bad form to override a method for the
sole purpose of changing its return type. Just cast the returned value got
the appropriate type.
What I do a lot, in my own classes and NSFoo subclasses, is this pattern.
- (MyView *)myView
{
return (MyView *)[self view]
}
and an assert that it really is the right type is useful too.
So does it matter that the IBOutlet private ivar of NSViewController is NSView*
?
Is it even worth using on OS X since there are so few built in methods? Is
it more practical to just load views from nibs without NSViewController?
NSViewController does correct memory management of all top level object in
the job, including breaking retain cycles caused by Cocoa Bindings. It's
also an NSResponder subclass, though it doesn't get inserted into the
responder chain automatically.
Yes. Life is *so much simpler* when you let the Cocoa code handle nib memory
management. The code we tossed when NSViewController came along was not
pretty.
No doubt the memory management wit this would be a PITA.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: NSViewController subclass return type
So does it matter that the IBOutlet private ivar of NSViewController is
NSView* ?
Not if MyView is a subclass of NSView, and I only bother with the myView
accessor if I specifically need to reference MyView methods.
- Original Message -
From: dangerwillrobinsondan...@gmail.com
To: Lee Ann Rucker lruc...@vmware.com
Cc: Kyle Sluder k...@ksluder.com, List Developer Cocoa
cocoa-dev@lists.apple.com
Sent: Thursday, July 11, 2013 1:33:13 AM
Subject: Re: NSViewController subclass return type
On Jul 11, 2013, at 4:50 PM, Lee Ann Rucker lruc...@vmware.com wrote:
On Jul 10, 2013, at 11:26 PM, Kyle Sluder wrote:
On Jul 10, 2013, at 11:18 PM, dangerwillrobinsondan...@gmail.com wrote:
Hi all,
Is there an appropriate way to subclass NSViewController to return a custom
view class or is casting the return of view or loadView the only way?
I'm not following here. It's generally bad form to override a method for the
sole purpose of changing its return type. Just cast the returned value got
the appropriate type.
What I do a lot, in my own classes and NSFoo subclasses, is this pattern.
- (MyView *)myView
{
return (MyView *)[self view]
}
and an assert that it really is the right type is useful too.
So does it matter that the IBOutlet private ivar of NSViewController is NSView*
?
Is it even worth using on OS X since there are so few built in methods? Is
it more practical to just load views from nibs without NSViewController?
NSViewController does correct memory management of all top level object in
the job, including breaking retain cycles caused by Cocoa Bindings. It's
also an NSResponder subclass, though it doesn't get inserted into the
responder chain automatically.
Yes. Life is *so much simpler* when you let the Cocoa code handle nib memory
management. The code we tossed when NSViewController came along was not
pretty.
No doubt the memory management wit this would be a PITA
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Custom drag image for NSTableView selections
NSTableView seems to limit the drag image for selected rows to the selected rows that are currently visible in the clip view. Am I correct that I will need to subclass NSTableView in order to do anything different? I want to display a drag image that shows some representation of all the selected rows. Granted I will need to also do some handling of excessively large number of selected rows and make some visual indication in that is more than can reasonably be displayed. Happy to hear any guidance on this from anybody who has implemented something similar before. (Caveats and gotchas please ) Thanks John Joyce ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSTextField: edits are committed even when -control:isValidObject: returns NO
Good morning, I'm trying to implement some input validation on an NSTextField using NSControlTextEditingDelegate's -control:isValidObject: method -- simple stuff like validating that the entered text is parsable as a number, falls within a certain range, etc. (I know that NSNumberFormatter is the obvious choice for this scenario, but I'm working with requirements that require more low-level customizability, particularly in the content of the error message and how it is presented to the user, than NSNumberFormatter allows.) I've got things generally working; the delegate method gets called, I validate the user's entry and return NO if it is invalid, and the text field remains first responder. The obstacle I've encountered is that in some cases my text field is a subordinate control that is enabled/disabled based on a checkbox elsewhere in my view. If the user enters something invalid and attempts to commit the edit by pressing tab/enter/return, I validate and display the error message and the text field remains first responder, as desired. However, if the user then unchecks the controlling checkbox -- causing the text field to be disabled via -setEnabled:NO in my view controller -- the text field is disabled but it keeps the invalid text. At this point, the user has successfully circumvented my input validation; they can just re-check the checkbox and the text field is reenabled containing the invalid text. Worse, if the user puts key focus in the NSTextField again but does not make any edits and then tabs out, the validation is not triggered because there are no pending edits. I do note that if the user enters invalid text but does not attempt to commit the edit and then unchecks the checkbox, the NSTextField is disabled and the text reverts back to what it was before the user made their edit. It seems that even though I'm returning NO from -control:isValidObject:, the edit is still 'committed' from the field editor to the NSTextField. What I want is for the text field to revert back to the previous valid entry upon unchecking the box, even after the user attempts to commit the invalid edit and is presented with an error message. So, it sounds like -control:isValidObject: might be too late in the pipeline to validate and prevent the edit from being committed in the first place. Any suggestions for an earlier point to hook in my validation? I did try -control:textShouldEndEditing:, but still see the same behavior. Or, a different approach to accomplish what I'm after? Thanks! ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Can't keep disabled UIBarButtonItem text white
Hmmm. Okay, thinking out loud here. I presume that the only significant difference between implementing these UIBarButtonItems initially and the remove/re-add sequences is that the view is already visible when you re-add them. (I.e., if you setTitleTextAttributes:forState: in viewWillAppear:, then the view has not yet been drawn…) I've seen some situations before which seem like they might be analogous. In those cases, there was some sort of animation or other asynchronous behavior going on. If this is happening in your case, then your setTitleTextAttributes:forState: call (on re-adding the UIBarButtonItem) might be happening too early. Support you try this: add the UIBarButtonItem in it's enabled state. Then in a dispatch_after (or however you prefer to implement a deferred execution block), call setTitleTextAttribute:forState: for the disabled state and then disable the control. This idea here is for the text attribute for the disabled state to be set after any animations, etc. have completed. On Jul 10, 2013, at 6:10 PM, Rick Mann rm...@latencyzero.com wrote: On Jul 10, 2013, at 16:07 , Rick Aurbach r...@aurbach.com wrote: Well, since a UIBarButtonItem is a UIBarItem, you might try explicitly using the UIBarItem method setTitleTextAttributes:forState:, specifying the disabled state. (You'll need to do this in code (such as viewWillAppear:), since IB doesn't disclose the information. I'm guessing here, but my guess is that grayed text is the default text attribute for the disabled state, unless explicitly overwritten. Sorry if I wasn't clear in the original post. This is exactly what I do, and has served me well, until I started removing and re-adding the items to the toolbar so that I could hide them when not applicable. -- Rick Cheers, Rick Aurbach Aurbach Associates, Inc. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTextField: edits are committed even when -control:isValidObject: returns NO
On Jul 11, 2013, at 9:00 AM, Matthew LeRoy wrote: I'm trying to implement some input validation on an NSTextField using NSControlTextEditingDelegate's -control:isValidObject: method -- simple stuff like validating that the entered text is parsable as a number, falls within a certain range, etc. (I know that NSNumberFormatter is the obvious choice for this scenario, but I'm working with requirements that require more low-level customizability, particularly in the content of the error message and how it is presented to the user, than NSNumberFormatter allows.) I've got things generally working; the delegate method gets called, I validate the user's entry and return NO if it is invalid, and the text field remains first responder. The obstacle I've encountered is that in some cases my text field is a subordinate control that is enabled/disabled based on a checkbox elsewhere in my view. If the user enters something invalid and attempts to commit the edit by pressing tab/enter/return, I validate and display the error message and the text field remains first responder, as desired. However, if the user then unchecks the controlling checkbox -- causing the text field to be disabled via -setEnabled:NO in my view controller -- the text field is disabled but it keeps the invalid text. At this point, the user has successfully circumvented my input validation; they can just re-check the checkbox and the text field is reenabled containing the invalid text. Worse, if the user puts key focus in the NSTextField again but does not make any edits and then tabs out, the validation is not triggered because there are no pending edits. I do note that if the user enters invalid text but does not attempt to commit the edit and then unchecks the checkbox, the NSTextField is disabled and the text reverts back to what it was before the user made their edit. It seems that even though I'm returning NO from -control:isValidObject:, the edit is still 'committed' from the field editor to the NSTextField. What I want is for the text field to revert back to the previous valid entry upon unchecking the box, even after the user attempts to commit the invalid edit and is presented with an error message. So, it sounds like -control:isValidObject: might be too late in the pipeline to validate and prevent the edit from being committed in the first place. Any suggestions for an earlier point to hook in my validation? I did try -control:textShouldEndEditing:, but still see the same behavior. Or, a different approach to accomplish what I'm after? It may be more likely the case that because a checkbox is a button, buttons do not cause a change in the first responder so there is no explicit commit of the editing value. It is curious, however, that when the field is disabled it retains the invalid value. I would file a radar on that... Anyway, I would add to the action method for the checkbox to make the view controller commit any pending edits and if it fails to reject the change in the button state and hence disabling the NSTextField. HTH, Keary Suska Esoteritech, Inc. Demystifying technology for your home or business ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
CATiledLayer requesting tiles that are way out of view bounds
We have an NSView subclass. It's in an NSScrollView. The view has 1 CALayer
added to it, so we have the view's wantsLayer set to YES. This gives us tiled
drawing in our view. We have a case where the view is over 5000 pixels wide and
the scroll view is only 600 and some wide. If we jump to the extreme right by
using [view scrollPoint:pos], we're seeing some of the tiles having an x origin
way back at 0, while some are correctly way over at the right around 5000.
What's going on here? If we're revealing the rightmost portion of the view, it
has no business drawing the leftmost portion. Below shows the output of the
current CGContextGetClipBoundingBox.
{origin = {x = 0, y = 191}, size = {width = 512, height = 512}}
{origin = {x = 512, y = 703}, size = {width = 512, height = 512}}
{origin = {x = 0, y = 703}, size = {width = 512, height = 512}}
{origin = {x = 5120, y = 191}, size = {width = 512, height = 512}}
{origin = {x = 4608, y = 191}, size = {width = 512, height = 512}}
{origin = {x = 512, y = 191}, size = {width = 512, height = 512}}
{origin = {x = 0, y = 191}, size = {width = 512, height = 512}}
{origin = {x = 5632, y = 703}, size = {width = 292, height = 512}}
{origin = {x = 5120, y = 703}, size = {width = 512, height = 512}}
{origin = {x = 4608, y = 703}, size = {width = 512, height = 512}}
{origin = {x = 512, y = 703}, size = {width = 512, height = 512}}
{origin = {x = 0, y = 703}, size = {width = 512, height = 512}}
--
Steve Mills
office: 952-818-3871
home: 952-401-6255
cell: 612-803-6157
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: NSTextField: edits are committed even when -control:isValidObject: returns NO
Right; I recognize that clicking the checkbox doesn't cause a change in the first responder, and so any pending edits just get discarded when the button is disabled in the action method for the checkbox. That's exactly what I'm seeing when the user enters an invalid value without pressing tab/return/enter and then unchecks the box -- the edit is just discarded without any attempt at being committed or validated, and the text field reverts back to the previous value from before the user made their edit. (Or rather, perhaps field editor is just dismissed and the text field never even sees the potential new, invalid, value?) It's when the user *does* press tab/return/enter, or otherwise tries to change the first responder, that things behave strangely. In that case an attempt is made to commit the value, which calls my control:isValidObject: and I return NO, and the field editor remains first responder (or at least it appears to)… but if the user then unchecks the box, the text field shows the invalid value rather than the previous value. That's what makes me think that the invalid value is actually being committed to the underlying NSTextField upon pressing tab/return/enter or trying to change the first responder, even though I'm returning NO -- because otherwise I would expect the text field to still have the previous valid value. I had previously considered the same approach you suggested regarding adding to the checkbox's action method. The problem is that our desired behavior is to allow the checkbox to be unchecked at any time, and any uncommitted edits simply be discarded whether they are valid or not. That's what we're getting in the first case above, but since it seems that the invalid value is getting committed from the field editor to the NSTextField even when control:isValidObject: returns NO, simply asking the field editor to discard any pending edits doesn't help; the NSTextField's object value has already been changed to the invalid text and that's what we see in the disabled text field. I did some more looking through the docs and I see that the NSTextDelegate protocol (to which NSTextViewDelegate, the field editor's delegate protocol, conforms) also has a -textShouldEndEditing: method. Perhaps validating and rejecting the pending edit there would prevent it from being committed to the NSTextField? Though, my understanding is that a field editor's delegate is always the control for which it is the field editor (e.g. my NSTextField). That means I would either have to set the field editor's delegate to something else -- which could potentially break other code which expects the NSTextField to be the delegate -- or subclass NSTextField and implement textShouldEndEditing: there. On Jul 11, 2013, at 12:39 PM, Keary Suska cocoa-...@esoteritech.com wrote: On Jul 11, 2013, at 9:00 AM, Matthew LeRoy wrote: I'm trying to implement some input validation on an NSTextField using NSControlTextEditingDelegate's -control:isValidObject: method -- simple stuff like validating that the entered text is parsable as a number, falls within a certain range, etc. (I know that NSNumberFormatter is the obvious choice for this scenario, but I'm working with requirements that require more low-level customizability, particularly in the content of the error message and how it is presented to the user, than NSNumberFormatter allows.) I've got things generally working; the delegate method gets called, I validate the user's entry and return NO if it is invalid, and the text field remains first responder. The obstacle I've encountered is that in some cases my text field is a subordinate control that is enabled/disabled based on a checkbox elsewhere in my view. If the user enters something invalid and attempts to commit the edit by pressing tab/enter/return, I validate and display the error message and the text field remains first responder, as desired. However, if the user then unchecks the controlling checkbox -- causing the text field to be disabled via -setEnabled:NO in my view controller -- the text field is disabled but it keeps the invalid text. At this point, the user has successfully circumvented my input validation; they can just re-check the checkbox and the text field is reenabled containing the invalid text. Worse, if the user puts key focus in the NSTextField again but does not make any edits and then tabs out, the validation is not triggered because there are no pending edits. I do note that if the user enters invalid text but does not attempt to commit the edit and then unchecks the checkbox, the NSTextField is disabled and the text reverts back to what it was before the user made their edit. It seems that even though I'm returning NO from -control:isValidObject:, the edit is still 'committed' from the field editor to the NSTextField. What I want is for the text field to revert back to the previous valid entry
Re: NSTextField: edits are committed even when -control:isValidObject: returns NO
On Jul 11, 2013, at 11:23 , Matthew LeRoy mle...@minitab.com wrote: I had previously considered the same approach you suggested regarding adding to the checkbox's action method. The problem is that our desired behavior is to allow the checkbox to be unchecked at any time, and any uncommitted edits simply be discarded whether they are valid or not. Relying on the text field delegate methods to capture the change of state in every sequence of events seems fragile. You should probably approach this by having your checkbox action method adjust the value of the text field directly, just after disabling it. Either set the text field to not available when disabling, or validate the input and discard invalid values. You might additionally choose to re-validate the text field value later, when it's actually used (or committed to your data model). That way, if there's a scenario you've overlooked that would leave invalid input in the field, it can't propagate to the data model. Incidentally, I'd suggest that the reason you're running into an issue is that you really have a composite control, but you're simulating it via a pair of separate controls. It's not very surprising in that case that you might have to code the relationship between the controls explicitly. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: CATiledLayer requesting tiles that are way out of view bounds
On Thu, Jul 11, 2013, at 11:10 AM, Steve Mills wrote: We have an NSView subclass. It's in an NSScrollView. The view has 1 CALayer added to it, so we have the view's wantsLayer set to YES. This gives us tiled drawing in our view. We have a case where the view is over 5000 pixels wide and the scroll view is only 600 and some wide. If we jump to the extreme right by using [view scrollPoint:pos], we're seeing some of the tiles having an x origin way back at 0, while some are correctly way over at the right around 5000. What's going on here? If we're revealing the rightmost portion of the view, it has no business drawing the leftmost portion. Below shows the output of the current CGContextGetClipBoundingBox. If the coordinates it's asking for are valid within your document view, what's the issue? They might be necessary for correctly drawing or animating your view. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTextField: edits are committed even when -control:isValidObject: returns NO
I don't feel that I am relying on the delegate methods to capture any state change; all I'm doing in control:isValidObject: is validating the object and returning NO when it is invalid. According to the documentation, that's exactly what you're intended to do in that method. I've confirmed my suspicion that edits are getting committed to the NSTextField (or rather, the NSTextFieldCell) even when control:isValidObject: returns NO. I subclassed NSTextFieldCell and overrode setObjectValue:, and it is getting called and passed the edited value even before control:isValidObject: gets called on my delegate. While I can't find anywhere in the docs that explicitly say it, I assumed that the field editor would not commit the edit (that is, call setObjectValue:) until after calling control:isValidObject:, and even then only if that method returns YES. I'm not sure whether this should be considered a bug since as I said I can't find anything to the contrary in the documentation, but if others think it's worthwhile I'll file a radar for it. It occurs to me however that the documentation for [NSTextField textShouldEndEditing:] says that it first calls isEntryAcceptable: on the cell and then calls control:textShouldEndEditing: on the delegate if the previous method returns YES. My guess is that in between those two it calls setObjectValue: on the cell without waiting to see what is returned from control:textShouldEndEditing:. Perhaps I can subclass NSTextFieldCell and override isEntryAcceptable: and do my validation there instead, in the hopes that returning NO from that method will prevent the field editor from calling setObjectValue: on the cell. On Jul 11, 2013, at 3:14 PM, Quincey Morris quinceymor...@rivergatesoftware.commailto:quinceymor...@rivergatesoftware.com wrote: On Jul 11, 2013, at 11:23 , Matthew LeRoy mle...@minitab.commailto:mle...@minitab.com wrote: I had previously considered the same approach you suggested regarding adding to the checkbox's action method. The problem is that our desired behavior is to allow the checkbox to be unchecked at any time, and any uncommitted edits simply be discarded whether they are valid or not. Relying on the text field delegate methods to capture the change of state in every sequence of events seems fragile. You should probably approach this by having your checkbox action method adjust the value of the text field directly, just after disabling it. Either set the text field to not available when disabling, or validate the input and discard invalid values. You might additionally choose to re-validate the text field value later, when it's actually used (or committed to your data model). That way, if there's a scenario you've overlooked that would leave invalid input in the field, it can't propagate to the data model. Incidentally, I'd suggest that the reason you're running into an issue is that you really have a composite control, but you're simulating it via a pair of separate controls. It's not very surprising in that case that you might have to code the relationship between the controls explicitly. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTextField: edits are committed even when -control:isValidObject: returns NO
On Jul 11, 2013, at 13:01 , Matthew LeRoy mle...@minitab.com wrote: I don't feel that I am relying on the delegate methods to capture any state change[…] I wasn't suggesting that you are doing anything wrong, rather that there's a more positive point of control. I assumed that the field editor would not commit the edit (that is, call setObjectValue:) until after calling control:isValidObject:, and even then only if that method returns YES. I don't know, but this seems like an unlikely assumption. The objectValue property *is* the value that the text field contains, and I doubt that there's any API contract that it's a validated value. Note that you've used commit in an unusual sense, in Cocoa terms. In the Apple documentation, commit means to transfer the raw value from a text field to the data model. The communication between the field editor and the text field is something of an implementation detail, and probably doesn't follow as clear a protocol as you would wish. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: CATiledLayer requesting tiles that are way out of view bounds
On Jul 11, 2013, at 14:25:08, Kyle Sluder k...@ksluder.com wrote: If the coordinates it's asking for are valid within your document view, what's the issue? They might be necessary for correctly drawing or animating your view. It's not animating. Plus, those areas were already drawn, so they should be cached. Because of our *extremely* complex drawing system, it causes problems. -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: [SOLVED] NSTextField: edits are committed even when -control:isValidObject: returns NO
Boy, do I feel like a dummy. While investigating when setObjectValue: is getting called on the cell, I set a breakpoint in my override of that method and decided to check the call stack to see who was calling it -- assuming that it was the text field itself in its implementation of textShouldEndEditing: as I had guessed previously. But when I looked, I saw the following stack: [TestTextFieldCell setObjectValue:] [NSCell setStringValue:] [NSCell stringValue] [MyViewController control:isValidObject:] ... Turns out that rather than validating the object passed to me in control:isValidObject:, I was stupidly getting the stringValue directly from the text field and validating that -- and apparently asking for the stringValue causes the cell to retrieve the current edited text from the field editor and call setStringValue: on itself with that text before returning it. I fixed my code to validate the object passed in isValidObject instead, and now the pending edit is not committed to the cell when I return NO -- setObjectValue: doesn't get called. As a result, if the user enters invalid text and presses tab/return/enter and then unchecks the checkbox, the text field reverts back to the previous valid value as desired. Thanks to those who took time to pass along their thoughts. My apologies for boring the list with problems caused by my own buggy code :-P ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: CATiledLayer requesting tiles that are way out of view bounds
On Thu, Jul 11, 2013, at 01:49 PM, Steve Mills wrote: On Jul 11, 2013, at 14:25:08, Kyle Sluder k...@ksluder.com wrote: If the coordinates it's asking for are valid within your document view, what's the issue? They might be necessary for correctly drawing or animating your view. It's not animating. Layers animate by default, even if the animation has zero duration. Things have gotten better recently with the advent of NSAnimationContext.allowsImplicitAnimation. Plus, those areas were already drawn, so they should be cached. Because of our *extremely* complex drawing system, it causes problems. Under the Cocoa drawing architecture, any part of your view can be invalidated at any time for any reason. Caching complex drawing has always been your responsibility. If we think about the time before layers, you would probably create an offscreen bitmap context for your rendering and blit the relevant portions to the screen in -drawRect:. With layers, you have some more flexibility, but only if you take the reins away from Cocoa's automatic layer-backing. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Using autolayout in a UI table view section header view
I'm trying to reproduce the UITableView section header view used by iOS for
regular text headers. Based on Reveal.app, I see that it's a view sized 540 x
34 that contains a UILabel (subclass) sized width x 21, positioned 40x5.
I wanted to add a UIActivityIndicator just to the end of the text label, so I
built up the same hierarchy in IB:
http://cl.ly/image/1L3q1b43471w
But that alone wasn't enough; iOS stretches my view to the full width of the
table, and squashes it vertically to something very short. So I tried adding a
height constraint in code, because IB doesn't let me add a height constraint to
a top-level view:
+ (UITableViewSectionHeaderWithActivityIndicator*)
instance
{
static UINib* sNib;
static dispatch_once_t sInit;
dispatch_once(sInit,
^{
sNib = [UINib nibWithNibName:
@UITableViewSectionHeaderWithActivityIndicator bundle: nil];
});
NSArray* objs = [sNib instantiateWithOwner: nil options: nil];
UITableViewSectionHeaderWithActivityIndicator* v = objs.lastObject;
// IB won't let us add constraints to the top-level view…
//v.translatesAutoresizingMaskIntoConstraints = false;
NSDictionary* metrics = @{ @height : @(v.frame.size.height) };
NSDictionary* views = @{ @view : v };
NSArray* constraints = [NSLayoutConstraint constraintsWithVisualFormat:
@V:[view(height)] options: 0 metrics: metrics views: views];
[v addConstraints: constraints];
return v;
}
This fails with:
2013-07-11 14:21:32.317 App[70432:c07] Unable to simultaneously satisfy
constraints.
Probably at least one of the constraints in the following list is one
you don't want. Try this: (1) look at each constraint and try to figure out
which you don't expect; (2) find the code that added the unwanted constraint
or constraints and fix it. (Note: If you're seeing
NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the
documentation for the UIView property
translatesAutoresizingMaskIntoConstraints)
(
NSLayoutConstraint:0x9fb6570
V:[UITableViewSectionHeaderWithActivityIndicator:0x9fb6c80(34)],
NSAutoresizingMaskLayoutConstraint:0x9fb50d0 h=-- v=--
V:[UITableViewSectionHeaderWithActivityIndicator:0x9fb6c80(10)]
)
Will attempt to recover by breaking constraint
NSLayoutConstraint:0x9fb6570
V:[UITableViewSectionHeaderWithActivityIndicator:0x9fb6c80(34)]
So I tried setting translatesAutoresizingMaskIntoConstraints to false, but that
results in
2013-07-11 14:24:53.688 App[70482:c07] *** Assertion failure in -[UITableView
layoutSublayersOfLayer:], /SourceCache/UIKit_Sim/UIKit-2380.17/UIView.m:5776
2013-07-11 14:24:57.127 App[70482:c07] *** Terminating app due to uncaught
exception 'NSInternalInconsistencyException', reason: 'Auto Layout still
required after executing -layoutSubviews. UITableView's implementation of
-layoutSubviews needs to call super.'
So I commented out that line and then added the bottom space constraint in IB
(between the label and the container view, to force the view's height).
Any suggestions?
Thanks,
--
Rick
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Using autolayout in a UI table view section header view
At least part of my problem is I forgot to implement
-tableView:heightForHeaderInSection:
On Jul 11, 2013, at 14:26 , Rick Mann rm...@latencyzero.com wrote:
I'm trying to reproduce the UITableView section header view used by iOS for
regular text headers. Based on Reveal.app, I see that it's a view sized 540 x
34 that contains a UILabel (subclass) sized width x 21, positioned 40x5.
I wanted to add a UIActivityIndicator just to the end of the text label, so I
built up the same hierarchy in IB:
http://cl.ly/image/1L3q1b43471w
But that alone wasn't enough; iOS stretches my view to the full width of the
table, and squashes it vertically to something very short. So I tried adding
a height constraint in code, because IB doesn't let me add a height
constraint to a top-level view:
+ (UITableViewSectionHeaderWithActivityIndicator*)
instance
{
static UINib* sNib;
static dispatch_once_t sInit;
dispatch_once(sInit,
^{
sNib = [UINib nibWithNibName:
@UITableViewSectionHeaderWithActivityIndicator bundle: nil];
});
NSArray* objs = [sNib instantiateWithOwner: nil options: nil];
UITableViewSectionHeaderWithActivityIndicator* v = objs.lastObject;
// IB won't let us add constraints to the top-level view…
//v.translatesAutoresizingMaskIntoConstraints = false;
NSDictionary* metrics = @{ @height : @(v.frame.size.height) };
NSDictionary* views = @{ @view : v };
NSArray* constraints = [NSLayoutConstraint constraintsWithVisualFormat:
@V:[view(height)] options: 0 metrics: metrics views: views];
[v addConstraints: constraints];
return v;
}
This fails with:
2013-07-11 14:21:32.317 App[70432:c07] Unable to simultaneously satisfy
constraints.
Probably at least one of the constraints in the following list is one
you don't want. Try this: (1) look at each constraint and try to figure out
which you don't expect; (2) find the code that added the unwanted constraint
or constraints and fix it. (Note: If you're seeing
NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the
documentation for the UIView property
translatesAutoresizingMaskIntoConstraints)
(
NSLayoutConstraint:0x9fb6570
V:[UITableViewSectionHeaderWithActivityIndicator:0x9fb6c80(34)],
NSAutoresizingMaskLayoutConstraint:0x9fb50d0 h=-- v=--
V:[UITableViewSectionHeaderWithActivityIndicator:0x9fb6c80(10)]
)
Will attempt to recover by breaking constraint
NSLayoutConstraint:0x9fb6570
V:[UITableViewSectionHeaderWithActivityIndicator:0x9fb6c80(34)]
So I tried setting translatesAutoresizingMaskIntoConstraints to false, but
that results in
2013-07-11 14:24:53.688 App[70482:c07] *** Assertion failure in
-[UITableView layoutSublayersOfLayer:],
/SourceCache/UIKit_Sim/UIKit-2380.17/UIView.m:5776
2013-07-11 14:24:57.127 App[70482:c07] *** Terminating app due to uncaught
exception 'NSInternalInconsistencyException', reason: 'Auto Layout still
required after executing -layoutSubviews. UITableView's implementation of
-layoutSubviews needs to call super.'
So I commented out that line and then added the bottom space constraint in IB
(between the label and the container view, to force the view's height).
Any suggestions?
Thanks,
--
Rick
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/rmann%40latencyzero.com
This email sent to rm...@latencyzero.com
--
Rick
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
UITableView section 20 px difference between text and view versions
If I implement -tableView:titleForHeaderInSection:, the resulting header has additional margin (20 px) above the views created for the header by iOS. If I instead implement -tableView:viewForHeaderInSection: and -tableView:heightForHeaderInSection:, I don't get that extra 20 px of padding above my view. Where does that padding come from, and can I get it added to my header view, or do I have to bake it into my view? Thanks, -- Rick ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
iOS reachability
I sent this yesterday to macnetworkprog, but I wonder if this list might reach more people who've encountered the issue before... --- I'm working on an iPad app to control a device. In one possible configuration, the device hosts a Wi-Fi network and the user connects the iPad to it. The device has a DHCP server and provides an IP address and subnet mask to the iPad, but does not provide a Router or DNS or other information. We are able to successfully make TCP connections to the device over Wi-Fi. If the iPad also has a cellular data plan, we want to connect to our server (this is a server in the cloud, not the device) via that cellular data connection. But the SCNetworkReachabilityFlags I get back are 0 (unreachable, not WWAN). Attempts to connect to our server fail. Attempts to use Safari to connect to the internet fail. Is there something about what our device is providing via Wi-Fi that prevents the iPad from figuring out how to route traffic? Is it not possible to split network operations this way? I thought it could do this, and this is critical to our product's ease of use. Thanks, -- Rick ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Custom drag image for NSTableView selections
I'd suggest just badging the drag image with the number of items being dragged if it's more than what is visible (or badge it anyway, so the user gets used to the badge). The latest drag API has a way to collapse the drag with an animation to help reinforce this idea as well. If you build a drag image from the entire selection no matter how large, the image will be often too large to be usable. --Graham On 12/07/2013, at 12:37 AM, dangerwillrobinsondan...@gmail.com wrote: Granted I will need to also do some handling of excessively large number of selected rows and make some visual indication in that is more than can reasonably be displayed. Happy to hear any guidance on this from anybody who has implemented something similar before. (Caveats and gotchas please ) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Custom drag image for NSTableView selections
On Jul 12, 2013, at 8:46 AM, Graham Cox graham@bigpond.com wrote: I'd suggest just badging the drag image with the number of items being dragged if it's more than what is visible (or badge it anyway, so the user gets used to the badge). The latest drag API has a way to collapse the drag with an animation to help reinforce this idea as well. The badge is a nice idea and would be a familiar paradigm for users! However, based on the way I have simply put the row selection indexes NSIndexSet into NSData and into the pasteboard, the API as I see it at the moment (using NSDraggingSession property draggingFormation ) may not work for me without some additional work. I wasn't really wanting to put the represented objects of my rows on to the pasteboard, since NSView and NSTableView do a lot of the dragging API work already, it may have to be a feature I handle later, it looks like a lot of work for now, and the API seems spread out amongst a lot of different classes I am not familiar with… :( If you build a drag image from the entire selection no matter how large, the image will be often too large to be usable. Most definitely. --Graham On 12/07/2013, at 12:37 AM, dangerwillrobinsondan...@gmail.com wrote: Granted I will need to also do some handling of excessively large number of selected rows and make some visual indication in that is more than can reasonably be displayed. Happy to hear any guidance on this from anybody who has implemented something similar before. (Caveats and gotchas please ) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: iOS reachability
Interestingly, this is now working as expected. Not sure what was going on last night, but I couldn't get it to behave. On Jul 11, 2013, at 16:40 , Rick Mann rm...@latencyzero.com wrote: I sent this yesterday to macnetworkprog, but I wonder if this list might reach more people who've encountered the issue before... --- I'm working on an iPad app to control a device. In one possible configuration, the device hosts a Wi-Fi network and the user connects the iPad to it. The device has a DHCP server and provides an IP address and subnet mask to the iPad, but does not provide a Router or DNS or other information. We are able to successfully make TCP connections to the device over Wi-Fi. If the iPad also has a cellular data plan, we want to connect to our server (this is a server in the cloud, not the device) via that cellular data connection. But the SCNetworkReachabilityFlags I get back are 0 (unreachable, not WWAN). Attempts to connect to our server fail. Attempts to use Safari to connect to the internet fail. Is there something about what our device is providing via Wi-Fi that prevents the iPad from figuring out how to route traffic? Is it not possible to split network operations this way? I thought it could do this, and this is critical to our product's ease of use. Thanks, -- Rick ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/rmann%40latencyzero.com This email sent to rm...@latencyzero.com -- Rick ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Custom drag image for NSTableView selections
On 12/07/2013, at 10:35 AM, dangerwillrobinsondan...@gmail.com wrote: However, based on the way I have simply put the row selection indexes NSIndexSet into NSData and into the pasteboard, the API as I see it at the moment (using NSDraggingSession property draggingFormation ) may not work for me without some additional work. I wasn't really wanting to put the represented objects of my rows on to the pasteboard, since NSView and NSTableView do a lot of the dragging API work already, it may have to be a feature I handle later, it looks like a lot of work for now, and the API seems spread out amongst a lot of different classes I am not familiar with… :( Is the drag expected to work between different apps or simply within your own app? If the latter, there is no reason to put anything on the pasteboard other than enough dummy data to identify the drag (usually your private drag type and an empty string are enough). When you start the drag, put the real data somewhere accessible, such as a class method. When you receive the drag and identify it as this private type, use the class method to get the data. That data can be the original index set for example (though as far as I can see there's nothing to stop you putting the index set on the pasteboard directly, not sure why you need to convert to NSData). The point is that the drag APIs standardise the visual side of the process, but do not force you to use the data side of the process unless the objective is to pass data between apps. Particularly for table reordering or dragging in and out of tables, it's often much easier to bypass the data side of the drag manager. Putting your actual objects on the pasteboard is a waste of time, since they're only going to be converted back again in a different place within the same app. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Custom drag image for NSTableView selections
On 2013/07/12, at 10:49, Graham Cox graham@bigpond.com wrote: On 12/07/2013, at 10:35 AM, dangerwillrobinsondan...@gmail.com wrote: However, based on the way I have simply put the row selection indexes NSIndexSet into NSData and into the pasteboard, the API as I see it at the moment (using NSDraggingSession property draggingFormation ) may not work for me without some additional work. I wasn't really wanting to put the represented objects of my rows on to the pasteboard, since NSView and NSTableView do a lot of the dragging API work already, it may have to be a feature I handle later, it looks like a lot of work for now, and the API seems spread out amongst a lot of different classes I am not familiar with… :( Is the drag expected to work between different apps or simply within your own app? Both. Internal for reordering rows for now. But will be adding drag to move and drag to copy between collections, as well as drag to external for copying a text or image representation. If the latter, there is no reason to put anything on the pasteboard other than enough dummy data to identify the drag (usually your private drag type and an empty string are enough). When you start the drag, put the real data somewhere accessible, such as a class method. When you receive the drag and identify it as this private type, use the class method to get the data. That data can be the original index set for example (though as far as I can see there's nothing to stop you putting the index set on the pasteboard directly, not sure why you need to convert to NSData). Hadn't thought of it that way. Examples of drag to reorder that I saw all used NSData IIRC. ... The point is that the drag APIs standardise the visual side of the process, but do not force you to use the data side of the process unless the objective is to pass data between apps. Particularly for table reordering or dragging in and out of tables, it's often much easier to bypass the data side of the drag manager. Putting your actual objects on the pasteboard is a waste of time, since they're only going to be converted back again in a different place within the same app. Good perspective! This makes it really like the drag op destination is a manually initiated notification in my mind. I will give this a try as it promises to clean up some unnecessary code. But to support the other kinds of drag ops, I may need to go with a heavier weight pasteboard entry? ( since there's no way to preemptively know the destination) I still want to control the drag image in any drag op and have a bit of learning and experimenting to do in that space. But I will start with one. ;) Last for polish I need to figure out the animation of row reordering when drag is internal. But that's not the highest priority at the moment. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Custom drag image for NSTableView selections
On 12/07/2013, at 2:29 PM, dangerwillrobinsondan...@gmail.com wrote: But will be adding drag to move and drag to copy between collections, as well as drag to external for copying a text or image representation. Those externals would be additional (standard) drag types. But to support the other kinds of drag ops, I may need to go with a heavier weight pasteboard entry? ( since there's no way to preemptively know the destination) At the time of the drop you do know, and for those types that are moving out of the app, you supply the data at that time (promise data). This avoids the need to load up the pasteboard with a lot of data (potentially expensively) ahead of time just on the offchance that one of them will be needed. You declare your various different types ahead of time, but not the actual data until actually needed. Last for polish I need to figure out the animation of row reordering when drag is internal. But that's not the highest priority at the moment. NSTableView has methods for performing the animation, once you know which rows are moving where. That is handled as part of the final step of the drop, which is long after the drag manager has done its bit. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
