Re: #selector noob question
Thanks for posting this extended answer!
On Mon, Mar 21, 2016 at 11:34 PM Quincey Morris <
quinceymor...@rivergatesoftware.com> wrote:
> On Mar 21, 2016, at 20:27 , Eric E. Dolecki wrote:
> >
> > Quick question. If I use #selector(funcName) - does it always send an
> > argument of the obj if the func requests it or not?
> >
> > If the function being called has a typed argument of something like
> > sender:UIButton, I can reference the sender in the func. Before with a
> > string we could add the ":" to inform that it would be supplied. Now is
> it
> > implied that it will be supplied?
>
> 1. The “:” was never optional, in the sense that you could choose whether
> or not to “add” it. Obj-C @selector(funcName) and @selector(funcName:) —
> “funcName” and “funcName:” in the previous Swift — are completely unrelated
> selectors. When performing the first of these selectors, there was never a
> parameter, and when performing the second there was always a parameter.
>
> 2. Selectors don’t send messages, selectors *are* messages. They are,
> approximately, polymorphic (class-independent) method names known to the
> runtime.
>
> When performing a selector, it has always been necessary to supply the
> correct number of arguments. It was an implementation detail of the Obj-C
> runtime that omitting or oversupplying parameters would not necessarily
> crash, and this fact could be exploited sometimes.
>
> 3. The new #selector syntax specifies the method by qualified name (via an
> expression that isn’t evaluated). For example:
>
> > import Cocoa
> >
> > let x1 = #selector (NSView.addSubview(_:))
> >
> > let v: NSView
> > let x2 = #selector (v.addSubview(_:))
> >
> > class A: NSView
> > {
> > let x3 = #selector (addSubview(_:))
> > }
>
>
> These 3 declarations specify the single-parameter addSubview method
> explicitly, by specifying the parameter keyword (_). They differ in the way
> they tell the compiler which class to consult to determine whether/how
> ‘addSubview:’ is declared.
>
> But Swift has additional source code forms. If it’s unambiguous which
> method is meant, you can just use the method name without keywords:
>
> > class A: NSView
> > {
> > let x4 = #selector (isDescendantOf) // OK because there is only
> one matching method
> > let x5 = #selector (addSubview) // ambiguous
> > }
>
>
> and you can use ‘as’ to specify the type of function, to distinguish
> between overloaded functions that have the same name and parameter
> keywords, but different parameter or return types.
>
> Note that x4 corresponds to Obj-C @selector(isDescendantOf:), not
> @selector(isDescendantOf).
>
> 4. Swift selectors are still polymorphic, so they aren’t tied to a class
> at runtime. For example, x1 above doesn’t mean “the selector for
> ‘addSubview:’ in class NSView". It means “the selector for method
> addSubview:, using NSView’s addSubview: method as a pattern to resolve any
> ambiguities”. You can still perform such a selector on any class that has a
> matching method, just like in Obj-C.
>
> 5. The problem being solved here is that in Obj-C the compiler can’t check
> that a selector is valid. There are two parts to this:
>
> a. It can only check that a method exists for a selector if a header file
> declaring that method is #imported into the current compilation.
>
> b. It cannot check the return type safely under any circumstances, leading
> to crashes when methods exist with the same selector but different return
> types.
>
> Swift solves the problem by requiring you to be explicit about which
> function signature the selector represents.
>
> ___
>
> 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/lutherbaker%40gmail.com
>
> This email sent to lutherba...@gmail.com
___
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: #selector noob question
Thanks for the answer. I am going to read it a few times.
Back to the original question - if an object has an addTarget, will calling
the non-string method name supply the object itself to the method?
On Tue, Mar 22, 2016 at 9:28 AM Luther Baker wrote:
> Thanks for posting this extended answer!
> On Mon, Mar 21, 2016 at 11:34 PM Quincey Morris <
> quinceymor...@rivergatesoftware.com> wrote:
>
>> On Mar 21, 2016, at 20:27 , Eric E. Dolecki wrote:
>> >
>> > Quick question. If I use #selector(funcName) - does it always send an
>> > argument of the obj if the func requests it or not?
>> >
>> > If the function being called has a typed argument of something like
>> > sender:UIButton, I can reference the sender in the func. Before with a
>> > string we could add the ":" to inform that it would be supplied. Now is
>> it
>> > implied that it will be supplied?
>>
>> 1. The “:” was never optional, in the sense that you could choose whether
>> or not to “add” it. Obj-C @selector(funcName) and @selector(funcName:) —
>> “funcName” and “funcName:” in the previous Swift — are completely unrelated
>> selectors. When performing the first of these selectors, there was never a
>> parameter, and when performing the second there was always a parameter.
>>
>> 2. Selectors don’t send messages, selectors *are* messages. They are,
>> approximately, polymorphic (class-independent) method names known to the
>> runtime.
>>
>> When performing a selector, it has always been necessary to supply the
>> correct number of arguments. It was an implementation detail of the Obj-C
>> runtime that omitting or oversupplying parameters would not necessarily
>> crash, and this fact could be exploited sometimes.
>>
>> 3. The new #selector syntax specifies the method by qualified name (via
>> an expression that isn’t evaluated). For example:
>>
>> > import Cocoa
>> >
>> > let x1 = #selector (NSView.addSubview(_:))
>> >
>> > let v: NSView
>> > let x2 = #selector (v.addSubview(_:))
>> >
>> > class A: NSView
>> > {
>> > let x3 = #selector (addSubview(_:))
>> > }
>>
>>
>> These 3 declarations specify the single-parameter addSubview method
>> explicitly, by specifying the parameter keyword (_). They differ in the way
>> they tell the compiler which class to consult to determine whether/how
>> ‘addSubview:’ is declared.
>>
>> But Swift has additional source code forms. If it’s unambiguous which
>> method is meant, you can just use the method name without keywords:
>>
>> > class A: NSView
>> > {
>> > let x4 = #selector (isDescendantOf) // OK because there is only
>> one matching method
>> > let x5 = #selector (addSubview) // ambiguous
>> > }
>>
>>
>> and you can use ‘as’ to specify the type of function, to distinguish
>> between overloaded functions that have the same name and parameter
>> keywords, but different parameter or return types.
>>
>> Note that x4 corresponds to Obj-C @selector(isDescendantOf:), not
>> @selector(isDescendantOf).
>>
>> 4. Swift selectors are still polymorphic, so they aren’t tied to a class
>> at runtime. For example, x1 above doesn’t mean “the selector for
>> ‘addSubview:’ in class NSView". It means “the selector for method
>> addSubview:, using NSView’s addSubview: method as a pattern to resolve any
>> ambiguities”. You can still perform such a selector on any class that has a
>> matching method, just like in Obj-C.
>>
>> 5. The problem being solved here is that in Obj-C the compiler can’t
>> check that a selector is valid. There are two parts to this:
>>
>> a. It can only check that a method exists for a selector if a header file
>> declaring that method is #imported into the current compilation.
>>
>> b. It cannot check the return type safely under any circumstances,
>> leading to crashes when methods exist with the same selector but different
>> return types.
>>
>> Swift solves the problem by requiring you to be explicit about which
>> function signature the selector represents.
>>
>> ___
>>
>> 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/lutherbaker%40gmail.com
>>
>> This email sent to lutherba...@gmail.com
>
>
___
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: #selector noob question
Okay - Xcode just finished installing and I got to see my code in situ with
fixable warnings.
myButton.addTarget(self, action: "selected:", forControlEvents: .TouchUpInside)
//above shows fixable warning. Changes to this:
myButton.addTarget(self, action: #selector(AudioElement.selected(_:)),
forControlEvents: .TouchUpInside)
I get it now that I can see what's going on with better context. I can also
just replace AudioElement with self.
On Tue, Mar 22, 2016 at 9:30 AM Eric E. Dolecki wrote:
> Thanks for the answer. I am going to read it a few times.
>
> Back to the original question - if an object has an addTarget, will
> calling the non-string method name supply the object itself to the method?
>
> On Tue, Mar 22, 2016 at 9:28 AM Luther Baker
> wrote:
>
>> Thanks for posting this extended answer!
>> On Mon, Mar 21, 2016 at 11:34 PM Quincey Morris <
>> quinceymor...@rivergatesoftware.com> wrote:
>>
>>> On Mar 21, 2016, at 20:27 , Eric E. Dolecki wrote:
>>> >
>>> > Quick question. If I use #selector(funcName) - does it always send an
>>> > argument of the obj if the func requests it or not?
>>> >
>>> > If the function being called has a typed argument of something like
>>> > sender:UIButton, I can reference the sender in the func. Before with a
>>> > string we could add the ":" to inform that it would be supplied. Now
>>> is it
>>> > implied that it will be supplied?
>>>
>>> 1. The “:” was never optional, in the sense that you could choose
>>> whether or not to “add” it. Obj-C @selector(funcName) and
>>> @selector(funcName:) — “funcName” and “funcName:” in the previous Swift —
>>> are completely unrelated selectors. When performing the first of these
>>> selectors, there was never a parameter, and when performing the second
>>> there was always a parameter.
>>>
>>> 2. Selectors don’t send messages, selectors *are* messages. They are,
>>> approximately, polymorphic (class-independent) method names known to the
>>> runtime.
>>>
>>> When performing a selector, it has always been necessary to supply the
>>> correct number of arguments. It was an implementation detail of the Obj-C
>>> runtime that omitting or oversupplying parameters would not necessarily
>>> crash, and this fact could be exploited sometimes.
>>>
>>> 3. The new #selector syntax specifies the method by qualified name (via
>>> an expression that isn’t evaluated). For example:
>>>
>>> > import Cocoa
>>> >
>>> > let x1 = #selector (NSView.addSubview(_:))
>>> >
>>> > let v: NSView
>>> > let x2 = #selector (v.addSubview(_:))
>>> >
>>> > class A: NSView
>>> > {
>>> > let x3 = #selector (addSubview(_:))
>>> > }
>>>
>>>
>>> These 3 declarations specify the single-parameter addSubview method
>>> explicitly, by specifying the parameter keyword (_). They differ in the way
>>> they tell the compiler which class to consult to determine whether/how
>>> ‘addSubview:’ is declared.
>>>
>>> But Swift has additional source code forms. If it’s unambiguous which
>>> method is meant, you can just use the method name without keywords:
>>>
>>> > class A: NSView
>>> > {
>>> > let x4 = #selector (isDescendantOf) // OK because there is only
>>> one matching method
>>> > let x5 = #selector (addSubview) // ambiguous
>>> > }
>>>
>>>
>>> and you can use ‘as’ to specify the type of function, to distinguish
>>> between overloaded functions that have the same name and parameter
>>> keywords, but different parameter or return types.
>>>
>>> Note that x4 corresponds to Obj-C @selector(isDescendantOf:), not
>>> @selector(isDescendantOf).
>>>
>>> 4. Swift selectors are still polymorphic, so they aren’t tied to a class
>>> at runtime. For example, x1 above doesn’t mean “the selector for
>>> ‘addSubview:’ in class NSView". It means “the selector for method
>>> addSubview:, using NSView’s addSubview: method as a pattern to resolve any
>>> ambiguities”. You can still perform such a selector on any class that has a
>>> matching method, just like in Obj-C.
>>>
>>> 5. The problem being solved here is that in Obj-C the compiler can’t
>>> check that a selector is valid. There are two parts to this:
>>>
>>> a. It can only check that a method exists for a selector if a header
>>> file declaring that method is #imported into the current compilation.
>>>
>>> b. It cannot check the return type safely under any circumstances,
>>> leading to crashes when methods exist with the same selector but different
>>> return types.
>>>
>>> Swift solves the problem by requiring you to be explicit about which
>>> function signature the selector represents.
>>>
>>> ___
>>>
>>> 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/lutherbaker%40gmail.com
>>>
>>> This email sent to lutherba...@gmail.com
>
Re: NSThread to NSOperation and blockUntil
> On Mar 22, 2016, at 2:33 AM, Trygve Inda wrote: > > So I need to be able to have a process done in 30 seconds for example At > full speed it could be done in 4 seconds but I'd like it done with as little > impact as possible. I don’t think it makes much difference to other system threads whether your thread takes 4 seconds or 30 to complete. Modern computers are almost never starved for CPU resources since they have a lot of cores and the OS is very good at fast context switching. On my MBP the only time the CPU meter fills up all the way is when Xcode is doing a clean build of a project, and even then I don’t notice other apps slowing down. If you’re really worried, you can use that background quality-of-service level on your thread/queue, and the OS will just put your thread on ice while other threads are contending for all the CPU cores. The resources that are more often limited are RAM and I/O. So it makes _much_ more of a difference to the rest of the system if your task uses a lot of memory or reads/writes a lot of data. In that case it could be advantageous to slow it down artificially, although you might get more bang for the buck by trying to optimize the algorithms to use less memory or I/O. —Jens ___ 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: #selector noob question
On Mar 22, 2016, at 07:21 , Eric E. Dolecki wrote: > > myButton.addTarget(self, action: #selector(AudioElement.selected(_:)), > forControlEvents: .TouchUpInside) > I get it now that I can see what's going on with better context. I can also > just replace AudioElement with self. It’s slightly better than that. Since ‘self’ is the observer, ‘selected(_:)’ is one of its own instance methods, so you don’t need to specify the class or ’self': > #selector (selected(_:)) If in addition the name of the method (selected) is unambiguous within the class of ‘self’, you don’t need to specify the parameters either: > #selector (selected) This doesn’t mean it doesn’t matter whether there’s a parameter or not, just that the Swift compiler can figure it out for you if you point it in the right direction. ___ 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: NSThread to NSOperation and blockUntil
> On 22 Mar 2016, at 5:33 PM, Trygve Inda wrote: > > So I need to be able to have a process done in 30 seconds for example At > full speed it could be done in 4 seconds but I'd like it done with as little > impact as possible. So just let it run as fast as possible. The whole point of threads is to let them work as hard as they need to and the scheduler will take care of giving other stuff the time they need. If the work is self-contained, in that it isn’t blocking other code, you won’t even notice it. It sounds like you’re trying to optimise based on faulty reasoning. —Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: UIDocument with NSFileWrapper
I don't claim this is the one right way, but I think it makes sense based on the little bit of documentation there is for NSFIleWrapper and it seems to work. My situation is complicated because my document consists of multiple files. UIDocument is pretty simple if you only need a single data file to store all your data. I'll post an update if I find anything else out, but I may start prototyping some other parts of that app before coming back to this again in a month or so. Dave Reed > On Mar 21, 2016, at 9:02 PM, Luther Baker wrote: > > Thanks for posting this. Exploring UIDocument and caching/parsing JSON > instead of CoreData for a service based mobile app that must support offline > mode ... and looking forward to considering where you landed. > On Mon, Mar 21, 2016 at 5:11 PM wrote: > > > On Mar 21, 2016, at 2:08 AM, Quincey Morris > > wrote: > > > > On Mar 19, 2016, at 18:54 , davel...@mac.com wrote: > >> > >> What I’m having trouble understanding is how I store the images (whose > >> filenames will vary from document to document) with NSFileWrapper. In my > >> top level directory do I have my main model file as a JSON file along with > >> a file (JSON or plist) that lists all the images and then have an Image > >> directory that another NSFileWrapper is used to read/write the images > >> (that are stored in the Image subdirectory)? > >> > >> Or can I simply store all the files without a subdirectory? I still > >> suspect I need to have a file with a fixed name (such as image.plist) that > >> tells me what all the other filenames are to put in the NSFileWrapper (vs. > >> using NSFileManager to ask for the name of all the files). > > > > There’s no correct answer to these questions. It’s a design problem whose > > answer is whatever works best in your use case. I’d recommend you start by > > choosing what looks to you like the most straightforward approach, then be > > prepared to revise your strategy later if it doesn’t work out well. (The > > amount of code relating to file wrappers is likely to be small relative to > > the code that generally maintains your data model, so rewriting it > > shouldn’t be onerous. However, that suggests it would be prudent not to let > > the wrappers propagate too deeply into the model. Keep them as an artifact > > of the save mechanism in particular, rather than the data model in general.) > > > > Ok, thanks again for all your feedback. I took a stab at implementing it > yesterday. Everything is in my subclass of UIDocument. The rest of the model > is a layer below the UIDocument subclass (i.e., the subclass has a couple > instance variables which are the main model) although I did put a few methods > in the UIDocument class to add the images since that needs to change the > NSFileWrapper. > > I think I've got it working. Here is how I did it (in case this helps anyone > else and in case anyone else sees a problem with this). > > UIDocument subclass has a NSFIleWrapper instances for each of these: > > 1. Top level NSFileWrapper directory wrapper. > 2. It contains a directory wrapper for a subdirectory named Images where all > the image files (that won't be updated often go). I put the method to add an > image here so that it could update the NSFileWrapper > 3. a NSFileWrapper that contains a single file that is a list of all the > image filenames that is added to the top level NSFileWrapper > 4. a NSFileWrapper for the rest of the model that will change often and is > added to the top level NSFileWrapper > > Whenever an image is added, I remove the NSFileWrapper in #3 from the top > level file wrapper, created a new NSFileWrapper with the new list of images, > and then add that to the top level NSFileWrapper. And add the image file to > the NSFileWrapper in #2. It appears you must call removeFileWrapper on the > top level NSFileWrapper and then add the new NSFileWrapper with > addFileWrapper rather than just calling addFileWrapper with the same > preferred filename and replacement NSFileWrapper. Similarly with my #4 main > data model file, I call removeFileWrapper and addFileWrapper each time a save > occurs since this data changes frequently. > > Since images won't be added as often as the rest of the model is updated, I'm > hoping this won't cause these images to be re-written every time a save is > performed but I'm not certain how to verify this is the case. > > Thanks, > Dave Reed > ___ 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 woes
> On 21 Mar 2016, at 5:02 PM, Quincey Morris > wrote: > > On Mar 20, 2016, at 20:20 , Graham Cox wrote: >> >> This is driving me insane! > > a. Can you produce a test project that demonstrates the behavior? (Preferably > not via drag-and-drop, since that’s so much harder to debug.) > > b. It’s not the actual problem, but I wonder why you construct the needed > parent-relative index set by using ‘rowForItem:’? I may be wrong, but I don’t > think we can assume that NSOutlineView keeps references to all or any subset > of the universe of items in the list, so it may have to walk the rows > starting from the root item, and this certainly opens the possibility of > dicey behavior if your data structures are in the process of being changed. I > certainly wouldn’t assume it can find the row more efficiently than you can > find the child index. Since you know the child, you know the parent, so you > can find child index by iterating linearly through the parent’s children > yourself. > > c. There’s also a logic issue here. It’s not clear whether you’re making a > mistake, or the mistake is only an apparent consequence of the way you’ve > described your methodology: It is incorrect, in general, to compute the child > index by subtracting the child row from the parent row, because there may be > intervening children which themselves have children. > Thanks for the help (on and off list) everyone - I managed to knock it into some sort of working shape. In the end I was able to use the ‘move’ variant of the animation by setting a flag to supress the response to the delete/insert operations. This is admittedly a little hacky but does work in all the test cases I was able to dream up. I also simplified the code in a few places to not rely on assumed internal states of the outline view and things got better. Overall it’s probably not the perfect solution, but it works and allows me to move on to other problems. —Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Multiple AVAudioPlayer - locking main thread?
> On Mar 18, 2016, at 1:10 PM, Eric E. Dolecki wrote: > > I have audio buttons, each with it's own associated AVAudioPlayer > > Any ideas about the main thread lockup? Rather than just looking at memory usage, look at what's actually taking up the time on the main thread. Use a time profile in Instruments. That's where you're going to find the best indication of what's going on. -- Seth Willits ___ 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
IKImageBrowserView bug?
Hi all, I just upgraded to 10.11.4 and XCode 7.3 and therefore the latest SDK. Rebuilding my app, my one instance of IKImageBrowserVIew in my app has gone haywire. Whenever I load new images into it, it scrolls constantly to the bottom of the view. If I manually scroll it elsewhere, it scrolls back to the bottom when I let go. This has worked fine for years, and while I am looking at some new code in this class (and hence have triggered a new compilation of the sources), the new code has no bearing on this issue. Has anyone else seen this, and if so, what’s the cause/fix? As it stands, the class is unusable. —Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Creating NSXMLDocument programmatically
I'm building an XML tree from an XML file which is XML 1.1, so has character references that NSXMLDocument cannot handle natively. So, I'm working with a modified version of the Expat parser and building the tree as I go. The problem: How do I associate a DTD with the document? setDTD: became unavailable in 10.10, but there appears to be no replacement. I'm still running Xcode 7.0.1, so maybe there's something newer that I can't see, but a Google search doesn't turn it up. Using addChild: raises an exception, so I'm wondering if there is any way to do this now. Thanks for any pointers. John -- John Brownie, john_brow...@sil.org or j.brow...@sil.org.pg Summer Institute of Linguistics, Ukarumpa, Eastern Highlands Province, Papua New Guinea Mussau-Emira language, Mussau Island, New Ireland Province, Papua New Guinea ___ 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 NSXMLDocument programmatically
On Mar 22, 2016, at 19:46 , John Brownie wrote: > > setDTD: became unavailable in 10.10, but there appears to be no replacement A number of redundant “freestanding” getter/setter method declarations were removed from the SDK, but the DTD property remains. You should be able to set it that way. ___ 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 NSXMLDocument programmatically
___ 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
