Hello Jens.
The documentation says Weight parameter is ignored when I use NSBoldFontMask.
Changing the weight will not affect the result - I tried it.
As for render - we have a part of code that generates bitmap from it and we
draw it using OpenGL. I am not really familiar with this part of
Hi All,
Recently, I was writing a command-line tool and I didn't feel like dropping
down to printf() for console output, so I wrote this category.
Drop this in your project…
@interface NSString (console)
- (void) writeToFileHandle:(NSFileHandle *) handle;
- (void) writeToStdOut;
-
Thanks Kyle. For some reason I missed the superclass (NSTableView) docs when
trying to solve my NSOutlineView selection issues.
However --- I remember (our previous implementation) that when you use an
NSTreeController (Or NSArrayController in the case of NSTableView) to control
the
If you are interested in putting on a presentation/ master class / show and
tell for Thursdays meeting, let me know :-)
#awesome
Tedd
Sent from my iPad
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or
By the way, I can readily confirm that the results differ on the simulator for
4.3 vs. 5.0. m.
On Fri, 11 Nov 2011 16:13:49 +0800, Kin Mak kin...@me.com said:
The following code used to work fine prior to iOS 5. The dateFromString
method seems to stop working on iOS 5 and always returns null. I
This is *very* well explained in the WWDC 2011 video on Objective-C advances. m.
On Sat, 12 Nov 2011 16:14:31 +0800, Roland King r...@rols.org said:
With the code below I'm getting a warning Automatic Reference Counting Issue:
Capturing 'self' strongly in this block is likely to lead to a
On Sun, 13 Nov 2011 01:42:07 -0600, Charles Srstka cocoa...@charlessoft.com
said:
On Nov 13, 2011, at 1:16 AM, ico wrote:
However, I just wonder, is it really true that there is no ANY different
between explicitly declaring iVars and not delaring it?
If youre 64-bit only (or if you
If you’re 64-bit only (or if you require Lion or better), there’s no real
reason to explicitly declare the ivars these days.
As others have pointed out, this is not true. There are practical differences
between declaring and not declaring the ivar explicitly. I almost never
declare the ivar
On Nov 15, 2011, at 9:48 AM, Torsten Curdt wrote:
If you’re 64-bit only (or if you require Lion or better), there’s no real
reason to explicitly declare the ivars these days.
As others have pointed out, this is not true. There are practical
differences between declaring and not declaring
In four words: Fragile Base Class Problem.
The problem is that a subclass (in 32 bit OS X) needs to know the size of the
superclass so it know how to lay out its ivars. If there is no explicit
ivars, there is no way for the compiler to know the size (since when it is
compiling the
On 11 Nov 2011, at 11:23 AM, Fritz Anderson wrote:
On 11 Nov 2011, at 11:00 AM, Fritz Anderson wrote:
My application writes an XML document that includes styled text in the form
of HTML. At the user end is an NSTextView; I use an in-memory Core Data
store for working storage. The text
On Nov 15, 2011, at 8:44 AM, Torsten Curdt tcu...@vafer.org wrote:
In four words: Fragile Base Class Problem.
The problem is that a subclass (in 32 bit OS X) needs to know the size of
the superclass so it know how to lay out its ivars. If there is no explicit
ivars, there is no way for
On Nov 15, 2011, at 8:46 AM, Fritz Anderson fri...@manoverboard.org wrote:
On 11 Nov 2011, at 11:23 AM, Fritz Anderson wrote:
On 11 Nov 2011, at 11:00 AM, Fritz Anderson wrote:
My application writes an XML document that includes styled text in the form
of HTML. At the user end is an
On Nov 15, 2011, at 12:13 AM, Dany Golubitsky wrote:
As for render - we have a part of code that generates bitmap from it and we
draw it using OpenGL. I am not really familiar with this part of code.
I do not think it is related, since, as I said some fonts do work, so it is
not render
Think of it like the compiler generates the ivars from the property
definitions. So the ivar would be indeed explicit ivars - just not
defined as such in the classic way.
Doesn't matter. The subclass still needs to know the size of its superclass
so that it generate the proper ivar offsets.
On Nov 15, 2011, at 9:52 AM, Torsten Curdt tcu...@vafer.org wrote:
Think of it like the compiler generates the ivars from the property
definitions. So the ivar would be indeed explicit ivars - just not
defined as such in the classic way.
Doesn't matter. The subclass still needs to know the
On 15 Nov 2011, at 11:02 AM, Kyle Sluder wrote:
Don't do this. Bindings really don't understad mutable value types like
NSTextStorage. This is going to call -setFoo: on your managed object, which
will fire KVO, which will call -setString: on your NSTextView, which will
reset the cursor
On Nov 15, 2011, at 9:55 AM, Kyle Sluder wrote:
FWIW I check on the llvm IRC channel and the response was I wouldn't
be surprised if there are annoying edge cases, but offhand I don't see
any reason it couldn't be done.
If it could've been done, they would have done it. The fragile base
On Nov 15, 2011, at 10:34 AM, Torsten Curdt wrote:
No it can't. @property only says I have methods named -foo and -setFoo:.
It implies absolutely nothing about storage.
How does
@property (nonatomic, assign) IBOutlet NSWindow *window;
not have the information that there would need to
On Nov 15, 2011, at 10:34 AM, Torsten Curdt wrote:
How does
@property (nonatomic, assign) IBOutlet NSWindow *window;
not have the information that there would need to be an ivar
NSWindow *window;
on 32-bit?
There’s no requirement that there be such an ivar, only a method named
There’s no requirement that there be such an ivar, only a method named
-window that returns an NSWindow*. The implementation of that method is
arbitrary. For example it might just look like
- (NSWindow*) window { return [_parent window];}
But then again the compiler would know about these
On Tue, Nov 15, 2011 at 10:54 AM, Torsten Curdt tcu...@vafer.org wrote:
There’s no requirement that there be such an ivar, only a method named
-window that returns an NSWindow*. The implementation of that method is
arbitrary. For example it might just look like
- (NSWindow*) window { return
On Nov 15, 2011, at 10:54 AM, Torsten Curdt wrote:
But then again the compiler would know about these implementations.
No, it wouldn’t. The compiler has no idea how NSDictionary or NSWindow are
implemented. All it knows about them is what’s given in their header files.
(Worse, even if it did
On Nov 14, 2011, at 5:32 PM, Conrad Shultz wrote:
On 11/11/11 9:50 PM, April wrote:
Actually I had a long existing project that I start working on in 4.1
before the release and then 4.2 when I started icloud support up
until now. I've hit multiple delays and setbacks due to adding
features
While on this subject I just got the dreaded: Your app will now spend the next
6-12 months in review round file hell before being rejected without further
review:
We are currently reviewing an app that you submitted for inclusion on the App
Store, and want to let you know that the review
Hi all,
Unless I've missed it, the docs say nothing about the thread safety of
NSTreeNode.
I'm hoping to be able to do the following: create and mutate an NSTreeNode on a
background thread, where only this thread knows about the instance, then pass
the instance off to the main thread, where
Hi all,
Suppose I have some common tasks, such as get user preferences and return
some value, or do some calculation then return the result.
I want to implement a function that do these kind of tasks so that I don't
need to write those codes again and again. However, this function seems
that it
On Nov 15, 2011, at 7:17 PM, ico wrote:
So what is the best practice to place these function? Simply write them as
a C function or implement them in a common class and make them static?
Either way is OK, and you can find several examples of either technique in
Apple’s APIs — look at
28 matches
Mail list logo
