Hi,
I’m overriding printDocumentWithSettings in order to get a notification for
when printing has finished, but the didPrint selector is never called.
This is the code:
class func document(document: NSDocument, didPrint: Bool, contextInfo:
UnsafeMutablePointer)
{
print("document was pr
Sorry - I forgot to copy to the list.
Jeremy
--
> Begin forwarded message:
>
> From: Jeremy Hughes
> Subject: Re: didPrint selector not called
> Date: 16 December 2016 at 19:15:10 GMT
> To: John McCall
>
>> On 16 Dec 2016, at 17:24, John McCall wrote:
>>
can call through to. I suppose it
would apply if I had a subclass (of my document class) that needed to override
the callback. Does that seem right to you?
Jeremy
--
> On 16 Dec 2016, at 18:26, Quincey Morris
> wrote:
>
> On Dec 16, 2016, at 08:45 , Jeremy Hughes wrote:
>>
> On 16 Dec 2016, at 19:29, John McCall wrote:
>
>> On Dec 16, 2016, at 11:24 AM, Jeremy Hughes
>> wrote:
>> Thanks for the link.
>>
>> I’ve looked at it, and I don’t think it applies in this case, because I’m
>> not actually overriding the docu
Also, NSInvocation (used in the release notes sample code) is unavailable in
Swift.
Jeremy
--
> On 16 Dec 2016, at 19:33, Jeremy Hughes wrote:
>
>>
>> On 16 Dec 2016, at 19:29, John McCall wrote:
>>
>>> On Dec 16, 2016, at 11:24 AM, Jeremy Hughes
&
>> OK - I misunderstood what Quincey was saying.
>>
>> The passed-in delegate and selector are nil, but I obviously can’t be sure
>> that they will always be nil.
>>
>> All I’m actually trying to do is to clean up some objects that need to exist
>> during the print operation. Is this the best w
> On 16 Dec 2016, at 20:01, Jeremy Hughes wrote:
>
>>> OK - I misunderstood what Quincey was saying.
>>>
>>> The passed-in delegate and selector are nil, but I obviously can’t be sure
>>> that they will always be nil.
>>>
>>> Al
> On 16 Dec 2016, at 20:17, Jeremy Hughes wrote:
>>> I'm not an expert in this part of Cocoa. Are there implicit system
>>> *callers* of this method, or is it more of a system *utility* that you're
>>> expected to call from your own code? If it&
> This is what I’ve currently got. It works OK, but the dictionary conversion
> seems clunky to me.
>
> override func printDocument(sender: AnyObject?)
> {
> let didPrintSelector = #selector(document(_:didPrint:contextInfo:))
>
> let dictionary = printInfo.dictionary()
>
> On 16 Dec 2016, at 21:40, Quincey Morris
> wrote:
>
> On Dec 16, 2016, at 12:01 , Jeremy Hughes wrote:
>>
>> It’s just an application method, which overrides the method that the system
>> calls from printDocument when a user chooses Print.
>
> Jus
> On 16 Dec 2016, at 21:54, Jeremy Hughes wrote:
>
>> In that case, you don’t know for sure who calls it and when. It appears to
>> documented that it’s called as part of the standard implementation of
>> “printDocument”, but you don’t know if there are other circ
Quincey Morris (1/9/11, 21:42) said:
>If it should happen that there was a practical need to change the column
>display frequently (dozens of times per day), choosing individual
>columns from a context menu would get very old very fast. In that case,
>the only practical choice might be an array of
Quincey Morris (20/8/09, 19:31) said:
>On Aug 20, 2009, at 11:02, I. Savant wrote:
>
>> I missed that thread. Do you happen to know some keywords from the
>> subject?
>
>No, I've looked for it but I can't find it. It was one of a number of
>similar questions around that time, possibly about iPhon
Graham Cox (14/8/13, 06:51) said:
>They did, which is why first modeless dialogs (from System 1? 2?) and
>then sheets (OSX 1.0) were developed. Even as far back as the original
>Inside Macintosh the use of modal dialogs was strongly discouraged when
>it was possible to use something else. The orig
Hi,
This seems like an elementary question.
I’d like to bind an NSTextField to an array of numerical values, so that the
text field will either display a single value if the values are identical or
will display a multiple values marker if the values are different.
Using Swift, I can bind a tex
> From what I understand of your example, you’re not “binding” anything in a
> Cocoa sense.
In the case of the single value, the text field is set up via the Bindings pane
of Interface Builder so that “Value" says “Bind to File’s Owner” with a model
key path of self.value. (And “value" is decla
> On 6 Mar 2017, at 14:30, Jonathan Mitchell wrote:
>
> Sounds like NSValueTransformer is in fact what you need.
> It can take in your NSArray ref and spit out a single NSString that the
> NSTextField binding can live with.
I think I must be missing something obvious.
The value of an NSTextFie
ection to
> generate values from.
>
> Mike.
>
>> On 6 Mar 2017, at 17:44, Jeremy Hughes wrote:
>>
>>> On 6 Mar 2017, at 14:30, Jonathan Mitchell wrote:
>>>
>>> Sounds like NSValueTransformer is in fact what you need.
>>> It can take
> On 6 Mar 2017, at 17:34, Jeremy Hughes wrote:
>
> It all works now.
Actually, it works as far as the text field displays “Multiple” (placeholder)
for multiple values, but it doesn’t work when I set a value in the text field.
In that case I get:
Error setting value for
If needsDisplay is set to true for an NSView, does that also cause subviews to
be redrawn?
I’ve seen conflicting statements about this, but haven’t found anything in
Apple’s documentation.
Jeremy
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.co
drawn -
except when “wantsLayer” has been set to true.
Does that make sense?
Jeremy
--
> On 8 Mar 2017, at 17:12, Jeremy Hughes wrote:
>
> Thanks - that seems reasonably clear, and it agrees with what I previously
> thought, but I’ve got a situation where it doesn’t see
> On 9 Mar 2017, at 01:49, Quincey Morris
> wrote:
>
> So, the correct answer to your original question, I think, is that if your
> model data has changed in such a way that the representation in custom views
> no longer reflects the data, then you should set “needsDisplay” on *every*
> custo
> On 9 Mar 2017, at 10:24, Jeremy Hughes wrote:
>
> So it seems that for layer-backed views, setting needsDisplay does cause the
> view to be redrawn - but the value is never actually set. If I needed to work
> with layer-backed views, it might be possible to get around this b
> On 9 Mar 2017, at 18:32, corbin dunn wrote:
>
>>
>> On Mar 8, 2017, at 8:46 AM, Jeremy Hughes
>> wrote:
>>
>> If needsDisplay is set to true for an NSView, does that also cause subviews
>> to be redrawn?
>>
>> I’ve seen conflictin
I have a text field that I want to grow and shrink while it is being edited.
In order to do that, I have overridden intrinsicContentSize and textDidChange
in a subclass of NSTextField:
override var intrinsicContentSize: NSSize
{
if let cell = cell, cell.wraps
> On 18 Mar 2017, at 04:45, Daryle Walker wrote:
>
>> This works, but if I remove the call to attributedStringValue (whose result
>> is discarded) the result of the following line fails to reflect changes in
>> the bounds of the text, and the field fails to grow or shrink.
>>
>> Presumably, ca
I’m trying to understand who owns a child view controller after it has been
removed from its parent view controller.
The following code (which doesn’t involve view controllers) behaves as I would
expect:
import Cocoa
class Element
{
var children = [Element]()
weak var parent: E
> On 12 Jul 2017, at 17:41, Jens Alfke wrote:
>
> There may still be a reference in the autorelease pool. Check childReference
> again ‘later’, i.e. on the next user event or after a timer/delayed-perform.
Thanks.
I’d forgotten about autorelease pools - but I guess they’re still there in
Coco
> On 12 Jul 2017, at 18:38, Charles Srstka wrote:
>
>> On Jul 12, 2017, at 12:23 PM, Jens Alfke wrote:
>>
>>> On Jul 12, 2017, at 9:54 AM, Jeremy Hughes
>>> wrote:
>>>
>>> I’d forgotten about autorelease pools - but I guess they’re stil
> On 12 Jul 2017, at 19:25, Jens Alfke wrote:
>
>>
>> On Jul 12, 2017, at 10:57 AM, Jeremy Hughes
>> wrote:
>>
>> Wouldn’t it be ARC (rather than the consumer) that is balancing retains?
>
> Yes. ARC internally generates calls to -autorelease
> On 12 Jul 2017, at 19:24, Jens Alfke wrote:
>
>> While that’s true, the main reason, as I understand it, that ARC doesn’t
>> know enough about the object’s lifetime is that non-ARC code may be calling
>> the method. In an all-ARC world, a method could always just return objects
>> with a +1
Thanks for elucidating!
> On 12 Jul 2017, at 22:03, Greg Parker wrote:
>
> ARC does add an optimization where a cooperating caller and callee can safely
> avoid the retain/release pair around the return operation, effectively
> transforming that call into the return-retained convention.
So in
> On 12 Jul 2017, at 22:07, Quincey Morris
> wrote:
>
>> Or there's something else going on under the covers.
>
> Yes, you are correct, betting *against* this assumption is a really, really
> terrible idea. Reasoning about the point at which objects actually deallocate
> is a code smell.
I’m
> On 12 Jul 2017, at 23:18, Doug Hill wrote:
>
> While this discussion has been good at understanding underlying ARC and
> manual ref-count issues, my guess as to what's causing these issues is that
> you shouldn't just assign nil to the childViewControllers array.
Actually an empty array rat
> On 13 Jul 2017, at 01:32, Jens Alfke wrote:
>
>> On Jul 12, 2017, at 2:57 PM, Jeremy Hughes
>> wrote:
>>
>> I’m trying to understand memory management so I can avoid retain cycles and
>> other issues.
>
> That’s fine. But using a weak refe
> On 13 Jul 2017, at 10:57, Jeremy Hughes wrote:
>
> Apple’s Swift book says:
>
> "The examples above show how to use safe unowned references. Swift also
> provides unsafe unowned references for cases where you need to disable
> runtime safety checks—for example, f
> On 13 Jul 2017, at 11:26, Jeremy Hughes wrote:
>
> So perhaps the difference between safe and unsafe unowned is that safe
> unowned generates a runtime error (but doesn’t crash) while unsafe unowned
> crashes? Or perhaps they both crash, but unowned(unsafe) gives a more h
> On 13 Jul 2017, at 19:43, Quincey Morris
> wrote:
>
> Here’s how I understand the situation in Swift. As usual, I may have some
> things a bit wrong, but I think this is right. There are four kinds of
> reference variable (or stored property) in Swift:
>
> 1. Strong.
>
> 2. Weak.
>
> 3. U
> On 12 Jul 2017, at 17:41, Jens Alfke wrote:
>
>> On Jul 12, 2017, at 9:34 AM, Jeremy Hughes
>> wrote:
>>
>> // Prints "Why is childReference not nil?”
>
> There may still be a reference in the autorelease pool. Check childReference
> again ‘la
> On 13 Jul 2017, at 20:29, Alex Zavatone wrote:
>
> One thing that I had to learn was to break my expectations of when a view
> controller (one that is tied to a navigationController) is deallocated.
I’m not sure that view controllers are special. My understanding is that
objects that are in
> On 14 Jul 2017, at 14:40, Steve Christensen wrote:
>
> On Jul 14, 2017, at 3:50 AM, Jeremy Hughes
> wrote:
>>
>> I’m still not entirely clear on when autorelease pools are used in Swift.
>> There is a WWDC video which says that they’re used in code that interf
> On 10 Aug 2017, at 15:15, Alastair Houghton
> wrote:
>
> On 10 Aug 2017, at 15:09, Charles Srstka wrote:
>>
>> They’re equivalent syntactically, but performance-wise, +array and friends
>> will cause the object to be put into an autorelease pool. Therefore, +new is
>> better for performanc
I have a problem printing an autolayout view in 10.13.2, and I’m wondering if
there is something wrong with my code or if Apple broke something in 10.13 or a
more recent update.
I’m using the same view class for printing and screen, but I have a separate
view object for printing.
I’m overridin
The release notes for 10.13 say:
If your application is linked on macOS 10.13 SDK or later, classes that return
NSPasteboardReadingAsKeyedArchive from readingOptionsForType:pasteboard: must
support secure coding, and will be decoded with a coder that requires secure
coding.
So I’m updating som
lizer, right?
Jeremy
--
> On 20 Dec 2017, at 01:09, Jeremy Hughes wrote:
>
> The release notes for 10.13 say:
>
> If your application is linked on macOS 10.13 SDK or later, classes that
> return NSPasteboardReadingAsKeyedArchive from
> readingOptionsForType:pasteboard:
Thanks, Quincey.
> That looks like Swift 3 code. The current version of the function is like
> this:
>
>> @nonobjc func decodeObject(of classes: [AnyClass]?, forKey key: String) ->
>> Any?
@nonobjc means this is Swift-specfic then?
The init function I’m using is marked as @objc:
@objc requir
> On 20 Dec 2017, at 01:25, Quincey Morris
> wrote:
>
> You’ll have to figure out what type to use for the Ints. If they were
> actually saved compatibly with Obj-C, the Ints will actually be NSNumbers,
> and you’ll need to say “NSNumber.self”. If the Ints are stored opaquely as
> Ints, I gue
> On 20 Dec 2017, at 02:07, Quincey Morris
> wrote:
>
> The class must be a kind of AnyClass, so you can’t specify a struct type.
> Sorry I sent you off in the wrong direction on that.
That’s what I just concluded in an email I started writing.
>> The code I mentioned in my follow-up email se
> On 20 Dec 2017, at 02:22, Jeremy Hughes wrote:
>
> What I don’t like about [NSArray.self] is that it’s an artefact of bridging.
> I’m not actually using it in the encoder:
>
> coder.encode(arrayOfInts, forKey: kArrayKey)
The declaration:
encode(_ object: Any?, forKey key:
> On 19 Dec 2017, at 18:03, Jeremy Hughes wrote:
>
> I have a problem printing an autolayout view in 10.13.2, and I’m wondering if
> there is something wrong with my code or if Apple broke something in 10.13 or
> a more recent update.
>
> I’m using the same view class fo
eremy
--
> On 20 Dec 2017, at 05:03, Quincey Morris
> wrote:
>
> On Dec 19, 2017, at 18:32 , Jeremy Hughes wrote:
>>
>>> On 20 Dec 2017, at 02:22, Jeremy Hughes wrote:
>>>
>>> What I don’t like about [NSArray.self] is that it’s an artefact of
>
Does anyone understand scroll views? I struggle every time I use them, and it
seems that I have to go through a process of trial and error to get them
working properly.
If I drag a scroll view into another view in Interface Builder, I get a
“Bordered Scroll View” that contains a “Clip View” tha
This is a follow-up to my previous email on Scroll views.
What I actually want to is be able to swap different views (with different
heights) in and out of the scroll view. To do this, I’m adding the different
views as a subview of the “document" view (called contentParent below):
contentParent
> On 19 Jan 2018, at 22:15, Quincey Morris
> wrote:
>
>> Interface Builder complains if I don’t also add vertical constraints, so
>> I’ve done that, but made the bottom constraint into a placeholder (“Remove
>> at build time”). Your email suggests that I can also make the top constraint
>> in
Hi Quincey,
I saw Kyle Sluder’s post some time ago, but it’s quite old and I’m not sure how
relevant it is now. My complaint about scroll views is not that they don’t
work, but that they’re confusing and I struggle each time I use them. My
initial email was an attempt to summarise what I’ve dis
I posted a related question in https://apple-dev.groups.io/g/xcode/
("Assets.car is much larger for High Sierra builds”) but I didn’t get much in
the way of a reply.
It seems that Assets.car is much larger when it is built with the 10.13 SDK
than when it is built with the 10.12 SDK.
I don’t kn
> I posted a related question in https://apple-dev.groups.io/g/xcode/
> ("Assets.car is much larger for High Sierra builds”) but I didn’t get much in
> the way of a reply.
https://apple-dev.groups.io/g/xcode/message/396
> It seems that Assets.car is much larger when it is built with the 10.13 S
> On 24 Jan 2018, at 19:46, Dragan Milić wrote:
>
> BTW, in both cases (Xcode 9 - 10.13 SDK and Xcode 8 - 10.12 SDK) the
> deployment target is macOS 10.11, so I don't think that setting matters.
Vince has explained why it does matter.
If you change the deployment target to 10.13 (which you pr
Killing cfprefsd seems unnecessarily drastic. Why not use:
defaults delete
as Gary Wade mentioned earlier?
is a reverse-dns string such as “com.company.appname”
—
> On 30 Apr 2018, at 15:31, Alex Zavatone wrote:
>
> Is it worth it (or wise) to zero out preferences and write them prior to
We found it very difficult. This was for a large C++ Carbon application.
We’re now rewriting in Swift + Cocoa, starting from scratch.
Jeremy
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comment
> By now, Cocoa may be the new Carbon.
The crucial difference is that Cocoa supports 64-bit applications, and Carbon
doesn’t.
> If you haven't switched to Cocoa after all these years, and if your app is
> large, I'd wait to see what happens with Marzipan
We don’t have time to wait for Marzipa
> Our app has 6 or 8 programmer-years of C++ cross-platform business logic.
> Accounting software is complicated. Rewriting that in another language would
> be hard work, and tons of testing. More than Mac sales would justify, so it
> would be time to go Windows-only or just fold.
If you have
> Of course, the C++ business logic doesn't need any changes. The concern is,
> how long will it last? Seems like the future is an entirely Swift-based API
> that replaces Objective-C Cocoa in 5 years, with no easy way to link to other
> languages.
Core parts of Webkit are written in C++, so I
> On 22 Jan 2019, at 18:23, Alastair Houghton
> wrote:
>
> There’s often a printer setting on users’ printers to tell them to use (just)
> black ink.
This also shows up in Cocoa Print dialogs under “Printer features” or as a
“Greyscale” checkbox. I have it turned on by default.
Jeremy
_
Hi Jens,
> On 3 Oct 2019, at 20:04, Jens Alfke via Cocoa-dev
> wrote:
>
> The people I hear complaining about this are those who, like you, didn't move
> to Cocoa. Carbon was a _temporary_ transition API*.
It wasn’t clear to us (outside Apple) that Carbon was a temporary API until
2007, whe
> On 4 Oct 2019, at 11:43, Dragan Milić via Cocoa-dev
> wrote:
>
>> pet 04.10. 2019., at 11.51, Jeremy Hughes via Cocoa-dev wrote:
>>
>> It wasn’t clear to us (outside Apple) that Carbon was a temporary API until
>> 2007, when Apple suddenly abandoned 64-bit C
Maybe it’s also worth noting that WebKit (the browser engine used by Safari) is
written in C++
Safari’s UI is probably written in Obj-C(++) or a mixture of Obj-C(++) and
Swift.
Jeremy
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do
> On 15 Oct 2019, at 18:27, Turtle Creek Software via Cocoa-dev
> wrote:
>
> MVC is an excellent design paradigm. The M and V layers were no problem at
> all to set up. The C started out easy, but ended up being a big problem.
> Quite a bit of the business logic is not just data, but fancy stuf
68 matches
Mail list logo
