Re: when __bridge isn't required
On Jul 27, 2013, at 11:54 , Robert Martin robmar...@frontiernet.net wrote: But CGImageSourceCreateWithURL() includes the keyword 'create' - so the object you get back has a retain count of 1. ARC will insist that you cast with __bridge or __bridge_transfer. ARC isn't involved with the return value in either case. In the first one, it's a scalar, as you noted. In the second, it's a core foundation object, which isn't managed by ARC … … unless the CGImageSourceCreateWithURL is marked (in the SDK) with the attribute that that says it can be managed by ARC (a fairly recent addition to Clang) … … but that wouldn't be it anyway, since there's no cast needed on the return value, let alone a __bridge. On Jul 27, 2013, at 11:31 , Matt Neuburg m...@tidbits.com wrote: The first one compiles (with no explicit __bridge). The second one doesn't; you must say __bridge explicitly. I tried both your examples in Xcode 4.6.3 and OS X 10.8 SDK, and neither produced an error or a warning. The answer to your question probably depends on: -- the version of Clang you're using -- the particular SDK you're using -- the compiler options you're using ___ 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: storage for context: value
On Jul 25, 2013, at 07:20 , Matt Neuburg m...@tidbits.com wrote: storage of the value passed as context:(void*), not just in addObserver:, but in general I think I'd take this in a different direction. In *all* of these scenarios the context parameter is a mechanism for passing a pointer to a data structure to a callback/completion routine/handler with a generic signature, as Roland already said. That leads to a set of potential pitfalls: -- Memory management. If the data structure is allocated memory (C idiom) or an object (ObjC idiom), it's not trivial to manage its lifetime. -- Heterogeneity. If contexts of different idioms are fed to the same handler, it can be difficult to decide what data structure is being pointed to. -- Complexity. If the data structure pointed to is just a single value (such as a simple type, or a simple identifier), it can take a lot of code to package this in a real data structure that behaves properly wrt the first 2 pitfalls. The 'static void* x = x;' convention you mention (a pointer as tag convention) is significant only because it's a very elegant way to avoid all 3 pitfalls, when no additional data needs to be passed. It also has the virtue of relieving the developer from the need to remember whether to put a '' on the front of the argument. The story behind 'addObserver' (or, really, the story behind 'observeValueForKeyPath') is a separate matter. This particular API was misdesigned, because it did not properly envisage a need to identify multiple observations of the same thing. Thus, the 'context' parameter came to be used as this identification -- there was no actual data structure to be passed in. The above pointer as tag convention bubbled to the top of the pile as the most convenient way to solve the problem. ___ 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: storage for context: value
On Jul 25, 2013, at 12:08 , Matt Neuburg m...@tidbits.com wrote: Well, and discussions of the issue often fail to take into account the problem of distinguishing the context on an instance-by-instance basis. Passing self as a context does that, obviously; but the static void* trick does not (there is one storage per class, not per instance of that class). In the 'observeValueForKeyPath' scenario (keeping in mind that it's a broken API design), using 'self' is dangerous because it's not unique enough. A superclass-defined observation may cleverly try to use it too. If an informative data structure is to be used on an instance-by-instance basis, and if this data structure is to persist, then it seems to me that it *must* be an instance variable. When you say instance variable I think there are actually 3 different possibilities: 1. You want a per-instance value, which is stored in an ivar specifically for that purpose. 2. You might get away with using the address of an ivar that's private to your class (whose value is something unrelated). The address is unique to the instance and class, because superclasses and subclasses won't be using it. 3. You might still need a per-observation-per-instance context tag, in which case #1 and #2 don't work. This is particularly relevant to the new form of 'removeObserver'. If it were me, I would use a per-class tag (such as the static variable address) when I could, or a per-observation UID otherwise. Using a per-instance UID -- anything unique only to the level of 'self' -- seems too dangerous these days. The likelihood of the class having -- or later adding -- multiple observations on the same thing seems too high. ___ 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: NSTextView's MarkedText
On Jul 24, 2013, at 14:53 , Gordon Apple g...@ed4u.com wrote: I need the mouseUp (selection ended) Why not use the delegate method for detecting a selection change (textViewDidChangeSelection) and, using state you save when a pen swipe starts, change the attributes on the new selection if the selection change is due to a pen swipe. ___ 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: type of NSNotFound
There's no mistake. There are several things going on here. One is that C is a bit funny about compile-time resolution of constants outside the signed (int or long) range, which makes it desirable to avoid having a constant outside the range. Otherwise, unsigned constants may turn into signed constants, and vice versa. (I can never remember the exact scenario, so that's why I'm waving arms a bit. But it's a known C quirk.) Another is that it's useful for NSNotFound to have one value that can be used in either an signed or unsigned context. That means it has to lie in non-negative signed integer range, and the only practical value meeting those conditions is NSIntegerMax. Lastly, NSUIntegerMax isn't *outside* the unsigned integer range, it's the last value inside it. However, limiting the range even to half of the theoretical maximum isn't a problem. It isn't possible to have a Cocoa collection of even NSIntegerMax elements, because the memory addressing range isn't big enough to record that many pointers, let alone the objects pointed to. (You'd need NSIntegerMax * 8 bytes for the pointers, or about 2**35 bytes.) There was a thread about this recently, and I think the take-away is: -- Having NSNotFound==NSIntegerMax is only a problem in the context of things like sparse arrays that need a full 64 bits of indexing. If you implement such a construct, you'd better stay away from using NSNotFound with it, but there's nothing like that (AFAIK) in Cocoa itself. -- The real difficulty with NSNotFound is that it's architecture dependent, which means you need to be very careful about NSArchiving it in documents shared between 32- and 64-bit architectures. On Jul 20, 2013, at 15:06 , Matt Neuburg m...@tidbits.com wrote: On iOS, NSNotFound is defined as NSIntegerMax. However, the index of an NSArray, which is a case where you'd often want to use NSNotFound (e.g. indexOfObject:), is of type NSUInteger. Isn't there a type mismatch here? It seems to me that NSNotFound ought to be a value *outside* the possible range NSArray index values - which it would be, if NSNotFound were NSUIntegerMax, or if NSArray's indexes were of type NSInteger. As thing are, when you call indexOfObject: and test the result against NSNotFound, you could be getting the wrong answer; if that index happens to be NSIntegerMax (which is only halfway through the available unsigned indexes), it will seem to be NSNotFound when in fact it is an actual index. I must be wrong about this, since Apple wouldn't make such a basic mistake. So what's *my* mistake? Thx - m. ___ 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: type of NSNotFound
Er, I mean 2**67 bytes. My brain was stuck on 32 bit pointers. On Jul 20, 2013, at 15:30 , Quincey Morris quinceymor...@rivergatesoftware.com wrote: or about 2**35 bytes ___ 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: NSUndoManager Won't Redo
On Jul 18, 2013, at 11:58 , Keary Suska cocoa-...@esoteritech.com wrote: Posting in hopes that someone has run into this case and figured it out. There used to be a bug in text field undo in a somewhat similar case (though I don't remember whether it involved using separate undo managers for the text fields) and it's quite possible it's never been fixed. The workaround was to intermediate a NSObjectController between the data model and the text field. This basically does nothing, except perhaps the object controller's commitEditing had a side effect that kept undo from misbehaving. ___ 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: Re-booting after changing Icons in OS X Doc app
On Jul 17, 2013, at 21:14 , Peter Teeson ptee...@icloud.com wrote: However from the Googling I did and the experiments I performed it seems I have to use terminal to (1) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -r -domain local -domain user (2) re-boot to effectuate new icons as I try them out after I have re-built the app. Is this correct and SOP? Or is there a better way? No, it's not really the correct approach. This is one of those Internet voodoo things that's been around for years, and survives because rebuilding the Launch Services database does sometimes fix (or appear to fix) the icons being displayed. -- If you change your app's icons and you see the new icons being correctly used, there's nothing you need to do. -- If the new icons don't show up, then you probably have an app bundle somewhere that has the old icons, and Launch Services is choosing the bundle with the old icons to represent your app. This sometimes happens when you have built for multiple configurations (Build/Release/etc) in the past, and haven't yet caused all of them to be rebuilt since you changed the icons. If the icons are displaying wrong, you can try cleaning (or just deleting) the derived data folder, which should delete any old app bundles. You might also have put a copy of an old app bundle somewhere else, and that may prevent your new icons from showing up. -- Occasionally, the Launch Services database gets out of sync with what's actually in the file system, and so you can't fix it by removing files. In that case, you might have to nuke the database with lsregister, but you shouldn't expect to have to do this as a regular thing. Note that if you have multiple bundles with different icon definitions, using lsregister isn't necessarily going to solve the problem. In the presence of conflicting information, Launch Services doesn't really know which to use. ___ 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 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: 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: 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: Bundle Identifiers - and application support directory
On Jul 10, 2013, at 08:43 , Scott Ribe scott_r...@elevated-dev.com wrote: The convention that we're talking about is that the apps' directories in Application Support should be named by bundle identifier, not by application name. The list that I provided was the result of ls Application\ Support, so as you can see the convention of using bundle identifiers is generally not followed. The convention has always been or, rather than instead of. The choice is still documented here: https://developer.apple.com/library/mac/#documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/FileSystemOverview/FileSystemOverview.html The Library Directory Stores App-Specific Files Application Support All content in this directory should be placed in a custom subdirectory whose name is that of your app’s bundle identifier or your company. My vague recollection is that it used to say something like or your app name too. A similar description here: https://developer.apple.com/library/mac/#documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/MacOSXDirectories/MacOSXDirectories.html doesn't mention the alternatives at all: OS X Library Directory Details Application Support By convention, all of these items should be put in a subdirectory whose name matches the bundle identifier of the app. so it's possible that we're seeing a change in the convention in progress. My guess is that the app-name variant was previously preferred because Application Support was always envisioned as a folder that users might have a reason to visit in the Finder. But in sandboxed apps, Application Support doesn't seem to have as big a role to play as before. ___ 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: The cost of using objects rather than plain C variables
On Jul 6, 2013, at 23:06 , Vincent Habchi vi...@macports.org wrote: instead of [myMutableArray add:[[NSString stringFromCString:… encoding:…] componentsSeparatedBy:@, ]], I just wrote: sscanf (myLine, %f, %f, %f, t [0], t [1], t [2]) How come I get such a large discrepancy in memory usage between the two solutions? Is the overhead of Cocoa object so huge? It's not just the overhead of objects. According to the code you posted, you're storing floats instead of strings. Ken already elaborated on this conceptual answer, but I think the back-of-the-envelope calculation is enlightening: Each NSString has at least 4 bytes of overhead (the 'isa' pointer); each character is UTF-16; each object is a multiple of 16 bytes. Your values may not fit in the remaining 12 bytes of the smallest object (an input format something like '0.xe-nn', which isn't an unlikely format, wouldn't fit in 12 bytes, even with only 1 significant digit in the mantissa). In addition, there's at least a pointer's overhead per value in the array itself. That means you could be using 36 bytes per value in the objectified representation, versus 4 bytes in the C representation, or a factor of about 9. That's not so far off the factor of 10 you reported. If the above is a correct analysis, then using a NSNumber representation instead of a NSString would reduce the memory use to around 100MB. Using a custom object should, as Ken suggests, reduce this by another factor of somewhere between 2 and 3. Actually, that's not so bad. 33-50MB instead of 20MB, for the objectified vs scalar representation, isn't unbearable, I suspect. However, the C array of scalars is probably the best choice. ___ 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: redo: action not in First Responder
On Jul 2, 2013, at 09:10 , Steve Mills smi...@makemusic.com wrote: That seems like a total hack when there should be an obvious button or something in First Responder's action list that allows the user to easily add a new action. There is a button, but it's obvious only after you know where it is. Select the First Responder item in the list of XIB components on the left of the editing pane. Display the Attributes inspector in the pane at the right of the window, and you'll see a list of custom actions to which you can add actions. ___ 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: NSOutlineView (Cell based) loses Text
On Jun 24, 2013, at 14:41 , Robert Fiedler robert.fied...@kryptowelt.de wrote: Does anybody have an idea what could be the reason for that behavior or in what direction I should dig? I believe I've seen similar behavior caused by malfunctioning auto-layout constraints on the text and image subviews. Make sure you have an exception breakpoint set to catch any auto-layout constraints violations. ___ 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: NSTableView/NSOutlineView view-based group rows/items span the whole column?
On Jun 22, 2013, at 17:52 , Nick Zitzmann n...@chronosnet.com wrote: I did search the documentation and the archives, and didn't see anyone talking about this. It appears that, in view-based NSTableViews or NSOutlineViews, if a row is designated as a group row/item, then the view spans the entire column, and the table column argument passed into -outlineView:viewForTableColumn:item: will always be nil. Am I correct so far? Is there any way to turn this off, so that group items can have multiple views in a row, and if so, then what do I do to make this not happen? Well, the documentation for the NSTableViewDelegate protocol says (of the column parameter): Will be nil if the row is a group row. If you want it to behave like NSCell-based tables used, one way would be to *not* make these group rows. Instead, implement the delegate method 'tableView:tableView rowViewForRow:' to create a view with a group row appearance behind the column views. The only thing you'd lose would be the floating row behavior of real group rows, but that probably isn't desirable anyway for your scenario. In a case of extreme need, you could create a group row view that contains subviews similar to the column views, and adjust the view layout to line the subviews up with the column views. It sort of makes sense for the new API to expect that group rows are section headers, rather than special detail rows, but I understand the frustration of having functionality you're actually using taken away from you. ___ 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: UIDocument + NSFileWrapper crashes on opening
On Jun 20, 2013, at 22:05 , Markus Spoettl ms_li...@shiftoption.com wrote: It seems that the default implementation of UIDocument uses an NSFileWrapper initialized with the NSFileWrapperReadingImmediate reading option. When I create a NSFileWrapper not using that option it works, meaning it now opens and loads the package document it previously crashed on. I wonder what surprises I will run into with lazy wrapper loading like that. Initial tests show no problems when changing the document and saving the whole thing. For now it seems to work exactly like on OSX. What is interesting too is that my application was able to create the whole wrapper structure when it first created the package. It would have required the same amount of memory to hold the wrappers in memory before they get written to the disk by UIDocument. Maybe it has to do with the fact that it is creating the structure incrementally and relatively slowly while downloading objects over the network. Reading the UIDocument from disk on the other hand requires it to load everything instantly. Maybe there's some system safeguard in place that kills apps whose memory usage increases too rapidly. I think the short answer is that your files are being memory-mapped rather than read via I/O. That means the result is dependent on the VM swapping caused by your pattern of access. That's assuming you actually read all of the files. If you don't access the data, it won't have any performance impact. You might get away with this on iOS, but on OS X it's all going to come unstuck if the document file is on a disk that doesn't allow memory mapping, such as a network volume. One of these days I'm going to write an experimental app that tries to figure out what happens when. ___ 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: UIDocument + NSFileWrapper crashes on opening
On Jun 21, 2013, at 03:40 , Markus Spoettl ms_li...@shiftoption.com wrote: can it be that a wrapper which I hold on to from the time I first created it switches it's backing from in-memory to memory mapped disk once it has been saved? There are actually three possible states for a regular file wrapper: 1. 'regularFileContents' is a NSData instance whose data is in memory in the normal way 2. 'regularFileContents' is a NSData instance whose data is memory-mapped to a file 3. 'regularFileContents' is nil When you create a regular file wrapper with 'initRegularFileWithContents:', the initial state is #1. There is no documented API that will change this state to #2 or #3, other than releasing the file wrapper and creating a new one. When you create a file wrapper with 'initWithURL:options:error:', the initial state is #3, unless you use the 'NSFileWrapperReadingImmediate' option. This gets changed to #1 or #2 when you access the 'regularFileContents' property. When a save occurs, 'contentsForType:error:' returns a package wrapper that may be the one you were given originally, or may be one that you construct at save time. I believe, therefore, that the frameworks do nothing to sub-wrappers after you return the package wrapper for the save. For files that were edited, the sub-wrapper will be in state #1 (with the new data), and for files that weren't, the sub-wrapper will be in state #2 or #3 (depending on whether this particular instance was used to read the old data or not). The net effect is that only changed file data is hogging RAM, and the only way to switch the sub-wrappers back to state #3 is the recreate the package wrapper yourself. What's confusing about this is that it's hard to tell the difference between the ideal (state #3 except for sub-wrappers with freshly edited data) and the typical (state #2 for sub-wrappers whose data has been read). ___ 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: NSDocument and Large File Import?
On Jun 20, 2013, at 12:06 , Karl Moskowski kmoskow...@me.com wrote: I’m creating a document-based OS X app. The document itself will be a package, with most of the its properties archived in a plist (via NSFileWrapper). However, the document package will also contain a potentially — probably, even — large asset file that’s too big to keep in memory. The first step of the new document workflow is that the user chooses the asset to import. It’s then displayed for editing. My problem arises in the creation phase. After the new NSDocument object is instantiated (in either -init or -initWithType:error:), but before the document is saved, I don’t have an on-disk location to which to import, as far as I can tell; all of the URL-ish properties and methods of NSDocument are nil. It’s a modern app, with the various autosave methods returning YES, and when the app quits, the new document is in ~/Library/Autosave Information”. Consider what happens later, when an existing document needs to be re-saved. Since, in general, your save method must handle the case where the save is to a different location (Save As, for example), you need a mechanism to clone the large file. (You could hard link it when possible, but there'll always be situations where you have to copy it -- saving to a network volume, for example.) With a little care, you should be able to use the same code for new documents. Import the asset into a temp file. At save time, you'd notice that the asset file isn't in the save destination, so you'd clone it. There are other approaches, but this one fits most neatly in the NSDocument architecture, if it suits your use case. Should I be taking the approach of Xcode, where the “New Project” process asks the user to choose a location for the project, and it’s saved immediately? Or is there a property or method I’m missing that gives the autosaved new document’s location? I think this is a different issue. It's mostly about whether it makes sense for the user to have an untitled-document experience for your app. If the import takes a long time, you can do it *before* creating the NSDocument instance, or *after* the document creation process is complete (that is, after makeWindowControllers is called). That's because you want a long import to have UI (progress/cancel), and the middle of a NSDocument 'init…' is not the place to do that. If you choose before, then it's probably easier to have the user choose the save location before, too. If you choose after, then it's probably better to maintain the untitled document experience for the user (if you want one). I've found from experience, though, that the implementation of both approaches amounts to much the same code, just in different places. From an implementation perspective, neither is preferable to the other. ___ 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: NSDocument and Large File Import?
On Jun 20, 2013, at 13:07 , Karl Moskowski kmoskow...@me.com wrote: In fact, I think that will almost always be the case, so the link-to-an-external asset approach may not be practical. Anyway, would that approach work with Sandbox restrictions? What about potential iCloud sync in the future (forgetting for a moment the issues of file size)? It's not an external asset in this case. When you create the clone by hard linking, there are two independent files sharing the same disk storage. The clone file is in the document package normally. NSDocument already does hard-linking for files within a package which (according to the wrapper you return) haven't changed since the last save, assuming the file system supports it, so the mechanism is already compatible with sandboxing and iCloud. My point was, though, sort of the opposite. In your document save, you will necessarily need a mechanism to transfer the asset from an existing document package to a new document package. The problem of transferring an asset in a temp file to a package isn't really an additional burden, since it can likely use the same mechanism. If you haven't considered the normal save behavior (in the situation of a destination different from the source), then your save strategy is already broken, and you aren't ready to think about the creation behavior. ___ 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: NSDocument and Large File Import?
On Jun 20, 2013, at 14:22 , Karl Moskowski kmoskow...@me.com wrote: So, when importing the asset upon new document creation, actually import it to a temp directory, then upon save of the document, hard-link to the temp asset (via NSFileManager methods)? How would you delete the original hard link from the temp directory? Just delete the temp directory itself non-recursively? (I couldn’t find any unlinking APIs.) Even easier, you just delete the file. When you hard link, there's nothing at all unusual about the files (other than the fact they they are hard-linked to the same disk data). The data itself is, in effect, reference counted, so it won't disappear until the last file using it is deleted. In modern document-based apps, this would be via the “Duplicate” menu, right? That's one scenario Another scenario is when a new document has been autosaved, which is typically to a local hard disk, and then the user chooses a different volume when prompted to save on closing the window. I may have slightly overstated the case earlier. If your embedded asset file never changes after being created, they you likely won't have any code to clone it yourself, since the NSDocument default behavior does this for you. However, if you don't have an existing file wrapper to trigger this, as when the document is first created, you need to do the cloning yourself. ___ 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: UIDocument + NSFileWrapper crashes on opening
On Jun 20, 2013, at 14:37 , Markus Spoettl ms_li...@shiftoption.com wrote: OK, but isn't NSFileWrapper supposed to facilitate exactly that by providing sub-wrappers instead of actual data of contained files/folders, which can be read on demand when needed? No, NSFileWrapper provides *lazy* loading, in the sense that you don't need to load a file until/unless it's actually needed. It doesn't provide any mechanism for evicting file contents from memory -- not that I can find, and I looked hard. If you need to read all the files, they will all eventually be in memory. This is doubly irritating, because if the file contents is an archive, or otherwise needs to be converted or expanded, then both the raw data and unarchived data are in memory.** This is distinct from *incremental* loading, which loads the raw data in pieces and only temporarily. This cannot -- in practical way -- be done with NSFileWrapper. I spent a lot of time going round in circles about this, so I'm speaking up here in case I've missed something obvious, in which case someone will jump in and correct me. But AFAIK NSFileWrapper isn't the way to go for managed, incremental loading. ** What makes this acceptable in a lot of cases is that NSFileWrapper may read files by memory mapping them. This can perform as well as, or better than, a properly functioning cache, at the expense of using up additional VM address space. ___ 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: NSDocument and Large File Import?
On Jun 20, 2013, at 15:12 , Mike Abdullah mabdul...@karelia.com wrote: There should be no need to do this. If you need a location on disk for the document, just trigger an autosave so that the system effectively creates a temp location for you to use (-[NSDocument autosavedContentsFileURL]) In principle I agree this is a neat approach, but in practice I think it doesn't help that much. If you take this approach, you have to do the following steps before you can actually import your data: 1. Ask the user for the source of the data (assuming a file or URL is being used as the source of the data). 2. Create a NSDocument instance. 3. Go through the document startup sequence, including creation of the window controller. 4. Put special handling in the window controller to deal with the special case of having no imported asset file yet. 5. Start importing the data. 6. Display progress/cancel UI while import proceeds, and (likely) prevent the user from interacting with the document window until it ends. If you import to a temp file *first* you get rid of a lot of complexity of timing at the UI level, at the cost of having the document save know how to deal with an asset file that's a temp file. As I suggested earlier, you may have essentially that code in the save anyway. ___ 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: Confused by memory issue with UIDatePicker
On Jun 16, 2013, at 15:30 , Daniel Wambold wambo...@gmail.com wrote: I have a UIDatePicker in an .xib file with its File's Owner set to a custom class, MyTimeDatePickerVC. The MyTimeDatePickerVC inherits from UIViewController, and has an IBOutlet attached to the UIDatePicker. What does the IBOutlet declaration for the UIDatePicker look like? ___ 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: Confused by memory issue with UIDatePicker
On Jun 16, 2013, at 17:29 , Kyle Sluder k...@ksluder.com wrote: For this reason, that document recommends you use a weak declared property for outlets to non-top-level objects. You should probably follow that recommendation. Under the circumstances, since this is a manual RR app, just releasing the UIDatePicker [ivar] in dealloc might be a superior approach. If the UIDatePicker is a *top-level* object in the nib, the IBOutlet needs to be a strong reference -- unless there is some other guarantee that it will outlive the nib itself. If it's not a top-level object, then the lifetime of whatever is keeping it alive needs to be considered instead. In either case, using a strong reference seems more robust, since it doesn't involve reasoning about the lifetime dependences, at the slight cost of an explicit release. ___ 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: Confused by memory issue with UIDatePicker
On Jun 16, 2013, at 18:16 , Kyle Sluder k...@ksluder.com wrote: Meh. As a Mac programmer, your approach would indeed be my instinct, but I'm trying to train myself to be more modern. Better still, it occurred to me after posting, would be to use Refactor… to convert the app to ARC. That would be even more modern. I suspect it's easier to do this with an iOS app than with a Mac app, since iOS has fewer classes that have some ARC-related restriction. ___ 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: IB keeps changing my constraints when I resize the cell
On Jun 15, 2013, at 18:48 , Rick Mann rm...@latencyzero.com wrote: I can leave the view 23 pixels high, and adjust the outline view's row height, but I'd rather it size automatically in case I add views of a different heigh later. It doesn't work like that. A table cell view [prototype] has no predetermined height. Rather, a cell view is resized, just after being instantiated, for the row height of the row it was created for. Note that this means that the run-time height of each row must be known in advance of creating the cell view for the row. What you see in IB is the design-time height of the cell view, which is deduced from the design-time row height of the table view. For the simplest case, this matches the run-time row height, but this isn't necessarily so (if you programmatically change the row height, or if you're going to use a variable row height). So you should probably just adjust the row height. ___ 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: IB keeps changing my constraints when I resize the cell
On Jun 15, 2013, at 19:31 , Rick Mann rm...@latencyzero.com wrote: There's a setting for Automatic…where does it get it from then? AFAIK, it means the row height is set automatically based on the control size (small/medium/large). Also, is there no way, using bindings, and no delegate, to choose among multiple NSTableViewCell implementations? I thought the 2011 WWDC video said it was possible, but I didn't quite understand what it was referring to. Unfortunately, there's no straightforward pure-bindings example to look at. There's no way within the design-time table view itself. If the table uses bindings and there's no delegate, the column identifier is used to choose the cell view to instantiate, which can be the design-time cell view or a view in its own registered nib, but can't be varied by row. If you want to choose between cell views by row, you need to put each cell view in its own nib, register each nib with the table view under a unique identifier, then implement the 'tableView/outlineView:viewFor…' delegate method to decide which identifier to use. It's very easy to do -- all it needs is to invoke 'makeViewWithIdentifier…' with a suitable identifier. BTW, it can be much harder to vary the row height based on the cell view. You'd either need to cache all possible cell view heights in advance, or have a mechanism to calculate the cell view heights before view instantiation, or some combination of the two approaches. ___ 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: Multiple Observations
On Jun 14, 2013, at 13:06 , Gordon Apple g...@ed4u.com wrote: ³currentPath² property in doc gets set once. Observation gets dinged about 200 times. Removing the ³reloadData² didn¹t affect this. Same observer in another file gets dinged once, like it should. Stack trace always leads back to where currentPath is set in doc. Any theories on what could cause this observer to have diarrhea? If the stack trace indicates that the observation is triggered by the currentPath setter, then you're looking for your bug in the wrong place. The problem is (prima facie) that the setter is being invoked multiple times. The cause is further up the call stack. BTW, I hope your real code isn't (a) using a nil context and (b) failing the check the context in the observation method. ___ 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: NSNotFound signed???
On Jun 12, 2013, at 00:11 , Oleg Krupnov oleg.krup...@gmail.com wrote: I've just been shocked to find out that NSNotFound is defined by the framework as NSIntegerMax, that is maximal value of *SIGNED* integer, which in 64 bit architecture is 0x7fff. I used to think that it should be NSUIntegerMax, that is the maximal value of *UNSIGNED* integer, corresponding to 0x. It had to be so because NSNotFound value is used in many places of the system framework for working with array indexes, for example, -[NSArray indexOfObject:] returns unsigned NSUInteger indexes, *BUT* it returns NSNotFound if the element is not found. But NSNotFound should be a valid index in the middle of possible unsigned integer range! It means that even though the NSArray allows NSUIntegerMax of elements, you can actually use only NSIntegerMax elements, because starting from NSIntegerMax you will get screwed up by things like indexOfObject: How come? It's the only extreme-ish compile-time constant that's representable unambiguously in both signed and unsigned expressions. C has funny rules for conversions in compile-time expressions, so that makes using (for example) 0x treacherous in other ways. As long as you're aware of it, it's not a major problem in the NSArray case, since it would be extremely rare to actually want array indexes that don't fit into 63 unsigned bits, as opposed to 64. In particular, there isn't enough address space to create a NSArray containing even NSIntegerMax pointers. The easiest conceptual adjustment here is to think of NSUInteger as a 63-bit number, not a 64-bit number. Actually, the weird value for NSNotFound is not really the most treacherous aspect. Far more dangerous is the fact that it's not generally safe to archive (i.e. use the NSCoder protocol on) NSNumber objects whose value represents NSNotFound, because the value is architecture dependent. If you archive a 64-bit NSNotFound, it's no longer NSNotFound when unarchived on a 32-bit architecture, and vice versa. ___ 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: NSNotFound signed???
On Jun 12, 2013, at 00:42 , Quincey Morris quinceymor...@rivergatesoftware.com wrote: If you archive a 64-bit NSNotFound, it's no longer NSNotFound when unarchived on a 32-bit architecture, and vice versa. Oops, just to clarify: I don't mean there's anything wrong with the archiving or unarchiving per se. It's no longer NSNotFound when you encode/decode a NSUInteger/NSInteger variable, because there'll be truncation or incorrect sign extension of the scalar value, in one direction or the other. ___ 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: NSNotFound signed???
On Jun 12, 2013, at 01:14 , Oleg Krupnov oleg.krup...@gmail.com wrote: What if I have sparse array etc. One higher bit is actually twice as many elements. Why having NSUInteger at all if you can't use more than NSIntegerMax? This doesn't seem right. -- If you're talking about NSArray, there's no such thing as a sparse array. That's why NSNotFound == NSIntegerMax works -- it's a value you can *never* use as a NSArray index, *not* an artificial limitation on the range of indexes. -- The same is true for (non-sparse) C arrays. -- If you implement a sparse array yourself, and you want to use the full index range, then you likely wouldn't use NSNotFound as a marker at all. If you need a marker, you'd likely use 0 or NSUIntegerMax, right? ___ 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: Memory not being released in a timely manner
On Jun 10, 2013, at 08:23 , Jonathan Taylor jonathan.tay...@glasgow.ac.uk wrote: However, if I understand you correctly, you are convinced that the (large) backing buffer for the bitmap data should be being reported by Allocations. As you can hopefully see from these screenshots, while the NS objects themselves are being reported as live, the backing memory itself really doesn't seem to be showing up in Allocations (though the VM tracker knows about it. It's quite possible that the image files are being mapped into memory, rather than being read into allocated buffers. That would produce the results you've described (an increase in VM usage, but no big allocation footprint). ___ 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: creating temp files or temp folders in standard temp file locations in mdimporter on Mac OS X 10.8.3
On Jun 1, 2013, at 14:04 , Kyle Sluder k...@ksluder.com wrote: Spotlight importers run within a worker process; thus, they inherit the sandbox of the worker process, not the sandbox of your app (which might not even be running). The part of this line of thinking that I don't understand is why the worker process, whatever it is, shouldn't have access to a temporary directory of its own. The sample code tries to create a subdirectory inside the directory pointed to by NSTemporaryDirectory(). If this code is running in the context of an app sandbox, then there should be no problem creating a subdirectory in its temp dir. If the code is running in (say) a background worker process, then it should have its own temp dir, and there should still be no problem. All of which makes me wonder if NSTemporaryDirectory() just isn't available in the worker process, for some non-apparent reason. In that case, isn't there a Unix-ey temp dir to use instead (/var/something or /usr/something)? Or have I missed an essential step in your reasoning? ___ 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: creating temp files or temp folders in standard temp file locations in mdimporter on Mac OS X 10.8.3
On Jun 3, 2013, at 09:58 , Sean McBride s...@rogue-research.com wrote: NSTemporaryDirectory() is an old path-based API. Perhaps the newer URL-based APIs (URLForDirectory:inDomain:appropriateForURL:create:error:) might return a more appropriate temp directory... In this document: https://developer.apple.com/library/mac/#documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html (which was updated this year, so it shouldn't out-of-date, I'd hope), under the heading Container Directories and File System Access, there's list of places a sandboxed app can access: When you adopt App Sandbox, your application has access to the following locations: • The app container directory. Upon first launch, the operating system creates a special directory for use by your app—and only by your app—called a container. Each user on a system gets an individual container for your app, within their home directory; your app has unfettered read/write access to the container for the user who ran it. […] • Temporary directories, command-line tool directories, and specific world-readable locations. A sandboxed app has varying degrees of access to files in certain other well-defined locations. and then, under the heading Powerbox and File System Access Outside of Your Container: In addition [to locations made available via Powerbox], the system automatically permits a sandboxed app to: […] • Read and write files in directories created by calling NSTemporaryDirectory. Note: The /tmp directory is not accessible from sandboxed apps. You must use the NSTemporaryDirectory function to obtain a temporary location for your app’s temporary files. That seems to answer your comment (NSTemporaryDirectory() does seem to be the right API) and Kyle's last comment (sandboxing doesn't intrinsically disable file writing -- it merely restricts places where files can be written without entitlements to a few known locations). The deeper question is whether a spotlight worker process is running in an *app* sandbox at all, or whether it has some other kind of security context. Under the circumstances, I'd suggest that the OP should use a TSI to find out why NSTemporaryDirectory() doesn't work. ___ 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: What, exactly constitutes a mutable action on an instance?
On May 28, 2013, at 23:37 , Diederik Meijer | Ten Horses diede...@tenhorses.com wrote: 1. With ARC, do we still have to worry about string1 leaking in the following scenario? @property (nonatomic, copy) NSString *string1; ….. self.string1 = @Hello; string1 = @Hello hello; string1 = @Hello hello hello; No, you don't have to worry. When dealing with objects, ARC handles all retain/release correctly, regardless of whether the assignment is to the property or the ivar. That's kinda the point. 2. How do the strong, copy and weak keywords in the property declaration affect this? ARC still does the right thing, whether you use the ivar or the setter. The ownership keyword is multi-purpose (unfortunately, IMO): 1. It defines the ownership attribute of a synthesized ivar (or must match the ownership attribute of a manually declared ivar). For this, copy is the same as strong. 2. It defines the behavior of a synthesized setter. For this, copy makes a copy, everything else just does an assignment (with the appropriate memory management according to the ivar ownership attribute). 3. It declares the ownership attribute of the property itself, separately from the ivar. For this, strong and copy represent a strong property; weak represents a weak property; __unsafe_unretained represents no ownership. However, the property's ownership attribute has no actual effect on the compiler. Everything the compiler does via synthesis is covered under #1 and #2. Note that #1 and #2 are in truth private implementation details of the class. #3 is the public API contract, and communicates to clients of the class whether the property takes ownership of the property value. ___ 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: Building an MVC based App for Mac OS X - NOT for iOS
On May 28, 2013, at 10:01 , YT y...@redwoodcontent.com wrote: I did run a test and created a NEW Project and checked the box Create a Document-based App AND no Controller files (.h,.m) were automatically generated. Actually, two controllers *were* generated: 1. The app delegate. This object has the role of a controller, even though it starts out with nothing to do. Its controller behavior comes from code you add to it, as necessary. 2. The NSDocument subclass. These objects are also controllers. Which leads to the general mechanical problem of how does one create Controller files (.h,.m)? A MVC controller is just an object that behaves like a controller. It doesn't have to have controller in its name to behave like a controller. It can be of any class, and the class you choose depends on what it's supposed to do. Keep in mind that the MVC pattern is a very general pattern. A MVC controller is not the same as a view controller. Putting this another way, a view controller is a kind of MVC controller, but not the only kind. Similarly, a MVC view is not necessarily a view. Rather, it's a component of your app design that interacts with the user. It may be implemented as a window, or as a view, or as a window with a hierarchy of views, or something more complex. Translating a MVC design pattern into an implementation is messier on the Mac than on iOS. That's because the objects used on the Mac grew up over time. iOS's UIViews and UIViewControllers were based on Mac concepts, but tried to unify the loose Mac architecture into something more consistent and rational. ___ 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: NSSlider, NSStepper, and NSTextfield with Bindings: how to display initial value?
On May 28, 2013, at 13:16 , Paul Johnson p...@askerko.net wrote: I have a slider, a stepper, and a textField that are synchronized using bindings. I didn't write any code to do this, just used Xcode with its Interface Builder. When the program starts I don't see the slider set to the Current position I'd like and the textField doesn't show the Current value either. Is there something I can do within Xcode or do I need to add a line of code somewhere (in a -WindowControllerDidLoadNib: somewhere, maybe)? This usually happens because something in the keypath of the binding isn't KVO compliant. For example, if your controls are bound to model.myValue of File's Owner, and the model property doesn't get set until after the nib is loaded and it isn't set KVO compliantly, then your controls will see myValue as 0. If you can't spot a property that's obviously non-compliant, it's going to be necessary to take the key path apart property by property and verify that each is doing the right thing. Where is the initial value coming from? One of the values you set in the slider, stepper or text field in IB, or something else? ___ 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: Building an MVC based App for Mac OS X - NOT for iOS
On May 27, 2013, at 20:34 , YT y...@redwoodcontent.com wrote: Here is an extracted section I found the section of documentation you're referring to (it wasn't easy, you didn't give us much to go on). The short answer to your concern is that this piece of documentation is just plain wrong. If you need to add a view-specific controller, it should be a NSViewController, or a subclass, and not a subclass of NSController. NSController subclasses serve a different purpose -- they are mediating controllers, which is a respectable name for class-wrapped glue code. If you're coming from iOS, the nearest equivalent to UIViewController is NSWindowController -- *not* NSViewController, and certainly not NSController. When starting a new Mac app, the Cocoa classes you need to pay immediate attention to are: -- the app delegate (a custom class you define) -- if it's a document-based app, a NSDocument subclass -- for each window in your app a NSWindowController subclass In the broadest MVC terms, the C is often a NSWindowController subclass. The M is often the app delegate *or* a NSDocument subclass, or is a more specialized object graph to which the app delegate or document holds a reference. The V is the window and its contained views. However, it's a bit difficult to advise you more specifically on this without knowing whether your app is document-based or non-document-based. Stay away from NSViewController until and unless you find that you need it, and know why you need it. It isn't UIViewController. Rather, it's a sort of specialized NSWindowController, but for independently-loaded views instead of windows. ___ 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: CTFramesetterSuggestFrameSizeWithConstraints cuts off text
On May 17, 2013, at 06:38 , Koen van der Drift koenvanderdr...@gmail.com wrote: CGSize frameSize = CTFramesetterSuggestFrameSizeWithConstraints(framesetter, CFRangeMake(0, stringLength), NULL, CGSizeMake(self.bounds.size.width, CGFLOAT_MAX), fitRange); self.frame = CGRectMake(0, 0, self.frame.size.width, frameSize.height); // frameSize.height is too small I ran into this problem a while back, and after a lot of anguish I think I worked out what was going wrong. From an admittedly imperfect memory… 'CTFramesetterSuggestFrameSizeWithConstraints' sometimes returns a width that's *larger* than the width in the 'constraints' parameter -- wider than the view width in your case. So, with your existing code, when the string is eventually typeset and displayed, your view isn't wide enough for the text to line-wrap with exactly the same line breaks as it when you got the suggested frame size, and the text wraps with (generally) one extra line. The extra width in the returned value comes from hanging spaces -- spaces at the end of a line that don't count in the line's wrap width. For example, if you specify a constraint width of 350 points, and the width metric for a space is 5 points (in the font size being used), then the longest possible typeset line is actually 355 points. There may also be other typesetting situations, such as hanging punctuation, which produce similar results. This is correct behavior, because the non-space characters in the line are allowed to use all 350 points of the width. (Hanging punctuation may partially occupy some of the 350-point width, and partially extend past the end of the width.) Note that the larger width isn't *always* returned -- it depends how close the non-hanging characters of the longest line come to the constraint width -- so the problem appears to be intermittent. It's disputable, I guess, but I convinced myself it's correct to return a width 350, because the character that oversets the line may have a non-blank glyph -- even a space, when displaying text with a show invisibles option -- and so needs to be given a place to display. Therefore, you need to use the *returned* width for your CTFrame, instead of your view width. This will mean that the CTFrame may overhang the view on the right. In most cases this won't matter, since in most cases the overhanging glyph will be a blank space. Alternatively, you can pass a smaller width to 'CTFramesetterSuggestFrameSizeWithConstraints' -- for example: self.frame.size.width - (width of a space) -- to ensure that hanging characters have a place to display. But this is an awkward solution if you have a mix of fonts and point sizes in your attributed string. ___ 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: CTFramesetterSuggestFrameSizeWithConstraints cuts off text
On May 17, 2013, at 11:20 , Robert Vojta rob...@tapmates.com wrote: Height was wrong even if returned width = constrained width. Once I took proper account of the returned width, I got no more wrong heights. However, IIRC, there was a separate issue that fractional line heights didn't work correctly. Maybe you ran into that problem as well. ___ 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: sandboxing and filename extensions
On May 14, 2013, at 21:16 , Scott Ribe scott_r...@elevated-dev.com wrote: On 10.6.8, if I enter a plain filename without extension, the save panel returns the path with the extension appended. On 10.7.5, where sandboxing kicks in and this actually matters because the code cannot normalize the returned name, the save panel returns the path WITHOUT extension. Could you clarify a couple of things… Are you typing the file name into the Save panel, or just pressing Enter to use the pre-filled name? What are the settings for canSelectHiddenExtension and isExtensionHidden? What is the behavior on 10.8.3? I seem to recall noticing a change in behavior in some system version, where the save panel no longer added the extension when it was missing. This was either on the initial file name pre-filled in the panel, or on entering an extension-less name when the checkbox indicating isExtensionHidden was unchecked, or something like that. But my recollection on this is very hazy, sorry. Does it make any difference if you use the UTI for PDF files instead of the literal string PDF for the extension? We already know that the powerbox Save panel doesn't implement everything the regular one does, and it may have some limitations for non-UTI type strings. ___ 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: sandboxing and filename extensions
On May 15, 2013, at 08:31 , Scott Ribe scott_r...@elevated-dev.com wrote:
I guess about the only thing I can do here in order to get the file named in
a usable manner […] is to use a delegate, implement panel:validateURL:error:,
and force the user to type .pdf.
I don't believe this. If true, it would suggest that sandboxed Save panels are
so broken that no one could save anything without typing the correct extension.
In fact, I'm not seeing the behavior you describe. In an existing sandboxed app
of mine, there's an Export function that does the right thing. The code is like
this:
NSSavePanel* savePanel = [NSSavePanel savePanel];
savePanel.title = …
savePanel.prompt = …
savePanel.nameFieldLabel = …
savePanel.canCreateDirectories = YES;
savePanel.canSelectHiddenExtension = YES;
savePanel.allowedFileTypes = [NSArray arrayWithObject: @abc];
NSString* exportDirectory = …
if (exportDirectory)
savePanel.directoryURL = [NSURL fileURLWithPath:
exportDirectory];
NSString* exportFileName = [[self.document displayName]
stringByDeletingPathExtension];
exportFileName = [exportFileName stringByAppendingString: @ Export];
exportFileName = [exportFileName stringByAppendingPathExtension:
@abc]; // -- this
savePanel.nameFieldStringValue = exportFileName;
[savePanel beginSheetModalForWindow: [self.document windowForSheet]
completionHandler: ^(NSInteger result)
{
… savePanel.URL …
}];
(The line labeled -- this is, IIRC, the change I referred to earlier.
Originally, there was no need to supply the extension explicitly there, but
somewhere around 10.7, it became necessary.)
Because of canSelectHiddenExtension, my Save dialog has a Hide Extension
checkbox. If it's unchecked, and I retype the file name text box without an
extension, the checkbox turns itself on automatically. If I type the correct
extension, the checkbox turns itself off automatically. (If I type an incorrect
extension, the checkbox turns on. I assume I'd get something like
filename.def.abc in that case.)
No matter whether the extension is shown in the text field, the Save panel
returns a URL with the correct extension. I have no idea why you might be
seeing different behavior. Except …
On May 14, 2013, at 21:16 , Scott Ribe scott_r...@elevated-dev.com wrote:
[pnl beginSheetForDirectory: ...];
When comparing your code with mine, I realized that -[NSSavePanel
beginSheetForDirectory: …] was deprecated in 10.6. Try using one of the
non-deprecated methods. It *does* matter, with powerbox.
___
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: Document Window Versions Drop-down Menu
On May 14, 2013, at 00:07 , Vincent CARLIER vince.carl...@gmail.com wrote: Is there a way to put the menu on other windows too, is there any available API to do that ? All document windows should have the menu. My guess is that you forgot to invoke '-[NSDocument addWindowController:]' on the additional window controllers. ___ 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: Document Window Versions Drop-down Menu
On May 14, 2013, at 04:30 , Vincent CARLIER vince.carl...@gmail.com wrote: As you will see, the menu item opens a second (and any number) of windows for the document, but only the first has got the menu. Yes, now you've pointed this out, I can see the same (mis)behavior in my own apps. Whether it used to work and now doesn't, I can't recall. But it does look like a bug. ___ 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: Changing Subview Order Prevents Dragging
On May 13, 2013, at 19:41 , Graham Cox graham@bigpond.com wrote: When you call -removeFromSuperview, the view is deleted, as there are no more references to it. The other methods are not called because the object ceases to exist. I believe your warning is apposite, but is not actually the cause of Tom's problem. After removing the view, his code adds it back again. If the view had already been deallocated, you'd expect a pretty big crash pretty soon (though not necessarily immediately). My guess is that the removed view is still retained by something, but that removing a view from its window causes the mouse-dragging state machine to be reset. If so, immediately re-adding the view isn't going to restore the dragging state. I think the trick is to avoid removing the view from its superview. I'm not sure of the *best* way of doing this, but here are the things I'd try: -- Invoke 'addSubview: self' without first removing self. The NSView machinery may be clever enough merely to move the view to the end of the subviews array, without actually removing and re-adding it. -- Create a mutable copy of 'self.superview.subviews', move 'self' to the end of the mutable copy, then use 'self.superview setSubviews:' to establish the new order. Note that using 'setSubviews:' this way is explicitly called out in the NSView documentation as a way of reordering views. -- Use 'sortSubviewsUsingFunction:context:' with a suitable comparison function to move 'self' to the end of the subviews. Of course, it's still possible that any or all of the above will reset the dragging state, but they're certainly worth a try. P.S. The OP's issue is one reason why using many small, draggable views probably isn't a good design solution to the problem anyway. ___ 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: Changing Subview Order Prevents Dragging
On May 13, 2013, at 21:30 , Andy Lee ag...@mac.com wrote:
I believe ARC keeps it alive by virtue of self being a strong reference.
It isn't, not exactly. According to section 7.3 of the Clang ARC spec:
The self parameter variable of an Objective-C method is never actually
retained by the implementation. It is undefined behavior, or at least
dangerous, to cause an object to be deallocated during a message send to that
object.
This is the case when the receiver of the method invocation is itself a strong
reference. If it's actually a __weak reference, it *is* retained for the
duration of the method execution, because of the rules for retention of __weak
objects used in expressions.
I did a quick test and found that if I do
- (void) mouseDown: (NSEvent*) event
{
NSView* superView = [self superview];
[self removeFromSuperview];
//[superView addSubview: self];
}
...then dealloc does in fact get called. But if I uncomment that one line,
which references self, dealloc does not get called.
I suspect it works because the ARC implementation is suboptimal, in the sense
that it's causing self to be autoreleased as a result of being used in a later
expression. If the implementation ever improved to avoid using autorelease, I'd
expect it to start crashing in this scenario.
___
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: Window positioning and screen resizing
On May 13, 2013, at 21:58 , Rick Mann rm...@latencyzero.com wrote: In any case, it would be helpful to me to know. So try it with a random sampling of 20 window sizes and positions, and log the window and screen frames before and after the screen change. If you post the results here on this list, someone may spot a pattern. ___ 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: NSPersistentDocument Migration with Sandbox
On May 10, 2013, at 07:12 , Jerry Krinock je...@ieee.org wrote: I think that it would help to have a higher-level understanding of the problem. How about this… You have a sandboxed app in which the user has somehow opened a document outside your sandbox (because the user navigated to it in an Open dialog?). […] Have I stated this correctly? I don't think so. The *user* doesn't see files as being in or out of a sandbox. After all, the user isn't sandboxed -- your app is. By and large, *all* documents are outside an app's sandbox. Use of the Open dialog, or resolving a security-scoped bookmark, grants the app access to a document *as if* if it was inside the sandbox, but the document isn't moved in any way to get this access. An app wanting to migrate a document (including, say, a word processor converting an older document format into a newer one, or converting a format it only knows how to read into one it knows how to write) is eventually going to have to create a new file, and a sandboxed app is therefore going to have to ask for permission via the Save dialog. [I'm talking here of a migration that preserves the original file beside the migrated one.] In the case of Core Data, this means that a sandboxed app cannot use automatic migration, but must migrate manually. On May 8, 2013, at 21:20 , Jim McGowan jim_mcgo...@mac.com wrote: to hijack the migration process to display a save dialogue to get user permission for the destination URL […] creates a confusing user experience (opening a document shouldn't immediately present a save dialogue) Yet, failing to get permission via a save dialog would defeat sandbox security. Malware invading your app would be able to hijack the migration process to create any file it wants, anywhere on the user's system. It's not clear that interacting with the user must be confusing. You could start with an alert that explains that the document format needs updating, offering a Save button that leads to the Save dialog. Annoying, perhaps, but not necessarily confusing. There are a couple of other approaches that might be preferable to you. The question is how well (or if) they work with NSPersistentDocument: 1. Use post-Lion autosave elsewhere to migrate the Core Data store into a new untitled document in a temporary location. This would defer the Save dialog until the document window closes. 2. Put your Core Data store inside a file package. Then do the migration within the package. However, you likely wouldn't be able to use NSPersistentDocument any more, since it doesn't sound like it supports packages directly. 3. Migrate your Core Data store to a temporary file, then move the migrated file back to the original location, replacing the pre-migration file. Presumably, this is the same approach that NSDocument Save takes, but you'd need to implement it yourself, since NSPersistentDocument doesn't (AFAIK) do this. The replacement needs to be safely done (using the file system's exchange objects API), otherwise a crash or failure during replacement would effectively destroy the document. ___ 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: Cocoa-dev Digest, Vol 10, Issue 276
On May 7, 2013, at 11:12 , gweston gwes...@mac.com wrote: You're relying on a learned behavior that's difficult or impossible to invoke for an increasing chunk of your potential market. Is that really something you want to vehemently defend instead of thinking maybe it's *less* problematic to ask existing users - who may already be unable to use the keystroke anyway, regardless of how many years your program has been offering the option - to learn something different? Or maybe you just prefer to insult those who can't use your program to its fullest effect and those who want to help you change that fact. In this thread, there are three separate issues being conflated. I've quoted Greg, as an example of where this conflation leads, but I'm not picking on his response specifically. In fact, it's perfectly rational -- just a bit out of context, IMO. The issues are: 1. The software Steve is dealing with (Finale, I believe he has stated earlier) has special needs. I've used music notation software for note-by-note entry in the past, and it's a horrendous chore without some dedicated keys to assist. You can use a MIDI (piano) keyboard for dedicating keys to pitch entry, but you still need to use keys on the computer keyboard for duration (quarter notes, eighth notes, dotted notes, etc) entry. This used to be what the numeric keypad was dedicated to in Finale, and I guess it still is. It's no use saying that Steve needs to consider whether users *have* a numeric keypad. For users of music notation software that do a lot of note entry, it more or less necessary to have the MIDI keyboard (or to suffer a lot of pain), and it's not unreasonable to predict that such users might also acquire a numeric keypad, if their Mac doesn't already have one. Such software has already established the precedent that it needs lots and lots of keyboard shortcuts. (Finale is well over 10 years old, IIRC.) Steve isn't condemning users to a keyboard shortcut nightmare, he's continuing a well-established though specialized UI pattern. On this point I 100% agree with Steve's right to continue the tradition without molestation. 2. Cocoa doesn't do for shortcut display in menus what Carbon did, and Steve thinks it should. On this point I 100% disagree with his position, or at least his moral outrage. It might be that Cocoa doesn't implement what he's asking for simply because no one asked before, in which case the functionality may appear in the future. On the other hand, if Apple is reluctant to sanction *generally* that apps should make a distinction between numeric keys and numeric keypad keys, I think it's well within Apple's rights to limit the scope of its own frameworks to match such guidelines. In that case, I think Steve needs to quit whining that Apple engineers aren't doing his job for him, and implement his own menu drawing for his specialized case. 3. It's a question whether boxed numerals displayed in a menu are a *discoverable* design for presenting numeric keypad shortcuts to the user. On this issue, I tend to agree with the opinions expressed by Greg and Kyle that there's really no discoverable approach that will educate users directly from the menu appearance. (If this were on non-Mac computers, then a representation like Num 1 might be an acceptable solution, because non-Mac numeric keypads have a Num Lock key, which gives the user a clue. But that doesn't help with a Mac numeric keypad.) Under the circumstances, I think there's no good solution except directing users to the documentation or help or tutorial which makes the connection between the menu appearance and the corresponding keys. (Finale and similar apps used to come with a quick-reference card that showed this sort of information. I have no idea if it still does.) However, I don't see a problem in having a discussion on this issue. Someone may come up with a clever idea that even Steve likes. ___ 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: Existence of objects
On May 5, 2013, at 21:43 , YT y...@redwoodcontent.com wrote: In some thread an object is created with a set of methods. Lets call this object objA. Later in time another objected is created perhaps in another thread (not sure if this note is relevant). Lets call this object objB. Now objB needs to call a method in objA. Since objB came into being after objA how does objB detect that objA exists before attempting to call one of its methods? There's no magic here. If objB is to be aware of the existence of objA, there must be a reference to objA stored somewhere. (In fact, normally, there has to be a [strong] reference to objA store somewhere in order for objA to continue to exist. Otherwise, it's leaked or deallocated, depending on how you're handling memory management.) Usually, the reference to objA is held by some other object, whose existence is known to B. For example, most applications have an application delegate object that exists for the lifetime of the app, so this object could be designed to hold a reference to objA. If necessary, you can create a global variable to hold the reference to objA, but this would normally be done only if there were no context (that is, object graph) to which objA naturally belongs. ___ 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: Existence of objects
On May 5, 2013, at 22:24 , YT y...@redwoodcontent.com wrote: What I have is a view within the main window that is a Quartz 2D graphical thing and I want to have a set of UI elements that a user interacts with to change the graphical presentation. Well the UI elements are in the Delegate and the Graphical thing is in the view. The UI elements need to call methods in the view to change the graphical thing. What you've got is a MVC (model-view-contoller) pattern, which is very typical for Cocoa apps. The view is everything in the window, including the graphical thing and any controls (radio buttons, check boxes, etc) that the user interacts with to change the presentation of the graphical thing. The model is the information in the app delegate, the information that the graphical thing presents. What you need to add now is the controller. Typically, this is a NSWindowController subclass. This controller is responsible for holding references that allow the view elements to locate the model, and perhaps each other. The controller obtains a reference to the model from the app delegate, and has outlets (references) to any views it needs to access directly. The views find the controller via the nib's File's Owner, or via outlets of their own. The model shouldn't contain any direct references to views or other objects in the nib. Note that the settings controlling the graphical presentation *could* be in the app delegate, or they *could* be in the window controller. Often, the window controller is the best place for them. (Ask yourself this question: If I was ever to allow a *second* window onto the same data, and the user was to change the UI elements controlling the presentation, what should happen? Should the presentation change in both windows, or just in the one where they were changed? If the answer is both windows, you should keep the settings in the app delegate. If the answer is only the window where they were changed, you should keep those settings in the window controller.) ___ 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: Sorting a view based TableView with bindings
On May 2, 2013, at 00:31 , Gerriet M. Denkmann gerr...@mdenkmann.de wrote: When I click on the header nothing happens (except the current selection is set to none and the small triangle on the right side alternate between up and down). At a wild guess, I'd suspect you neglected to bind the table's Sort Descriptors binding to the array controller's sortDescriptors property. This probably happens automatically for a cell-based table view, but perhaps (like the Content binding) needs to be done explicitly for a view-based table view. What am I missing? Possibly that using bindings with a view-based table view is more trouble than it's worth? (I don't mean bindings to the cell view's objectValue. That's worth doing.) But I digress… ___ 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: NSOutlineView Travails
On May 2, 2013, at 14:52 , Corbin Dunn corb...@apple.com wrote: On Apr 17, 2013, at 2:09 PM, Quincey Morris quinceymor...@rivergatesoftware.com wrote: On Apr 17, 2013, at 10:50 , Gordon Apple g...@ed4u.com wrote: We are converting tables and outlines to view-based. So far, so good, on tables. But NSOutlineView has been a pain. First of all, there is no documentation on this, zero, zip, nada, zilch, in the NSOutlineView Reference. You have to rely on sample code and NSOutlineView.h. Yup, the documentation situation for NSOutlineView is awful. You should log bugs at bugreporter.apple.com asking for specific things you would like to see better. Please be specific; general statements like X is terrible don't help us know what you are wanting to know. A better thing would be to say I don't understand how to begin editing in NSOutlineView.. or it took me a long time to figure out XX, and it should be documented. Yes, I know. But Gordon already said the specific thing: there is no documentation on [view-based outline views], zero, zip, nada, zilch. This isn't just about programming guides. The delegate method 'outlineView:viewForTableColumn:item:' isn't even mentioned in the NSOutlineViewDelegate protocol reference documentation. Zero, zip, nada, zilch. Under the circumstances, I think it's a little hilarious to be asked to meticulously bug-report what will 'help us know what you are wanting to know. ___ 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: delaying forced sleep after initial 30 seconds delay
On May 2, 2013, at 21:16 , Nick Rogers roger...@mac.com wrote: I want my app to delay forced sleep even after requesting the initial delay of 30 seconds. This have to be specifically set by the user in the Preferences of the app and only when the user clicks a button to run some operation, for the duration of that operation which could extent to a minute or two. I know it would be against the mac os x design principles, but I think in the end it has to be the user's wish. I have seen my macbook pro sometime taking more than 2 minutes to go into sleep, after closing the lid. So is this possible at all? It's worth watching the 2012 WWDC session video on Power Management. The relevant APIs are here: https://developer.apple.com/library/mac/#documentation/IOKit/Reference/IOPMLib_header_reference/Reference/reference.html I don't see any reason to think this violates any Mac design principles. ___ 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: View Based Table - where is my data?
On May 1, 2013, at 08:34 , Gerriet M. Denkmann gerr...@mdenkmann.de wrote:
- (id)tableView:(NSTableView *)aTableView
objectValueForTableColumn:(NSTableColumn *)aTableColumn
row:(NSInteger)rowIndex
{
NSDictionary *aLine = self.dataArray[rowIndex];
NSTableCellView *cellView = [ aTableView makeViewWithIdentifier:
@DieSpalte owner: self ];
[ cellView.textField setStringValue: aLine[kNameKey] ];
[ cellView.imageView setImage: aLine[kImageKey] ];
NSLog(@%s %ld %@,__FUNCTION__, rowIndex, cellView);
return cellView;
}
This is wrong. You should not create a cell view in this method, and you should
not return a cell view as a result. The value returned from this method becomes
the the objectValue property of the cell view. Because you're trying to
create the cell view in the wrong place, the table view is creating one for you
(a different one), and that view isn't getting its text or image set to
anything useful.
Instead, you should be putting the above code in a
'tableView:viewForTableColumn:row:' delegate method. Since you're (apparently)
not using any bindings within your cell view, you don't need objectValue at all
-- neither the data source method nor the property.
___
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: View Based TableView - how to use bindings?
On May 1, 2013, at 11:52 , Gerriet M. Denkmann gerr...@mdenkmann.de wrote: The Array Controller has it's content bound to some array of dictionaries, which have the keys Name and Image. The table view's content is bound to Array Controller arrangedObjects. The only TableColumn is not bound to anything. The Image View of the Table Cell View has it's Value bound to Table Cell View objectValue.Image. The Static Text of the Table Cell View has it's Value bound to Table Cell View objectValue.Name. But still - the table remains empty. What kind of empty? Are there any rows? Can you select rows by clicking on them, even if their content is blank? Are you sure there aren't any exception or other messages in the Console log that you didn't see? You could try temporarily unbinding the image and text properties of the cell view, so that they should display whatever they're showing in IB. That might give a clearer idea of whether it's the binding from the table to the array controller that's at fault, or the bindings from the cell subviews to the cell view. Do you still have a 'tableView:objectValue…' method, or do you set objectValue in 'tableView:viewWithIdentifier…'? Neither should be necessary when using the table view binding to the array controller. Is your cell view a subclass of NSTableCellView, or something else? Are you trying to use the built-in (design-time) table cell view, or have you registered a nib to provide the cell views? Are you sure you're using the correct view identifier in 'tableView:viewWithIdentifier…'? Are you sure 'makeViewWithIdentifer:' isn't returning nil? Are you sure this is a table view issue, and not a KVO compliance issue with the property that's supplying the array controller content? There's lots that can go wrong here. :) ___ 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: View Based TableView - how to use bindings?
On May 1, 2013, at 12:52 , Gerriet M. Denkmann gerr...@mdenkmann.de wrote: Can't find the method: 'tableView:viewWithIdentifier…'. But makeViewWithIdentifier:... is never called. It was used in ...viewForTableColumn:... which was never called and has just been removed. I guess this is the root of the problem: I do not know where to call makeViewWithIdentifier. But do I need to? both things in the NSTableCellView have bindings already. The header comments for 'tableView:viewForTableColumn:' say: Bindings: This method is optional if at least one identifier has been associated with the TableView at design time. If this method is not implemented, the table will automatically call -[self makeViewWithIdentifier:[tableColumn identifier] owner:[tableView delegate]] to attempt to reuse a previous view, or automatically unarchive an associated prototype view. So you don't need the method (because you have bindings), but you need to make sure that the table column identifier matches the interface identifier of the prototype view. id g = [ self.arrayController arrangedObjects ];// _NSControllerArrayProxy NSLog(@%s arrangedObjects %ld ,__FUNCTION__, [g count]); prints 39 as expected. So the array controller is not empty. It also contains correct objects. Just bound the image to objectValue.AbsoluteNonsense and did not get any error messages. Is this normal? If it's not creating any cell views, there won't be any errors. I think you still need to find out whether it's the table view binding or the cell view binding that's failing. You could insert a line of code, after the table view is supposedly initialized, to query the number of rows and see if it's 39. Note that the fact that the array controller contains the right objects doesn't necessarily mean anything, if KVO compliance is messed up. It's a matter of timing, in that case, as to what results you get. You could try throwing in a 'reloadData' for the table, once you're sure the array controller has the right content, and see if that changes things. If so, you have a KVO compliance problem earlier in the initialization. ___ 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: Overlapping sibling views
On Apr 30, 2013, at 00:39 , Gideon King gid...@novamind.com wrote: My scenario is a whole lot of sibling, potentially translucent, overlapping, layer backed views. I've never seen any evidence that sibling *NSView*s draw in the wrong order since 10.5. I believe that 'drawRect:' is correctly called in the back-to-front order of the sibling arrangement in the parent view. However, I *have* seen firsthand, in the last few weeks, that the layers of siblings under a layer-backed parent view were composited in a random order. In my case, I had two sibling views, and I observed the bottom one displaying on top unpredictably, about 50% of the time. To be clear, the layers didn't get re-ordered randomly every time they were drawn. The random order was baked into the view or layer hierarchy as part of the view initialization, and didn't change subsequently as long as the view existed. So from my own experience, I'd agree there is a problem, but I don't know where the problem lies. It may be nothing to do with layers. Perhaps there's currently a bug loading nibs that randomly re-orders sibling views. Perhaps the sibling order in the layer hierarchy doesn't match the order in the view hierarchy. Perhaps the hierarchies are correct but the layer compositing operation is wrong. ___ 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: Overlapping sibling views
On Apr 30, 2013, at 08:55 , Mike Abdullah cocoa...@mikeabdullah.net wrote: On 30 Apr 2013, at 16:53, Gideon King gid...@novamind.com wrote: So it sounds as if as long as I have all my views in the entire hierarchy layer backed, my sibling views should always draw in order. Yup. Bear in mind WebViews don't support being layer-backed (still!), which can throw a spanner in the works. Nope. I just tried it again, setting the layer-backed checkboxes all the way up in IB, and it still fails sometimes (about 1 time out of every 20 or 30, today). ___ 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: Overlapping sibling views
On Apr 30, 2013, at 18:37 , Gideon King gid...@novamind.com wrote: How did you test it? Did you sort the views at all, or just leave them in the order they were instantiated? My hierarchy is very simple. The content view contains a single view (which layer-backed in order to use a background color), and that view contains two child views whose order is set in IB. I made no programmatic adjustments to anything. The only change from my original attempt was to make all of the views layer-backed in IB. Both child views are custom views, and they both return NO for isOpaque. I did, however, verify that the order of the child views was correct and hadn't been inadvertently switched somewhere in nib loading. The view order was correct. Did you try Sean's workaround? No, but I have no doubt it works as he says. ___ 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: Multiple untitled docs are saving to same file
On Apr 29, 2013, at 11:08 , Steve Mills smi...@makemusic.com wrote: We just noticed something that is wrong. When our saveToURL:ofType:forSaveOperation:completionHandler override gets called for NSAutosaveElsewhereOperation on two different untitled docs, the url is exactly the same, so the 2nd one overwrites the 1st. Why? How does Cocoa formulate the url for untitled autosaved files? The autosaves I've seen use a URL in a temporary directory (with, essentially, a random directory name), but it constructs the file/package name by using a standard name containing a number that's incremented until it finds the first one for which no file already exists -- (A document being autosaved by XXX) is the starting name, then (A document being autosaved by XXX 2), followed by 3, 4, 5, etc. Since you're not creating anything there, I conclude, it always thinks the starting name is available, and re-uses it. Keep in mind we have preservesVersions and autosavesInPlace both returning NO. We've overridden saveToURL so we can direct autosaves to a folder optionally set by the user. But the incoming url is the problem, before we've even touched it. You should generate your own unique file name, then. There's no value in preserving the incoming file name anyway, is there, since you're returning a different URL, right? ___ 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: Temporarily disabling autosave
On Apr 25, 2013, at 09:10 , Steve Mills smi...@makemusic.com wrote: Saving in place is not something most users expect, because it hasn't been done that way on all the common platforms. Uh, you can't make statements like that without citing evidence. Have you surveyed most users on this point? There are plenty of users to whom the idea of saving is itself unexpected -- because the [pre-Lion] need to save changes implied that your computer was otherwise going to discard your changes, and why would it do that For people with this mindset, needing to save explicitly is like some kind of punishment. I can't begin to count the number of times I've opened documents, edited them in some way, not intending to save those changes. Maybe I just needed to, say, find an image in a particular layer of some image editing app, so I hid some layers. That sort of thing. But doing something as simple as quitting means those changes will automatically change my actual document file without even asking if I want to discard them. That's just dangerous. You have this exactly backwards. Autosaving-in-place never changes the *saved* document file. It writes the autosaved document elsewhere. When you quit with an open, dirty document, there are two copies until you relaunch. At that point, your document is *still* dirty, and you can *still* close the document window explicitly, and you get a dialog asking if you want to save or discard changes (back to the point of the original save, which was before you quit and relaunched). Autosave-in-place was explicitly designed to avoid the problem you're complaining about! Remember, way back in this discussion, I said that the post-Lion saving behavior made sense only in its own terms, not in terms of the pre-Lion behavior. It sounds like your approach to this is stuck in pre-Lion terms, and so of course the new behavior seems wrong to you. ___ 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: Temporarily disabling autosave
On Apr 25, 2013, at 10:21 , Kevin Perry kpe...@apple.com wrote: Actually no—autosaving-in-place means exactly that changes are always saved to the main document file, hence in place. There is only ever a single file per document, even when quitting. Oops, I obviously got too focused on the autosave elsewhere part of this. However, I think the essence of my point was correct. Without activating the options added in Mountain Lion, if you quit with a dirty document and relaunch, it comes back as a dirty document. You've neither lost nor gained anything by quitting. In fact, IIUC, even if you don't quit, a timed autosave will also save the document in place, right? You can still discard your changes, if you wish, which seems to be one of the worries Steve had. Steve also seems worried that autosaved changes are visible to other apps using the same document, but that's a design choice of the post-Lion document architecture, with the whole coordinator/presenter mechanism to support it. Steve might validly be worried about the privacy implications of this behavior, but it seems over-alarmist to call it dangerous or dumbed-down. ___ 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: Preferences for network login
On Apr 19, 2013, at 22:46 , Graham Cox graham@bigpond.com wrote: Exactly, which is why I figured it must either mean something else here, or the user in question is confused... It's a network of iMacs we're talking about. https://developer.apple.com/library/mac/#documentation/Security/Conceptual/AuthenticationAndAuthorizationGuide/Authentication/Authentication.html AFAIK (which isn't very far, I admit) ActiveDirectory is LDAP, which OS X Server supports. ___ 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: Temporarily disabling autosave
On Apr 19, 2013, at 13:04 , Steve Mills smi...@makemusic.com wrote: This leads me to believe that the autosave dirty state is getting out of whack if the save doesn't happen as planned. Any ideas? a. When you get an autosave during playback, can you save the dirty state of the document, return a YES result but not actually autosave, then when playback stops, if you have this saved state, restore it (via NSChangeReadOtherContents or whatever)? The downside is that if your app crashes during playback, the pending changes are lost. b. At a higher level, force an autosave to occur just before playback starts, then don't let the document get dirtied till playback ends. c. If the autosave is asynchronous, you can just not return from it until playback finishes. Note, however, this does not prevent another autosave from arriving after some time interval, so you need to be careful that the second one doesn't step on the first one. (This autosave behavior is a bug, IMO, but it is the current behavior.) ___ 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: Temporarily disabling autosave
On Apr 19, 2013, at 14:39 , Steve Mills smi...@makemusic.com wrote: so autosave will happen again during playback You may have covered this ground already and I missed it, but what happens if you return NO from the autosave, along with a cancel error (that is, domain=NSCocoaErrorDomain code=NSUserCancelledError). On iOS, the document has a special save failed state, and I believe it will try again later. It's possible that something similar may occur on OS X. Or, if it just stops autosave cold, perhaps you can forcibly dirty the document again later. The point of returning a cancel error is that NSDocument tends not to report that particular error via a sheet. ___ 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: Preferences for network login
On Apr 19, 2013, at 22:18 , Graham Cox graham@bigpond.com wrote: what sort of network accounts are implied by 'AD' ? I assume AD == ActiveDirectory, which is a Microsoft thing. ___ 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: NSOutlineView Travails
On Apr 17, 2013, at 10:50 , Gordon Apple g...@ed4u.com wrote: We are converting tables and outlines to view-based. So far, so good, on tables. But NSOutlineView has been a pain. First of all, there is no documentation on this, zero, zip, nada, zilch, in the NSOutlineView Reference. You have to rely on sample code and NSOutlineView.h. Yup, the documentation situation for NSOutlineView is awful. Our outline view has a column/cell identifier ³LineNumber², one for ³CheckBox², one for ³Outline². Previously, the latter two were bound to our NSTreeController. Converting to views (yes, using outlineView:viewForTableColumn:item:), we could not even get the nib to load. ObjectValue always came up nil. We tried binding the tableView to the tree controller still nil. You can't try binding here. If you're using a data source, you don't bind the outline view to the tree controller, and in that case you need to set view.objectValue to the desired object before returning from 'outlineView:viewForTableColumn:item:'. Otherwise, you *must* bind the outline view's content binding to the tree controller, and the outline view should then maintain objectValue for you. (But since I always use data sources these days, I can't swear that this is precisely correct.) Ok, after examining sample code, we decided that just maybe there was something magic about the column/cell identifier ³MainCell², so we changed our third column/cell identifier and replaced @²Outline² with @²MainCell² in our code. Amazing now the nib loads. However, still no values. Since you're talking about loading nibs, I assume you've got code to register the nib, and I bet you forgot to ensure that the nib is registered with with the identifier that matches what you're actually using. If I remember the details correctly, you're going to invoke 'makeViewWithIdentifier:owner:' inside 'outlineView:viewForTableColumn:item:'. When you're using registered nibs, you must use the identifier that the nib is registered under, and the identifier assigned to the built-in cell view (that you're not using) is irrelevant. When you're using the built-in cell view, you must use its identifier, of course. The column identifier is basically unrelated, unless you *choose* to configure it to match the actual cell view identifier. The table view documentation assumes this is desirable, but I've never found it makes anything much easier. All it does is provide the opportunity for things to get out of sync, as you discovered. Even worse, the turn-down dingy appears in the first column, not the third where we want it. It does turn down the right number of times and depths to match our outline, but is in the wrong place and no values. So how do I get the outline back into the third column and get my objectValues to work? Are you sure you aren't inadvertently returning a group row view, or a full-row view? ___ 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
Semaphore strangeness
I'm not sure if this is the right list for this, but then I'm not sure what is the right list. I'm seeing a consistent problem disposing of GCD semaphores. For example, if I create a semaphore like this: semaphore = dispatch_semaphore_create (10); and then use if for a while, then try to destroy it (using ARC): semaphore = nil; If the semaphore's count is less than the original value (10 in the example), I get a EXC_BAD_INSTRUCTION crash: #0 0x7fff91fcfb5f in _dispatch_semaphore_dispose () #1 0x7fff91fcc898 in _dispatch_dispose () #2 0x7fff91fcc837 in -[OS_dispatch_object _xref_dispose] () 0x7fff91fcfb3e + push %rbp 0x7fff91fcfb3f +0001 mov%rsp,%rbp 0x7fff91fcfb42 +0004 push %rbx 0x7fff91fcfb43 +0005 push %rax 0x7fff91fcfb44 +0006 mov%rdi,%rbx 0x7fff91fcfb47 +0009 mov0x38(%rbx),%rax 0x7fff91fcfb4b +0013 cmp0x40(%rbx),%rax 0x7fff91fcfb4f +0017 jge0x7fff91fcfb61 _dispatch_semaphore_dispose+35 0x7fff91fcfb51 +0019 lea0xa8a6(%rip),%rcx# 0x7fff91fda3fe 0x7fff91fcfb58 +0026 mov%rcx,-0x17cbe317(%rip)# 0x7fff7a311848 gCRAnnotations+8 0x7fff91fcfb5f +0033 ud2aThread 1: Program received signal: 'EXC_BAD_INSTRUCTION' It's not clear to me why it should matter whether the original count has been restored. There's nothing waiting on the semaphore -- the operations that decremented the count have themselves be disposed of already. If I forcibly increment the count to 10 *or more*, there's no crash. ___ 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: NSOutlineView Travails
On Apr 17, 2013, at 18:08 , Gordon Apple g...@ed4u.com wrote: Our outlineView is not stable and it sometimes edits the wrong row. FWIW, the several times I saw instability and other odd behavior, it turned out I was doing something to the outline view on a non-main thread. The odd behavior didn't necessarily show up instantly. ___ 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: Semaphore strangeness
On Apr 17, 2013, at 17:06 , Greg Parker gpar...@apple.com wrote:
dispatch assumes you are using the semaphore in a lock-like pattern, where
all waiters are expected to signal when they are done with their work. In
that pattern, destroying a semaphore whose value is less than its original
value indicates a bug somewhere (because somebody should have signaled the
semaphore but has not yet done so). _dispatch_semaphore_dispose() is
enforcing that assumption and deliberately halting your process if it fails.
One example where the assumption doesn't hold is where the semaphore is
controlling access to AudioQueueBuffers for an AudioQueue. Calling
AudioQueueDispose suppresses further calls of the buffer release callback,
where the semaphore is signaled. After that, you don't get any outstanding
buffers back again, and your semaphore count is borked.
(If you try to use AudioQueueStop first, you then have to orchestrate a *wait*
for all outstanding buffers to arrive at the callback, for no other purpose
than satisfying the count requirement, before destroying the related semaphore.
This adds *harder* synchronization code to solve a problem that never really
existed.)
My assumption would be that, if you're destroying the semaphore, you're
shutting some procedure down, so you likely have taken care of the waiters
already. If you haven't, that's clearly a bug and they're going crash anyway
when they try to signal a nil ivar or an invalid semaphore. There's no point in
crashing at semaphore-disposal time.
Anyway, my workaround is now to signal the semaphore 'originalCount' times
before disposing of it.
On Apr 17, 2013, at 17:55 , Greg Parker gpar...@apple.com wrote:
There should be a message in the crash log.
if (dsema-dsema_value dsema-dsema_orig) {
DISPATCH_CLIENT_CRASH(Semaphore/group object deallocated while in
use);
}
I couldn't find one. Maybe the bad instruction crash was a failed attempt to
log this message?
___
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: Binding NSDictionary in NSArray into table view cell
On Apr 16, 2013, at 10:26 , Chris Paveglio chris_paveg...@yahoo.com wrote:
I've added an NSArrayController to the xib. Set it's contentArray binding to
my array. Then I selected a text box in my table cell where one of the
dictionary values would go. I set it's binding to BindTo:arrayController;
controllerKey:arrangedObjects; modelKeyPath:{key for the object in
dictionary}.
Yeah, this isn't going to work. It binds each row's text box to the *entire*
arrangedObjects array, which is not what you want.
If I understand your purpose, you need the Full Monty view binding procedure
described (if that's the right word for it) here:
https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/TableView/PopulatingViewTablesWithBindings/PopulatingView-TablesWithBindings.html
Basically, there are two parts to this:
1. You must explicitly bind the table view's content binding to
arrangedObjects. Note that this normally isn't done explicitly for cell-based
table views, but it's necessary in the view-based case.
That causes the table view to set the objectValue property of each
NSTableCellView to the correct object in arrangedObjects -- one of your
dictionaries, in your scenario.
2. You must bind the NSTableCellView subviews to the table cell item in the
binding popup, and use key paths of the form objectValue.key. That should
give you access to the value for key in the dictionary represented by
objectValue.
FWIW, I've never actually done part 1 of this myself -- I've used a data source
for every cell-based table view I've created -- but I've done part 2 several
times and it's straightforward once you get your head around the objectValue
concept.
___
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: Binding NSDictionary in NSArray into table view cell
On Apr 16, 2013, at 11:41 , Quincey Morris quinceymor...@rivergatesoftware.com wrote: for every cell-based table view I've created every *view*-based table view, I meant. ___ 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: Restoring unsaved docs does wrong thing
On Apr 15, 2013, at 13:49 , Steve Mills smi...@makemusic.com wrote: I have the following overrides in my NSDocument subclass: […] You didn't mention autosavesInPlace. This is the one to override if you don't want any (new-style) autosaving. The data was never saved anywhere, so opening a new document is the wrong thing for the OS to do. No, that's not true when autosavesInPlace is YES. In that case, if the app has a window open when it quits, it should and will open a window when it re-starts. If autosave has never completed, it'll be a new, untitled window. Having said that, things get a bit more complicated when you kill the app during debugging. It's a bit unpredictable what restorable state has been saved, and whether it'll successfully restore. You can turn off the Launch application without state restoration option in the Run action of the scheme, which make help you out during debugging, though that of course won't prevent the behavior in normal usage for your users. ___ 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: Restoring unsaved docs does wrong thing
On Apr 12, 2013, at 13:10 , Steve Mills smi...@makemusic.com wrote: If I have an unsaved doc open in my app (I mean one that has never been saved to disk), and I kill the app, upon relaunch, the OS attempts to restore that document, but it does so incorrectly. First of all, the data was never saved by the new Cocoa autosaving mechanism (we have our own and must use it for now). Second, it creates a new untitled doc by calling our document controller's openUntitledDocumentAndDisplay method. Why would it do that? A new untitled doc with nothing in it has *nothing* to do with what might've been an untitled doc with user changes in it. Here's how I believe it works: -- If you have an untitled document, but the document has not been dirtied before you quit, the restore mechanism will tell you to create an untitled document when you start up again. I think the rationale here is that there's no point in wasting disk space saving anything, but you do want the window to re-appear (with restored appearance) when the app re-starts.** -- If you have a dirty document, untitled or not, then it will always be autosaved before you quit -- *either* when the autosave timer elapsed, which might be anything from a few seconds to about 30 seconds, *or* just before quitting, if the timer hasn't fired yet. When you start up again, the documented will be opened in the usual way, and if it was previously untitled it will be untitled again. Either way, the document is *still* dirty. IOW: untitled + never dirtied -- no save or autosave on quit --create untitled on start untitled + clean -- no save or autosave on quit -- open autosave as untitled + clean on start saved + clean - no save or autosave on quit -- open save as saved + clean on start untitled + dirty -- autosave on quit - open autosave as untitled + dirty on start saved + dirty - autosave on quit -- open autosave as saved + dirty on start A regular [non-auto-]save is done only if the user explicitly asks it for using File menu--Save, etc.*** You have to keep in mind that the new document handling metaphor is *fundamentally* different from the old one. If you try to interpret its behavior in terms of the old metaphor, it will seem to be senseless and wrong. If you think in terms of the new metaphor, things do make sense, eventually. In this regard, I don't think Apple did us any favors by glomming the new behavior onto the old API. It would have helped a lot if there were a a NSModernDocument class that didn't bother with API compatibility. Also, what should I be overriding and returning in my document subclass to ensure that the OS autosaving never happens and prevent it from trying to create new docs on launch like this? You can just override autosavesInPlace to return NO, to turn off the new behavior. It's also possible that just overriding autosavesDrafts to return NO might disable the untitled document behavior, if that's all you need, but the drafts behavior is a bit hard to follow from the documentation. ** I ran into a complication here, in a situation where a new untitled document contained the result of an import. You have to dirty the document to force an eventual autosave, but using the recommended constant for the purpose (NSChangeReadOtherContents) didn't quite produce the correct results after a quit, re-start and explicit window close, IIRC. I think I had to use the undesirable NSChangeDone to get this to offer to save the untitled document in all cases. But it was a while ago, and tangled up with the mysteries of drafts, so I don't remember the details. *** If you need to know which kind of save is being done, I think the easiest way is to override one of the 'saveToURL:ofType:forSaveOperation:…' methods and look at the save operation. ___ 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: Anyone seen [NSCursor set] crash by calling abort()?
On Apr 11, 2013, at 11:57 , Sean McBride s...@rogue-research.com wrote: I have an executable which runs fine on 10.7.5, but when run in 10.8.3 crashes as below. This repros 100% on several machines. The cursor is created plainly: [NSCursor pointingHandCursor], it happens with [NSCursor crosshairCursor] too, but not with IBeamCursor nor arrowCursor! Is this by chance a garbage-collected app? ___ 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: UIView final frame after device rotation
On Apr 3, 2013, at 00:16 , Markus Spoettl ms_li...@shiftoption.com wrote: bounds and center are correct at all times. However, I need the view's frame in screen coordinates because I'm positioning an independent overlay window, not a subview. Since the transformation messes with -convertRect:from/toView: in my view hierarchy, I have no idea how to get to the frame I'm interested in. Any ideas? It might be easier just not to work with the frame at all. I suspect you can use 'convertPoint:…' on the center to get to the coordinate system you need for the attached view, then use that and the bounds to compute the attached view's center and bounds. ___ 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: UIView final frame after device rotation
On Apr 2, 2013, at 13:25 , Markus Spoettl ms_li...@shiftoption.com wrote: I'm displaying an overlay window which is attached to the view in question. When the rotation takes place, it needs to realign itself so that it's new location agrees with what the view displays (in my context). Isn't it a mistake to tie this to rotation? IIRC there are other reasons the root view might be resized (e.g. squished to make room for the status bar or not? notifications?). You probably want to adjust your child view location in those cases too. IAC you might be safer to avoid using the frame. If there's a transform involved in the view's rotation, then the frame property will be meaningless. (But IDK if there's actually a transform applied to the view during rotation, or whether there's just a rotating animation.) ___ 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: UIView final frame after device rotation
On Apr 2, 2013, at 14:21 , Markus Spoettl ms_li...@shiftoption.com wrote: Not sure if I understand what you're saying, but if that was the case, the view's frame I'm attaching the overlay to would turn out wrong if the device is rotated. No, once the rotation is complete (at least), there'd be no transform any more, and so the frame would then be valid. I looked at what happens when I rotate iBooks from portrait to landscape on an iPad (a +90 degree rotation), and this is what I see: 1. The view changes from portrait layout to landscape layout, but is displayed so the text is still in portrait orientation. In other words, the view behaves *as if* it immediately resizes to its final landscape orientation bounds, and is immediately displayed with a -90 degree rotation relative to landscape orientation, which preserves the original text orientation. 2. The view animates the rotation to landscape. That is, the view appears to animate its rotation smoothly from -90 degrees up to 0 degrees, relative to landscape orientation. (There may also be a scaling involved here, I couldn't quite tell since it all happens so fast. If there is one, it also ends at 100%.) 3. At that time, the transformation is the identity transformation. If the rotation notification is sent after step 1, the view frame is meaningless until step 3. The only time I get a bogus view frame is when the rotation notification is delivered. It would be easy to try examining the bounds and center properties at the time of the notification, and see whether *they* are bogus. If not, you should be able to orient your child view using those two properties, instead of using frame. ___ 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: Stubborn setValue:forUndefinedKey error
On Apr 1, 2013, at 13:16 , Koen van der Drift koenvanderdr...@gmail.com wrote: I am getting the following error when loading a viewController: *** Terminating app due to uncaught exception 'NSUnknownKeyException', reason: '[IDSelectionViewController 0x75bff50 setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key settingsTable.' I understand why this error can occur, but I am not using a 'settingsTable' at all. I do have a settingsTable in another viewController, but I have triple-checked that the correct File Owner is set in IB. It's not a question of the wrong target of the binding, but the wrong binding name in the originator of the binding. Select File's Owner in the nib, display the Connections inspector, and look under Referencing Bindings. That should show you an object bound using the binding settingsTable. ___ 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 Delegate - Using _delegate works but not delegate or [self delegate]
On Mar 26, 2013, at 10:30 , Chris Tracewell ch...@thinkcl.com wrote:
How can I get [self delegate] to recognize my custom methods?
There are two ways, one simpleminded, the other a bit sophisticated:
1. Use a local variable:
idTKOutlineViewDelegate delegate = [self delegate];
…
[delegate outlineView:self enterKeyPressedForRow:[self selectedRow]];
…
You'd need to introduce the local variable into each scope where you send the
delegate one of your custom messages.
2. Redeclare the delegate property:
@interface TKOutlineView : NSOutlineView {}
@property (nonatomic,readonly) idTKOutlineViewDelegate delegate;
@end
@implementation TKOutlineView
@dynamic delegate;
…
[[self delegate] outlineView:self enterKeyPressedForRow:[self
selectedRow]];
…
The @dynamic statement says I don't have an implementation of the 'delegate'
property in this class, but that's just fine because it's already implemented
(in my superclass).
Alternatively, you can avoid @dynamic by supplying an overriding implementation:
- (idTKOutlineViewDelegate) delegate {
return [super delegate];
}
but the @dynamic version is a bit more elegant.
With either alternative, this approach lets you avoid the clutter of the
additional local variables.
___
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 Delegate - Using _delegate works but not delegate or [self delegate]
On Mar 26, 2013, at 13:11 , Conrad Shultz conrad_shu...@apple.com wrote: If code expecting an NSOutlineView receives a TKOutlineView instance it may break or behave unexpectedly since it may well try to set a delegate conforming to NSOutlineViewDelegate but you have made your class require a delegate conforming to the more specific TKOutlineViewDelegate. Chris's delegate actually implements NSOutlineViewDelegate, doesn't it? Lee Ann's earlier suggestion of declaring TKOutlineViewDelegate to conform to NSOutlineViewDelegate would prevent any remaining compiler complaints. Thus the final declaration of the protocol would look like: @protocol TKOutlineViewDelegate NSObject,NSOutlineViewDelegate Would that take care of your concern? ___ 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 Delegate - Using _delegate works but not delegate or [self delegate]
On Mar 26, 2013, at 14:14 , Conrad Shultz conrad_shu...@apple.com wrote:
Step #1 in my hypothetical was that in the future a *required* delegate
method be added, in which case there would be no -respondsToSelector: check.
1. Your earlier suggestion of having *two* delegate objects would certainly be
one way of ensuring this couldn't be a problem.
2. If there is to be only one delegate object, the correct way (in terms of
ensuring compile-time compliance) would be to declare the subclass delegate
property override like this:
@property (nonatomic) idTKOutlineViewDelegate delegate; // making it
readwrite now
That is, any code setting a delegate would be required to provide one of the
correct sort. If desirable (and perhaps it would be under the circumstances),
this could be enforced at run-time by providing overrides, rather than using
@dynamic:
- (idTKOutlineViewDelegate) delegate {
idTKOutlineViewDelegate delegate = [super delegate];
if ([delegate conformsToProtocol: @protocol
(TKOutlineViewDelegate)])
return delegate;
else
return nil;
}
- (void) setDelegate: (idTKOutlineViewDelegate) delegate {
NSAssert ([delegate conformsToProtocol: @protocol
(TKOutlineViewDelegate)], @Boo boo);
[super setDelegate: delegate];
}
3. With one delegate object, if there's a legal scenario where some code might
think that the outline view was merely a NSOutlineView and therefore set a
delegate that was merely NSOutlineViewDelegate rather than
TKOutlineViewDelegate, then conformity to TKOutlineViewDelegate is effectively
optional. It would be incumbent, then, on callers of the TKOutlineViewDelegate
delegate methods to either check for conformity or to check respondsToSelector,
even for @required methods.
The correct approach requires knowing the answer to this question: Does
TKOutlineView *require* TKOutlineViewDelegate conformity, or is it merely
optional?
___
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: Pop Up Menu in NSTableView
On Mar 24, 2013, at 13:47 , Pascal Harris 45rpmli...@googlemail.com wrote:
Question 1. Is this possible, and am I even using the correct tool to do the
job?
It's certainly possible to use popup buttons in a table column.
It's questionable whether this is the right tool for this job. Popup buttons
aren't great at showing multiple selections -- except when their menu is
actually popped up, of course. It's irritatingly harder (though not exceedingly
hard) to force the button to display a title that isn't the same as the
(single) selected item.
And what title to display? That's a significant problem, especially if there
might be twenty [actions] in the future.
At the moment, my code looks like this (nothing is happening yet - I'm just
trying to see if I can get the toggle to work - and I can't):
- (IBAction)cellPreferenceChanged:(id)sender
{
[[sender selectedItem] setState:NSOnState];
}
cellPreferenceChanged is bound to the NSPopUpButtonCell in IB.
What do you mean by bound? Are you using a Cocoa binding, or do you just mean
you've connected the selector connection from the cell to some target?
Oddly, despite this binding, this code results in [NSTableView selectedItem]:
unrecognized selector sent to instance. Why is this? Surely, since it is
the NSPopUpButtonCell that is bound it should be the NSPopUpButtonCell
instance for the selected row that is sent?
I dunno, but table views do things to cells that you might not always expect.
If you set a breakpoint in your 'cellPreferenceChanged' method, what does the
backtrace look like?
___
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: Pop Up Menu in NSTableView
On Mar 24, 2013, at 14:50 , Pax 45rpmli...@googlemail.com wrote: You may be more successful if you use a view-based table rather than a cell-based table. One of the reasons we have view-based tables is to be able to avoid dealing with cells directly, in situations like this. However, if you've never used a view-based table before, the learning curve is fairly steep (though short). As to your second question, I've connected the selector connection from the cell to 'cellPreferenceChanged'. In my header I have: IBOutlet NSPopUpButtonCell* preferenceCell; - (IBAction)cellPreferenceChanged:(id)sender; and both are hooked up in IB. Ugh, it doesn't look right to set up an outlet to a cell like this. Table views deal with cells at two points: 1. When obtaining a cell for a given column. It uses the delegate method 'tableView:dataCellForTableColumn:row:' to get the cell, which may or may not be the one that's in the nib file. It does a certain amount of configuration of the cell after this method returns. 2. When preparing the cell for a drawing specific row. It uses the delegate method 'tableView:willDisplayCell:forTableColumn:row:', and does more configuration before this method is called. So, rather than keeping an outlet to a cell that might not be the one used in any given case, you should use one of the above delegate methods to find out which cell is actually being used. That's if you need to know the cell in your code, which is doubtful. As to the third, how do I find out? In Xcode, set a breakpoint in the action method. When you get to the breakpoint, go to the debugger console and type the bt command. That will give a backtrace you can copy and paste into an email. ___ 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: Pop Up Menu in NSTableView
On Mar 24, 2013, at 15:16 , Pax 45rpmli...@googlemail.com wrote: Ah. I shall have to look that up. Do you know of any good examples for view based tables? Not really. You can work through the Apple documentation: https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/TableView/Introduction/Introduction.html Much of the information is there, but it's woefully inadequate, particularly in regard to view identifiers, custom cell views, and bindings within cell views (as opposed to binding from cell views to the data model). As to the backtrace: That looks unsurprising. In particular, after the table view passed the mouse-down to the popup button, it didn't get involved again later. Are you sure the action method isn't being called twice, with different senders? With the breakpoint in place, you can do po sender in the debugger whenever it breaks, and the result will tell you the actual class of 'sender'. Then click the Continue button to see if you get to the breakpoint again. ___ 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: How to search the list archives?
On Mar 24, 2013, at 15:25 , John Bartleson jfbartle...@me.com wrote: How do you list denizens typically check to see if a problem has already been solved before querying the list? You can search via a mainstream search engine such as Google or DuckDuckGo by including 'site:lists.apple.com' in your query. CocoaBuilder is preferable, perhaps, because it displays search results as complete threads on a single web page. Unfortunately, CocoaBuilder has been offline at times in the last couple of years, and I'm not sure it's captured all of the list history. ___ 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: ARC Help
On Mar 22, 2013, at 11:34 , Chris Tracewell ch...@thinkcl.com wrote:
After ARC conversion it looks like
@interface TKObject : NSObject
{
NSString *__strong theString;
}
@property(readwrite,strong) NSString *theString;
My question is, couldn't it just as easily be written the same as the pre ARC
style sans assign in @property since strong is the default?
Yes, and it could just as easily be written sans readwrite since that's also
the default.
Note that you can likely just remove the ivar declaration completely, or at
worst move it to the @implemenation statement instead. There's really no need
to put a private ivar in a public interface file any more.
If you're going through the code cleaning things up, I'd also suggest you take
the trouble to add 'nonatomic' to your properties generally, or to add an
explicit 'atomic' in only those cases where atomicity is required and (for
custom accessors) actually implemented.
I noticed that in most of my files that the ARC conversion tool changes it
simply replaced properties with assign type with the strong and __strong
designators. However three files out of about 50 it just dropped the assign
form @property. Is there a difference or reason for this?
By chance, did those 3 files have the ivars for the properties synthesized --
not explicitly declared? There were some older compiler versions that
complained if the attributes on the property weren't the same as the attributes
on the ivar, even when they were effectively the same due to the defaults. It's
possible the conversion is being conservative for a reason like that.
___
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: ARC Help
(sorry, this turned into a tome)
The way properties are compiled has changed over time. Assuming you're using
the current (Xcode 4.6+) version of clang to compile your files, there is an
explicit 'atomic' attribute for properties. This has been around for some time.
(Keep in mind that out-of-date information never gets removed from
StackOverflow. It's a treacherous place to use as your primary source of
information.)
The purpose of the explicit 'atomic' keyword is so that you don't let
atomic/nonatomic default. There is a companion compiler option in the build
settings (Implicit Atomic Objective-C Properties) which you can set to YES to
get a warning when you don't specify either nonatomic or atomic.
The reason for this is not much about performance. ('atomic' is slower, but not
by much.) It's more about what happens when you write custom accessors. For
example
@property id someProperty;
- (void) setSomeProperty: (id) newValue {
_someProperty = newValue;
}
This is a bug, because you've declared someProperty atomic (by default), but
you didn't provide an atomic implementation. Secondarily, in the above example,
when there's no custom getter, the compiler will object that it can't
synthesize the getter. If you declare the property nonatomic, the compiler will
happily synthesize the getter for you.
At a different level, forcing yourself to specify nonatomic or atomic will help
you to remember whether you need the property to be atomic or not. If you make
it atomic, you are probably dealing with a thread synchronization issue. But in
many cases making the property atomic does *not* produce thread safe code, and
in many cases thread safe code doesn't need atomic properties. Properties that
truly need to be atomic are rare in most apps.
The current paradigm for declaring properties is like this:
@interface MyClass : …
@property (nonatomic) id someProperty; // or 'atomic' if that's what
you want.
@end
@implementation MyClass;
@end
The implementation uses auto-synthesis, which does three things:
1. It synthesizes the ivar that backs the property (with the name
_someProperty, with a leading underscore).
2. It synthesizes the getter.
3. It synthesizes the setter.
Note that if you synthesize explicitly like this:
@implementation MyClass;
@synthesize someProperty;
@end
the compiler does the same three things *except* that it synthesizes the ivar
with the name someProperty, without a leading underscore.
If you want to declare a private ivar yourself, you should do it in the
implementation and not in the interface:
@implementation MyClass
{
NSNumber* _someProperty;
}
@end
If you're writing your own getter and/or setter, none of the above changes.
Except for one thing. If you provide both a getter and a setter, the compiler
does *not* auto-synthesize the ivar. You must either declare the ivar
explicitly, as in the immediately preceding example, or with an explicit
synthesize:
@synthesize someProperty = _someProperty;
Be careful about whether the synthesize will put a leading underscore on the
ivar name. Because the rules have been in transition, it's easy to end up with
the wrong name, producing a hard-to-find bug.
___
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: Disable iCloud as a save destination
On Mar 7, 2013, at 14:28 , Ben ben_cocoa_dev_l...@yahoo.co.uk wrote: I have an iCloud-enabled document-based app which can export the document contents into various other formats. It cannot open these formats. Is it possible to disable iCloud as a destination in an NSSavePanel for these exported files? Is there a reason you can't examine the URL returned by -[NSSavePanel URL], and determine if it is (or is contained in) the URL returned by -[NSFileManager URLForUbiquityContainerIdentifier:]? Or, in a similar vein, use a save panel delegate to prevent such a URL from being chosen in the first place? Alternatively, you might be able to use NSURL's NSURLIsUbiquitousItemKey property to simplify the check for an iCloud URL, but it's not obvious from the documentation whether it gives the correct answer for a URL whose file doesn't exist yet. ___ 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: Documents not opening from Finder
On Mar 2, 2013, at 13:17 , Mills, Steve smi...@makemusic.com wrote: But I'm not calling runModalPrintOperation, nor do I want to, because we need to do something completely different at this point. This is the reason I'm overriding printDocumentWithSettings in the first place. I just need to know how to call the selector like I stated before. Take a look at this: https://developer.apple.com/library/mac/#releasenotes/Cocoa/AppKitOlderNotes.html and search for the heading Advice for Overriders of Methods that Follow the delegate:didSomethingSelector:contextInfo: Pattern. If the code sample makes your eyeballs hurt, I don't blame you. It's the kind of hackery that could be avoided with blocks, but this delegate/selector pattern pre-dates blocks. The other gotcha is that NSInvocation doesn't take ownership of any objects referred to by its arguments. That means being very careful when using ARC, since it can't memory-manage them for you. ___ 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: Documents not opening from Finder
On Mar 2, 2013, at 17:11 , Graham Cox graham@bigpond.com wrote: Unless you send -retainArguments to it, in which case it, well, does what it says on the tin. OK, but it's still a bit more complicated than that. Using the override code suggested in the AppKit release notes I linked to, you also have to deal with the management of the 'contextInfo' parameter, which is one of those awkward ARC cases. There are likely also some bridging casts needed, since the 'didSomethingSelector' and 'contextInfo' patterns both gloss over the difference between void* and id. So maybe what I should have said was that NSInvocation needs some hand-holding when used with ARC. ___ 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: Documents not opening from Finder
On Mar 1, 2013, at 13:59 , Steve Mills smi...@makemusic.com wrote: I have tons of experience with AppleEvents under Carbon, but none under Cocoa. Where does that event come in? I think the diversion into Apple Events is something of a red herring, at least at this stage of your debugging. Requests to open and print may indeed arrive at your app as Apple Events, but the best place to intervene is in NSApplicationDelegate protocol. By default, all such external requests should end up at one or other of the delegate protocol methods. If they don't get there, it seems likely the Finder isn't sending them. That wouldn't solve your problem, of course, but it would tell you that looking in your app's code isn't going to get to the solution. ___ 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: Documents not opening from Finder
On Mar 1, 2013, at 14:59 , Steve Mills smi...@makemusic.com wrote: Sorry, I still consider myself a newbie in Cocoaland. I can add those open and print overrides to my NSApplicationDelegate, but I only want to be able to set breakpoints on them but still let the default behavior happen. Since NSApplicationDelegate doesn't actually implement those methods, I can't simply call [super application:sender openFiles:filenames]; to get that default behavior. So what do I do? I need everything to work at least once in the normal way so I can then see which methods might not be getting called when things start going wrong. Well, yes, good point. Answers are buried in here: https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ScriptableCocoaApplications/SApps_handle_AEs/SAppsHandleAEs.html#//apple_ref/doc/uid/20001239 under the heading Apple Events Sent by the Mac OS. That brings us back to AppleEventland, in a sense, but the point is to pull out of this documentation the standard invocations of NSDocumentController or NSDocument methods, and use those in your app delegate methods. Unfortunately, this document appears to date from 10.4 times, but it should lead you to the information you want. In practice, you'll likely only care about providing 2 app delegate methods: 'application:openFile:' (or 'application:openFiles:') and 'application:printFiles:withSettings:showPrintPanels'. ___ 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: Convention for init with error
On Feb 27, 2013, at 13:12 , Brad O'Hearne br...@bighillsoftware.com wrote:
- (id)init:(NSError **)error;
{
self = [super init];
if (self)
{
if ([self operationThatMightFail:error])
{
*error = nil;
}
else
{
return nil;
}
}
return self;
}
The 'init' method pattern that returns nil and an error object works just fine
for me. FWIW, I've adopted the convention (for all my code, though of course
the frameworks APIs don't necessarily work this way) that an init method
*either* doesn't return nil:
- (id) init {
self = [super init];
NSAssert (self, @Initializer failed); // -- if super's init
isn't code I wrote; if it is I just leave this assertion out
…
}
*or* has an error parameter similar to your example. The advantage of this
approach is that it eliminates a lot of trivial checking for nil returns in the
caller, which has to create an error object anyway in order to get the error
presented to the user, but doesn't know what the error really was.
However, your code isn't quite right:
-- It's not necessary to set the output error value unless you return nil.
According to the usual pattern, callers should *not* expect anything in *error
(especially nil) if the method succeeded.
-- The usual pattern lets the caller specify NULL for the error parameter. If
you set the output value explicitly, you'd be wise to check for that.
Applying those 2 things to your code, you get this:
if ([self operationThatMightFail:error]) // -- rely on this to check
for error==NULL properly
return nil;
which is a whole lot more concise.
P.S. I agree with John's statement that a factory method is better (especially
with ARC) for your class's public interface, but even within the class
implementation you might not be able to avoid the need to return an error from
a private 'init'.
___
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: NSSavePanel problem
On Feb 24, 2013, at 09:10 , Kyle Sluder k...@ksluder.com wrote:
If that doesn't clear the problem, try launching your app with the Shift key
held down (or turn on Don't restore windows in your Debug scheme's editor,
or set the ApplePersistenceIgnoreState default to YES).
Good idea.
I'd also try using Apple menu - Recent Items - Clear Menu.
I'd also try switching the panel mode between column view and list view, and
navigating to a series of different folder without using the popup (and
clicking Save for each one), to push older recents out of the popup.
And if course, FILE A BUG! http://bugreport.apple.com. It could be that Apple
knows about this issue already.
Yes, and attaching a crash dump might provide sufficient information to isolate
the problem.
On Feb 24, 2013, at 01:26 , Peter Hudson peter.hud...@me.com wrote:
NSSavePanel *sp = [NSSavePanel savePanel];
[sp setTitle:@Save as HTML];
[sp setRequiredFileType:@html];
The last line of code is a bit suspect here.
'setRequiredFileType:' was deprecated in 10.6. You should be using
'setAllowedFileTypes:' instead. (If you target back to 10.5, you can use a
run-time check to decide which method to use.)
More importantly, given that the crash occurs in code that appears to be
deciding whether your app can open files with a certain extension, you could
change this last line to specify a UTI for html content ('kUTTypeHTML') rather
than an extension. UTIs are the *correct* solution.
___
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: NSFileManager createDirectory… confusing docs.
On Feb 23, 2013, at 07:57 , John Joyce dangerwillrobinsondan...@gmail.com wrote: The docs do not seem clear on this. (not to me anyway). Yes, they're not clear on this. If the directory you are creating is also considered an intermediate parent directory, that is just confusing. Presumably, it seemed like a good idea to someone at some time to treat the leaf directory consistently with the intermediate directories, when 'withIntermediateDirectories:' is YES. Or perhaps this was originally just a bug that was overlooked. Can anybody explain to me how this makes any sense? It makes sense as a historical behavioral artifact, but changing the behavior of the existing API might break existing code in hard-to-debug ways. I'd suggest you submit documentation feedback reporting the confusing description. It's likely not a high-priority issue, but OTOH it wouldn't be hard to improve the documentation. ___ 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: NSSavePanel problem
On Feb 23, 2013, at 18:12 , Andy Lee ag...@mac.com wrote: Also, to repeat part of Graham's question: is the window you're attaching the sheet to a floating window or a regular window? Maybe the sandboxing is irrelevant. How do you run it as a panel standalone - as opposed to as a sheet ? I don't remember the method name offhand, but you'll find it if you look at the docs for NSSavePanel. If you try it and the crash goes away, please let us know -- I'm curious. Peter didn't run it as a sheet. You can see in line 30 of the backtrace that his app invoked -[NSSavePanel runModal]. Also, according to the backtrace, the crash occurred in Cocoa frameworks (well, Apple frameworks, since it's in C++ code), so I wouldn't hare off looking for app memory management errors without any evidence supporting the idea. Rather, I think Graham's closer to being on the correct track. I've noticed that 10.8 NSSavePanel does have a tendency to explode, for reasons that are unclear. When it does that, it continues to explode until you find a way of getting it past the triggering condition. After that, it behaves properly until the next time. My guess is that 10.8 re-architected NSSavePanel (to better support sandboxing, but affecting non-sandboxing too) in such a way that there is persistent state stored outside the application. For that reason, quitting the app doesn't necessarily clear the problem. My guess is that in Peter's case the popup contains an entry that is no longer valid. It's possible that clicking the Save button without popping up the menu will clear it, or perhaps using the Save panel of a different application, or rebooting. Or possibly there's a preferences file that could be deleted. That's all speculation, but given the backtrace there's really no evidence the crash is Peter's fault. ___ 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
