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 code.
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 NSOutLineVi
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 mode
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 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 suspect
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 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 retain cycle"
>
On Sun, 13 Nov 2011 01:42:07 -0600, Charles Srstka
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 require Lion or be
>>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 t
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 no
> 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 s
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 t
On Nov 15, 2011, at 8:44 AM, Torsten Curdt 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 the comp
On Nov 15, 2011, at 8:46 AM, Fritz Anderson 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 NSTextView; I us
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
On Nov 15, 2011, at 9:52 AM, Torsten Curdt 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 size
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
> 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 be an ivar
NSWindow *window;
on 32-bit?
>> FWIW I
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 fragil
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 wou
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 na
> 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 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 [_parent wi
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
>> f
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 proce
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 th
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 sh
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 NSFileM
29 matches
Mail list logo
