Thanks, that really helps - I never really understood what was happening with
this - I do now.
Indeed I had the ‘Installation Directory’ set incorrectly for the Debug version
of the library. Working fine now!
—Graham
> On 2 Jul 2015, at 1:38 pm, Greg Parker wrote:
>
> Check the install name
> On Jul 1, 2015, at 7:55 PM, Graham Cox wrote:
>
> Hi all,
>
> I’m developing an app that includes a .dylib within its own resources. For
> convenience I’m locating this in the /Frameworks subdirectory. I added a File
> Copy to the Build Phases to copy the library there, and I confirm it’s b
Hi all,
I’m developing an app that includes a .dylib within its own resources. For
convenience I’m locating this in the /Frameworks subdirectory. I added a File
Copy to the Build Phases to copy the library there, and I confirm it’s being
done in both debug and release builds. I also added the
> On 2 Jul 2015, at 11:15 am, Charles Srstka wrote:
>
> and that you have the named function parameters to make it clear what’s going
> on
Amen :)
G.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or mode
> On Jul 1, 2015, at 18:15 , Greg Parker wrote:
>
> An implicitly-unwrapped optional works as if every access were
> force-unwrapped. I don't know how well the optimizer can fold redundant nil
> checks together; it's likely that there are cases that would be a little bit
> faster when written
On Jul 1, 2015, at 6:28 PM, Graham Cox wrote:
>
> Obviously it’s only a convention, but I think horizontal values should always
> precede vertical ones, if only because x comes before y in the alphabet, and
> map coordinates are that way around as well. The change to {origin, size} was
> also
> On Jul 1, 2015, at 5:39 PM, Rick Mann wrote:
>
>> On Jul 1, 2015, at 17:04 , Greg Parker wrote:
>>
>> Implicitly unwrapped optional is a good solution for this. The source code
>> is no more complicated outside init, and if you get something wrong then you
>> will get a runtime error with
> On Jul 1, 2015, at 18:05 , Quincey Morris
> wrote:
>
> On Jul 1, 2015, at 17:50 , Rick Mann wrote:
>>
>> I didn't think it was possible to not return. Maybe an assert() is better in
>> this situation, because I think it always indicates a programming mistake.
>
> Indeed it is possible. Th
On Jul 1, 2015, at 17:50 , Rick Mann wrote:
>
> I didn't think it was possible to not return. Maybe an assert() is better in
> this situation, because I think it always indicates a programming mistake.
Indeed it is possible. There are three possible functions:
fatalError (“message”)
> On Jul 1, 2015, at 17:48 , Quincey Morris
> wrote:
>
> On Jul 1, 2015, at 17:39 , Rick Mann wrote:
>>
>> What's the run-time penalty of using implicitly- or force-unwrapped
>> Optionals? Does it do a check for null at each invocation, or does it crash?
>
> I’d propose that not returning f
On Jul 1, 2015, at 17:39 , Rick Mann wrote:
>
> What's the run-time penalty of using implicitly- or force-unwrapped
> Optionals? Does it do a check for null at each invocation, or does it crash?
I’d propose that not returning from the initializer at all is a better
solution. If there’s no reas
> On Jul 1, 2015, at 17:04 , Greg Parker wrote:
>
> Implicitly unwrapped optional is a good solution for this. The source code is
> no more complicated outside init, and if you get something wrong then you
> will get a runtime error with a useful message.
All that makes sense, although Jens's
> On Jul 1, 2015, at 4:49 PM, Rick Mann wrote:
>
> I'm trying to define a Swift wrapper around CGContext. I want to assert that
> a Context object, if successfully initialized, will always have a valid
> CGContextRef property. Since at least one of my initializers can fail, I set
> it up as "
graphicsPort doesn’t return an Optional however currentContext does, so
cocoaCTX is an NSGraphicsContext? which is what the error message was trying to
tell you.
let cocoaCTX = NSGraphicsContext.currentContext()
let sysCTX = cocoaCTX?.graphicsPort as! CGContextRef?
is what you need to get an o
> On Jul 1, 2015, at 4:49 PM, Rick Mann wrote:
>
> I'm trying to define a Swift wrapper around CGContext. I want to assert that
> a Context object, if successfully initialized, will always have a valid
> CGContextRef property. Since at least one of my initializers can fail, I set
> it up as "
> class
> Context
> {
>init()
>throws
>{
>let cocoaCTX = NSGraphicsContext.currentContext()
>guard let sysCTX = cocoaCTX.graphicsPort as! CGContextRef else { throw
> Errors.InvalidContext }
>CGContext = sysCTX;
>}
>
>var CGContext : CGContextRef
>
> On Jul 1, 2015, at 16:51 , Stephen J. Butler wrote:
>
> You're focusing on the wrong part :) Which element of your code has a type of
> "NSGraphicsContext"? It's cocoaCTX! The compiler error is suggesting you do
> one of these:
>
> cocoaCTX?.graphicsPort
> cocoaCTX!.graphicsPort
Yeah, I fi
You're focusing on the wrong part :) Which element of your code has a type
of "NSGraphicsContext"? It's cocoaCTX! The compiler error is suggesting you
do one of these:
cocoaCTX?.graphicsPort
cocoaCTX!.graphicsPort
On Wed, Jul 1, 2015 at 6:28 PM, Rick Mann wrote:
> I'm trying to do this:
>
> cl
I'm trying to define a Swift wrapper around CGContext. I want to assert that a
Context object, if successfully initialized, will always have a valid
CGContextRef property. Since at least one of my initializers can fail, I set it
up as "throws".
After getting the actual init code to compile, I'v
I think I figured this out. graphicsPort does not return an Optional type. I
guess the only way to know that is via Xcode's Code Completion, is that right?
Oh, the docs seem to show it, too (assuming it can find either).
Sorry for the noise.
> On Jul 1, 2015, at 16:28 , Rick Mann wrote:
>
> I
I'm trying to do this:
class
Context
{
init()
throws
{
let cocoaCTX = NSGraphicsContext.currentContext()
guard let sysCTX = cocoaCTX.graphicsPort as! CGContextRef else { throw
Errors.InvalidContext }
CGContext = sysCTX;
}
var CGContext : CGContextR
> On 2 Jul 2015, at 7:22 am, Greg Parker wrote:
>
> Classic Mac OS was inconsistent. For example, the C struct initializer for
> Rect was { top, left, bottom, right }, but the initializer function was
> SetRect(&rect, left, top, right, bottom).
Ah, the good old days /sarc
Obviously it’s onl
> On 1 Jul 2015, at 09:37, Ken Thomases wrote:
>
> On Jun 30, 2015, at 11:56 AM, Jonathan Guy wrote:
>
>> Im trying to fix a problem with dynamic row heights with auto layout and
>> bindings which was working fine in an older build of Xcode but which now no
>> longer works. So my new attempt
> On Jul 1, 2015, at 8:58 AM, Charles Srstka wrote:
>
>> On Jul 1, 2015, at 10:09 AM, Jean-Daniel Dupas wrote:
>>
>> Only because you are used to CGRect. QuickDraw used to defined a rect using
>> left, top, right, bottom values.
>
> Actually, it was top, left, bottom, right.
Classic Mac OS
> On Jul 1, 2015, at 3:55 PM, Alex Kac wrote:
>
> Our app shows up in the Accessibility section of System Preferences:
> Allow the apps below to control your computer.
>
> Any idea why?
Because your application uses Apple's accessibility API to monitor or control
other running applications o
> On Jul 1, 2015, at 09:07 , Roland King wrote:
>
> Named parameters is good syntax, autocomplete, which needs to still get
> better,
It needs to get SO MUCH BETTER.
• It still fails completely for me ALL the time, Xcode 6 or 7, there are times
when it simply won't offer any completions at a
Hi!
I've an XCode Swift project with 2 targets, an traditional app and a
screensaver. I want to use a framework in both (I've tried with at least 2
frameworks with no luck).
In the app they work ok but in the screensaver, despite that I'm able to
compile (I have a bridging file with the appropria
Our app shows up in the Accessibility section of System Preferences:
Allow the apps below to control your computer.
Any idea why?
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list
On Jul 1, 2015, at 08:09 , Jean-Daniel Dupas wrote:
>
> Only because you are used to CGRect.
Well, that’s kinda what I was saying: “everyone” is used to CGRect. I’ve been
trying to think of other types that are as fundamental, but so far I haven’t
thought of any beyond NS/CGRect/Point/Size
>
> On 1 Jul 2015, at 23:58, Charles Srstka wrote:
>
> On Jul 1, 2015, at 10:09 AM, Jean-Daniel Dupas wrote:
>>
>> Only because you are used to CGRect. QuickDraw used to defined a rect using
>> left, top, right, bottom values.
>
> Actually, it was top, left, bottom, right.
>
> Charles
>
And
On Jul 1, 2015, at 10:09 AM, Jean-Daniel Dupas wrote:
>
> Only because you are used to CGRect. QuickDraw used to defined a rect using
> left, top, right, bottom values.
Actually, it was top, left, bottom, right.
Charles
___
Cocoa-dev mailing list (
> Le 30 juin 2015 à 23:46, Quincey Morris
> a écrit :
>
> On Jun 29, 2015, at 15:42 , Rick Mann wrote:
>>
>> Here's an example (and this is what I frequently encounter) where requiring
>> parameter names adds nothing but clutter:
>>
>> let config = WKWebViewConfiguration()
>> self.webVi
What would be the feature set?
What features that are currently part of the table view that you'd currently
include? I ask this because there are many features within a tableview that I
know of but never use (cell reordering) and I'm sure there are many that I also
don't know about.
Cheers,
> On 30 Jun 2015, at 18:40, Britt Durbrow
> wrote:
> can you talk to the server directly, instead of going thru Outlook?
Unfortunately that isn’t an option for quite a few reasons.
Cheers
Dave
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.c
On Jun 30, 2015, at 11:56 AM, Jonathan Guy wrote:
> Im trying to fix a problem with dynamic row heights with auto layout and
> bindings which was working fine in an older build of Xcode but which now no
> longer works. So my new attempt for the most part works but about 30% of my
> row heights
35 matches
Mail list logo
