The NSRulerViews are owned and provided by the NSScrollView.
While you can certainly scroll a view without the ScrollView, you would need to
reimplement a lot of its functionality yourself.
These are pretty tightly coupled classes in terms of functionality.
Without an NSScrollView you canno
On 15 Jul 2014, at 4:54 am, Jens Alfke wrote:
> The equivalent function in the ‘classic’ Mac OS had the very appropriate name
> of Munger( ) since it would munge bytes around in a heap block. Knowing how
> to use Munger was a sign of geek cred in the old (80s-90s) Mac dev community.
My god,
On Jul 14, 2014, at 1:07 PM, Carl Hoefs wrote:
> modifiableData = [ NSMutableData dataWithData: [ external call that gives
> me an NSData ] ];
It’s shorter and more idiomatic to just say
modifiableData = [external mutableCopy];
(plus an autorelease if you’re not using ARC)
> Will
On Jul 14, 2014, at 12:57 PM, "Gary L. Wade"
wrote:
> where you're creating the object
On Jul 14, 2014, at 12:53 PM, Jens Alfke wrote:
> If you’re the one creating the NSData object in the first place, can you
> create it as an NSMutableData?
Certainly that makes sense enough, just hoping
The reason you can't do exactly what you're asking is because there may be
other owners of the immutable object. Since NSMutableData is a subclass of
NSData, you should ask yourself where you're creating the object and try
creating it from the start as mutable, and also if there are owners of th
On Jul 14, 2014, at 12:15 PM, Carl Hoefs wrote:
> Okay, 1 last question on this. Is there a way to promote-in-place an NSData
> object into an NSMutableData object? -becomeMutable or some such? I'm trying
> to avoid copying megabytes of data/sec if it's avoidable.
Nope. Part of the contract
On Jul 14, 2014, at 11:54 AM, Jens Alfke wrote:
>
> On Jul 14, 2014, at 11:48 AM, Carl Hoefs
> wrote:
>
>> Yes, I guess it's the semantics that threw me. I was attempting to
>> "insertBytesInRange" not "replaceBytesInRange", so I had it in my mind that
>> the one couldn't do the other. But
On Jul 14, 2014, at 11:48 AM, Carl Hoefs wrote:
> Yes, I guess it's the semantics that threw me. I was attempting to
> "insertBytesInRange" not "replaceBytesInRange", so I had it in my mind that
> the one couldn't do the other. But that's the whole purpose of the NSRange.
> Very cool.
The eq
On Jul 14, 2014, at 11:35 AM, Ben Kennedy wrote:
> On 14 Jul 2014, at 11:30 am, Carl Hoefs
> wrote:
>
>>> [bigMData replaceBytesInRange:NSMakeRange(0,0) withBytes:newBytesPtr
>>> length:1024];
>>
>> Wow, that's damn clever! My thinking is so clunky. It never would have
>> occurred to me tha
On 14 Jul 2014, at 11:30 am, Carl Hoefs wrote:
>> [bigMData replaceBytesInRange:NSMakeRange(0,0) withBytes:newBytesPtr
>> length:1024];
>
> Wow, that's damn clever! My thinking is so clunky. It never would have
> occurred to me that NSMutableData could expand (0,0) into (0,1024) out of
> thin
On Jul 14, 2014, at 11:22 AM, Mike Abdullah wrote:
> [bigMData replaceBytesInRange:NSMakeRange(0,0)
>withBytes:newBytesPtr
> length:1024];
On Jul 14, 2014, at 11:23 AM, Ben Kennedy wrote:
> [bigMData replaceBytesInRan
On 14 Jul 2014, at 11:12 am, Carl Hoefs wrote:
> Okay, now if I want to insert 1024 bytes of new data at the beginning of a
> populated NSMutableArray, is there a better way than this:
Sure; why not just do [bigMData replaceBytesInRange:NSMakeRange(0,0)
withBytes:newBytesPtr length:1024]; ...
On 14 Jul 2014, at 19:12, Carl Hoefs wrote:
> Okay, now if I want to insert 1024 bytes of new data at the beginning of a
> populated NSMutableArray, is there a better way than this:
Yes.
[bigMData replaceBytesInRange:NSMakeRange(0,0)
withBytes:newBytesPtr
Okay, now if I want to insert 1024 bytes of new data at the beginning of a
populated NSMutableArray, is there a better way than this:
NSMutableData *bigMData = ... // (approx 1MB of data);
int origlength = bigMData.length;
uint8_t *newBytesPtr = ...
. . .
// Shift contents ove
On Mon, 14 Jul 2014 09:11:58 -0700, Jens Alfke said:
>But I agree about NSNumbers being more complicated. The only time you
>need to use an NSNumber is if you want to stick a number into a
>collection or otherwise need to treat it as an object.
It's also useful for optional values, where a nil NS
On Jul 14, 2014, at 3:44 AM, Uli Kusterer wrote:
> NSNumber is more complicated to use (constant calls to integerValue and
> valueWithInteger: etc. to actually work with them) and carries a bit more
> overhead (it creates a new NSObject subclass on the heap every time
“Every time" hasn’t been
On 13 Jul 2014, at 23:29, Trygve Inda wrote:
> NSNumber just seem a bit more flexible since they can be added to
> dictionaries (such as in the userInfo of a Notification).
NSNumber is more complicated to use (constant calls to integerValue and
valueWithInteger: etc. to actually work with them)
Graham Cox wrote:
> NSInteger is a typedef for 'long', which size depends on the platform (32/64
> bit), so valueForKey: will wrap it as a NSNumber using type 'long’.
That’s not quite true. While it is the desired effect that NSInteger behave
like long, NSInteger was used because the spots in th
18 matches
Mail list logo
