Re: creating files to write data to?

[Scott Anguish]

On 17-Aug-08, at 1:52 AM, Ken Thomases wrote:


On Aug 17, 2008, at 12:07 AM, FTB Accounts wrote:


Here is the current code I am running:


This code has many fundamental errors.  I think you need to review  
the basics of the C language first, then of Objective-C.  You have  
to walk before you can run.


You say that you're not getting any errors or warnings when you  
build this, but that can't be.  You would definitely get warnings  
for this code.



/* START CODE */

#import 

int main(int argc, char *argv[])
{

NSData *fname = "file:///Users/cknorr/mytest/MYTEST/data.txt";


You are initializing a variable of type NSData* (pointer to  
NSData).  However, the right-hand side is not an NSData*, it's a C- 
style string, which is a character array (char* or char[]).  These  
are not compatible.  It's certainly not meaningful.  Any attempt to  
use the fname variable as though it were a pointer to an NSData  
object would fail, because it doesn't actually contain a valid  
pointer to an NSData object.



NSFileHandle *fh=[NSFileHandle fileHandleForWritingAtPath:fname];


Even if fname did contain a valid pointer to an NSData object, the  
above would not be correct.  The +fileHandleForWritingAtPath: method  
of NSFileHandle expects a pointer to an NSString object as its  
argument, but that's not what you're providing.


and file:/// is a URL string, not a file system path.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: creating files to write data to?

[Ken Thomases]

On Aug 17, 2008, at 12:07 AM, FTB Accounts wrote:


Here is the current code I am running:


This code has many fundamental errors.  I think you need to review the  
basics of the C language first, then of Objective-C.  You have to walk  
before you can run.


You say that you're not getting any errors or warnings when you build  
this, but that can't be.  You would definitely get warnings for this  
code.



/* START CODE */

#import 

int main(int argc, char *argv[])
{

NSData *fname = "file:///Users/cknorr/mytest/MYTEST/data.txt";


You are initializing a variable of type NSData* (pointer to NSData).   
However, the right-hand side is not an NSData*, it's a C-style string,  
which is a character array (char* or char[]).  These are not  
compatible.  It's certainly not meaningful.  Any attempt to use the  
fname variable as though it were a pointer to an NSData object would  
fail, because it doesn't actually contain a valid pointer to an NSData  
object.



NSFileHandle *fh=[NSFileHandle fileHandleForWritingAtPath:fname];


Even if fname did contain a valid pointer to an NSData object, the  
above would not be correct.  The +fileHandleForWritingAtPath: method  
of NSFileHandle expects a pointer to an NSString object as its  
argument, but that's not what you're providing.


Note that a pointer to a C-style string (character array), which is  
what's in fname, is also _not_ a valid pointer to an NSString object.   
They are two completely different ways of representing strings and are  
not directly interchangeable.



[fh writeData:@"THIS IS A TEST"];


The -writeData: method of NSFileHandle expects a pointer to an NSData  
object.  However, what you're passing here is a pointer to an NSString  
object.  Again, this can't work.




[fh closeFile];

   return NSApplicationMain(argc,  (const char **) argv);
}


Regards,
Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: creating files to write data to?

[FTB Accounts]

Thanks, all for the responses.

First I changed the path to write to. The folder is writable. On GetInfo for 
the folder "MYTEST", I have set "Read & Write" permissions for:
You can, Owner, Group, & Others. Is there anything else I need to do to make it 
write to that folder?

As a side note, I am running an Apache server on the mac I am working on, and I 
can write PHP programs that will write to this directory.

However, this is still not working. I am not getting anything under  "Errors 
and Warnings" in Xcode. Also the program loads. However, after running the 
Debugger does come up.

On debugger there are 5 listed.

0. asm objc_msgSend 0x90a594c0:1
1. ?
2. asm -[NSConcreteFileHandle initWithPath:flags:createMode:] 0x92867509:1
3. asm +[NSFileHandle fileHandleForWritingAtPath:] 0x9287a5e6:1
4. THIS IS BROKEN DOWN IN SUB SECTIONS

[Arguments]
Value: 1
Variable: argc
Value: 0xba5c
Variable: argv
[Locals]
Value: 0x2cf58
Variable: fname
Summary: {(int)[$VAR length]} bytes
Value: 0x1f4c
Variable: fh
Summary: file descriptor: {(int)[$VAR fileDescriptor]}


Here is the current code I am running:

/* START CODE */

#import 

int main(int argc, char *argv[])
{

NSData *fname = "file:///Users/cknorr/mytest/MYTEST/data.txt";
NSFileHandle *fh=[NSFileHandle fileHandleForWritingAtPath:fname];
[fh writeData:@"THIS IS A TEST"];
[fh closeFile];

return NSApplicationMain(argc,  (const char **) argv);
} 



--- On Sat, 8/16/08, Jason Coco <[EMAIL PROTECTED]> wrote:

> From: Jason Coco <[EMAIL PROTECTED]>
> Subject: Re: creating files to write data to?
> To: "Andy Lee" <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], cocoa-dev@lists.apple.com
> Date: Saturday, August 16, 2008, 3:33 AM
> On Aug 15, 2008, at 19:35 , Andy Lee wrote:
> 
> > On Aug 15, 2008, at 6:43 PM, Jason Coco wrote:
> >> Adding the @ just makes it an NSString constant...
> but writeData  
> >> still requires (NSData *), not (NSString *).
> >
> > Argh!  Or perhaps, given the nature of this error,
> which I missed, I  
> > should say "Arg!"
> >
> > Surely you got a compiler warning?  If you ignored
> that, surely a  
> > runtime error?
> >
> > Check your errors, both at compile time and runtime
> (and treat  
> > warnings as errors).
> 
> Yeah... I was thinking the same thing... you /must/ have
> got  
> warnings... eventually you would have gotten an Exception I
> think :)


  
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

How to debug "The Debugger has exited due to signal 10 (SIGBUS)."

[Nathan Gilmore]

Hello Everyone,

I am a newbie to Cocoa and just started getting this error as my app  
starts up:


The Debugger has exited due to signal 10 (SIGBUS).The Debugger has  
exited due to signal 10 (SIGBUS).


I am having trouble debugging this because I do not know what this  
means.  I also don't know what part of my code is causing this error.   
Is there a way to get more information out of Xcode?


Any help is greatly appreciated!

Thank you,
Nathan
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Hiding NSTableColumn causes other columns to shrink

[Markus Spoettl]

Hi List,

 it appears it's time for a stupid question again. I'm experiencing  
some odd behavior of NSOutlineView (probably NSTableView as well) when  
hiding and showing table columns dynamically.


I have an outline with a number of columns, the first and last column  
have "resize with table" turned on, most of the other columns don't.  
Now, when I change [column isHidden] of any column programmatically,  
the first and last column shrink to their minimum size (as set in IB).  
It doesn't matter whether a column gets hidden or shown, the effect is  
the same for both actions.


The shrinking appears to affect the two outermost columns (from left  
and right edge respectively) that have "resize with table" set.


Does anyone know why? Is there a cure (other than turning off "resize  
with table")?


I'm using Xcode 3.0 on Mac OS 10.5.4

Regards
Markus
--
__
Markus Spoettl



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa-dev Digest, Vol 5, Issue 1470

[John Joyce]

On Fri, Aug 15, 2008 at 10:53 PM, John Joyce
<[EMAIL PROTECTED]> wrote:

Right now, I'm toying with using Flex/Lex in a Cocoa project.
Unfortunately, I don't see a reliable or easy way to handle NSStrings
correctly all the time with Flex.
Does anybody have any suggestions for such text handling and reliable
unicode aware regexes?
I'm seriously not interested in implementing such details in C with  
Flex.
Flex is fast and cool for that, but if it's going to be stupidly  
difficult
to use reliably with other languages on a mac, it's not a good idea  
for me.


Depending on exactly what you need, unicode awareness can be fairly
straightforward.

Commonly, unicode in regexes is only needed to pass through
undifferentiated blobs of text, with ASCII delimiters. For example,
imagine parsing a CSV file which potentially has unicode text inside
the quotes. For this case, you can convert the file to UTF-8, and then
constructs like . will accept them. All non-ASCII characters in UTF-8
are represented as bytes 128-255, so if you just pass those through
then you'll be fine. But be aware of some potential problem areas:

- Each non-ASCII character will be more than one byte, and flex will
think of it as more than one character. Write your regexes
accordingly. In particular, avoid length limits on runs of arbitrary
characters, and avoid using non-ASCII characters directly in your
regex.

- It's very difficult to split UTF-8 strings correctly. If you
encounter a run of non-ASCII characters, ensure that you follow that
run through the end, until you get back to ASCII. Don't have a regex
that stops in the middle of it and then expects your code to be able
to do something useful with it.

- If you need to do something with non-ASCII characters besides read
them in one side and write them out the other, for example doing
something special with all accented characters, then Flex is probably
not the right answer.

Besides this it ought to be pretty straightforward. Since Flex just
passes your code straight through to the compiler, you can write
Objective-C in the actions (as long as you compile the result as
Objective-C, of course!), convert the text from UTF-8 back to an
NSString, and take things from there.

Mike



Thanks to all.
Mike, your answer especially set it on the right path that Flex is not  
going to do what I would like to do, at least not without a lot of  
work that might be silly.
Certainly, I could extract ranges of strings that are within the  
ranges of ASCII and apply rules to them and then lump other stuff into  
a separate group, but I'd like to have more control.


If I were willing to just do ASCII, it would be a wonderful thing,  
since Flex is so fast.
I understand well enough how difficult it can be to establish rules  
for unicode strings when there are a lot of semantics possible  
depending on the language.
In my case, I am mainly interested in working with Japanese text,  
which does have difficulty due to a general lack of white space to  
rely on, but beyond that not so much more than a large character set.
I want to be able to use Japanese strings as tokens throughout  
something.
I seriously wonder how sophisticated syntax highlighting in Xcode  
really is... it does handle things quite well!


As cool and wonderful as Flex is, it just isn't going to be reliable  
for what I want to do.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Window 'close' action fails

[Chris Hanson]

On Aug 16, 2008, at 11:48 AM, dct wrote:

I'd still like to know why "[self close]" failed in this case--but I  
can live with the solution without knowing why it works in some  
cases and not in others.


I suspect you were not closing the window you thought you were  
closing, due to the way you had written your NSWindowController  
subclass's -init method.


  -- Chris


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Window 'close' action fails

[Chris Hanson]

On Aug 15, 2008, at 3:28 PM, dct wrote:

I don't believe that my 'close' problem is explained by an awkward  
init -- as I said before, all of the other U/I operations of the nib  
"SPlotWindow.nib" are working as expected (so somehow I've dodged a  
potential bullet, at least so far).


Indeed; your application may be behaving the way you'd like it to for  
the time being, but it's not doing so for the reasons you expect.   
That's something you'll need to fix to keep your application  
maintainable.



I do wonder why it is improper to:
 1. load a nib, then
 2. init a WindowController instance using that nib, and then
 3. init an NSView instance defined as part of the nib using the nib  
defined frame

all within a subclass init method.


It's improper because you're doing the same thing multiple times, and  
re-initializing objects that are already initialized.  Here's what  
your original code looked like, with its lines numbered:


1  - init
2  {
3  [NSBundle loadNibNamed:@"SPlotWindow.nib" owner:self];
4  [super initWithWindowNibName:@"SPlotWindow.nib"];
5  [splotView initWithFrame:[splotView frame]];
6  return self;
7  }

The problems with this are:

(1)  You're not assigning to "self" when invoking your superclass  
designated initializer.  That may return a different object; you must  
return the object you got back from your superclass designated  
initializer except in very special cases.


(2)  On line 3, you're loading a nib file -- and setting its owner to  
a not-yet-initialized object! -- and then on line 4 you're basically  
telling your superclass to load that nib again.  Line 3 is entirely  
redundant.  Get rid of it.


(3)  On line 5, you're not initializing "splotView" with information  
from the nib.  You're **re-initializing** "splotView" with **its own**  
frame.  This will have undefined results, because either your nib  
won't be loaded yet (once you get rid of line 3) or because  
initializing the same object twice could put it into a bad state.   
Furthermore, the frame of "splotView" will be set to whatever it is in  
the nib automatically, since you've said "splotView" comes from the nib.


In summary, your -init method should really look like Charles Steinman  
said it should:


1  - (id)init
2  {
3  return [super initWithWindowNibName:@"SPlotWindow.nib"];
4  }

There's no need to assign to "self" here because you're not doing  
anything with it, but if you were you should follow the standard Cocoa  
"self = ...; if (self != nil) { ... } return self;" pattern.


  -- Chris

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Preferred Wrapper for TCP Sockets Over Local Network?

[Devon Ferns]

I've used AsyncSocket before but not too extensively.  It seems to  
work just fine and I don't really have any complaints about it.


Devon

On 16-Aug-08, at 2:27 PM, Brad Gibbs wrote:


Hi,

I'm looking for a Cocoa class to establish a TCP socket with another  
machine on a local network (non-OS X).  I've found Omni Networking,  
AsyncSocket and NetSocket.  I've read conflicting reports of the  
suitability of NSSocketPort for non-DO-related work.  I would like  
to be able to use an SSL certificate, but, beyond that, my needs  
aren't exotic.  Ease-of-use and reliability would be a big plus.   
I've also considered a Ruby class that would handle the TCP  
messaging and pass responses back to the Cocoa-based app.  Any  
suggestions?


Thanks,

Brad
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/dferns%40devonferns.com

This email sent to [EMAIL PROTECTED]




smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: NSUInteger hash

[Steve Wart]

Thanks for the useful feedback.

Nick I thought about creating an object for the number but I was
apprehensive about the allocation overhead. It seems strange that NSRect and
NSPoint are structs and not objects, but I'm rolling with it :)

Mike thanks for suggesting I use integer value as its own hash. I was
looking in completely the wrong places.

Steve

On Sat, Aug 16, 2008 at 2:21 PM, Michael Ash <[EMAIL PROTECTED]> wrote:

> On Sat, Aug 16, 2008 at 3:57 PM, Steve Wart <[EMAIL PROTECTED]> wrote:
>
> > What's the standard way of hashing non-object values in Cocoa?
>
> For primitives, the hash value can generally just be itself.
>
> Recall that NSUinteger is just a typedef for either int (in 32-bit) or
> long (in 64-bit). So it's just an integer.
>
> You have a pair of floats. The simplest thing to do would be to cast
> them to NSUInteger, thereby truncating off the decimal bits, and then
> XOR the result together:
>
> - (NSUInteger)hash { return (NSUInteger)p.x ^ (NSUInteger)p.y; }
>
> Note that this stops making much sense if you expect your points to be
> fractional values, and you want different fractional values to be
> considered unequal*. In that case, I'd recommend simply using the
> whole float bit-pattern as your hash:
>
> static NSUInteger CGFloatHash(CGFloat f) { return *(NSUInteger *)&f; }
>
> - (NSUInteger)hash { return CGFloatHash(p.x) ^ CGFloatHash(p.y); }
>
> (This works in both 32-bit and 64-bit since NSUInteger and CGFloat
> happen to be the same size. If you use this in real code then I
> recommend at least adding a check that the sizes are in fact equal and
> failing in some loud, obvious way if they aren't so you don't end up
> reading junk.)
>
> Note that if you ever expect to have both positive zero and negative
> zero in your points then this will fall apart, as negative zero and
> positive zero can compare as equal but don't have matching bit
> patterns. The solution to this is left as an exercise to the reader,
> with a pointer to the IEEE 754 spec.
>
> * Note that in general it's bad to compare floating point numbers with
> non-integral parts for equality anyway. Two numbers which you think
> should be equal may well not be due to rounding error in the
> calculations which generated them. There's even an optional gcc
> warning flag, -Wfloat-equal, which will produce a warning any time the
> == operator is used on floating point numbers. Thus if your instance
> variables are NSPoints, and you expect those points to have fractional
> values, and you're using those variables as part of your equality
> comparison, you're probably doing something wrong. (Although if you
> only expect two floats to be equal when you've merely saved a copy of
> one to look up later, then that can be reasonably expected to work.)
>
> Mike
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: NSUInteger hash

[Michael Ash]

On Sat, Aug 16, 2008 at 3:57 PM, Steve Wart <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I'm just getting started with Cocoa and I'm trying to implement hash and
> isEqual: methods according to the recommendations in the coding guidelines.
>
> To implement a hash method I would normally just hash the receiver's
> instance variables together and xor the result, but this only works if the
> instance variables are objects.
>
> However my instance variables are NSPoints, which are defined as structs,
> not objects. The C programmer in me wants to cast the floats into integers
> and hash those, but we are in a 64-bit world now, and I assume that 32-bit
> algorithms may not give a good result.
>
> Maybe I'm trying too hard, but it's important for what I'm doing that I
> don't have a lot of collisions so I want a good quality hash function.
>
> What's the standard way of hashing non-object values in Cocoa?

For primitives, the hash value can generally just be itself.

Recall that NSUinteger is just a typedef for either int (in 32-bit) or
long (in 64-bit). So it's just an integer.

You have a pair of floats. The simplest thing to do would be to cast
them to NSUInteger, thereby truncating off the decimal bits, and then
XOR the result together:

- (NSUInteger)hash { return (NSUInteger)p.x ^ (NSUInteger)p.y; }

Note that this stops making much sense if you expect your points to be
fractional values, and you want different fractional values to be
considered unequal*. In that case, I'd recommend simply using the
whole float bit-pattern as your hash:

static NSUInteger CGFloatHash(CGFloat f) { return *(NSUInteger *)&f; }

- (NSUInteger)hash { return CGFloatHash(p.x) ^ CGFloatHash(p.y); }

(This works in both 32-bit and 64-bit since NSUInteger and CGFloat
happen to be the same size. If you use this in real code then I
recommend at least adding a check that the sizes are in fact equal and
failing in some loud, obvious way if they aren't so you don't end up
reading junk.)

Note that if you ever expect to have both positive zero and negative
zero in your points then this will fall apart, as negative zero and
positive zero can compare as equal but don't have matching bit
patterns. The solution to this is left as an exercise to the reader,
with a pointer to the IEEE 754 spec.

* Note that in general it's bad to compare floating point numbers with
non-integral parts for equality anyway. Two numbers which you think
should be equal may well not be due to rounding error in the
calculations which generated them. There's even an optional gcc
warning flag, -Wfloat-equal, which will produce a warning any time the
== operator is used on floating point numbers. Thus if your instance
variables are NSPoints, and you expect those points to have fractional
values, and you're using those variables as part of your equality
comparison, you're probably doing something wrong. (Although if you
only expect two floats to be equal when you've merely saved a copy of
one to look up later, then that can be reasonably expected to work.)

Mike
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: NSUInteger hash

[Nick Zitzmann]

On Aug 16, 2008, at 1:57 PM, Steve Wart wrote:


What's the standard way of hashing non-object values in Cocoa?



Something like this ought to work: (warning - written in Mail,  
untested, use at your own risk)


[[NSNumber numberWithUnsignedInteger:someNSUInteger] hash];

You can use NSValue to turn other Foundation data structures into  
objects.


Nick Zitzmann


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Preferred Wrapper for TCP Sockets Over Local Network?

[Marco Masser]

I would like to be able to use an SSL certificate, but, beyond that,  
my needs aren't exotic.  Ease-of-use and reliability would be a big  
plus.  I've also considered a Ruby class that would handle the TCP  
messaging and pass responses back to the Cocoa-based app.  Any  
suggestions?


Maybe the NSStream class is what you're looking for, especially the  
NSOutputStream and NSInputStream classes. There's a sample code called  
Cocoa Echo that shows how to use them. They are really easy to  
implement and they work with SSL, too (although the Cocoa Echo sample  
doesn't cover that).

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

NSUInteger hash

[Steve Wart]

Hi all,

I'm just getting started with Cocoa and I'm trying to implement hash and
isEqual: methods according to the recommendations in the coding guidelines.

To implement a hash method I would normally just hash the receiver's
instance variables together and xor the result, but this only works if the
instance variables are objects.

However my instance variables are NSPoints, which are defined as structs,
not objects. The C programmer in me wants to cast the floats into integers
and hash those, but we are in a 64-bit world now, and I assume that 32-bit
algorithms may not give a good result.

Maybe I'm trying too hard, but it's important for what I'm doing that I
don't have a lot of collisions so I want a good quality hash function.

What's the standard way of hashing non-object values in Cocoa?

Thanks,
Steve
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Window 'close' action fails

[dct]

My 'close' problem is solved by changing

- (IBAction)quit:(id)sender
{
[self close];
}

to

- (IBAction)quit:(id)sender
{
[splotWindow close];
}

where splotWindow is a File's Owner outlet connected to the nib's  
(only) window.


I'd still like to know why "[self close]" failed in this case--but I  
can live with the solution without knowing why it works in some cases  
and not in others.


Don
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Preferred Wrapper for TCP Sockets Over Local Network?

[Brad Gibbs]

Hi,

I'm looking for a Cocoa class to establish a TCP socket with another  
machine on a local network (non-OS X).  I've found Omni Networking,  
AsyncSocket and NetSocket.  I've read conflicting reports of the  
suitability of NSSocketPort for non-DO-related work.  I would like to  
be able to use an SSL certificate, but, beyond that, my needs aren't  
exotic.  Ease-of-use and reliability would be a big plus.  I've also  
considered a Ruby class that would handle the TCP messaging and pass  
responses back to the Cocoa-based app.  Any suggestions?


Thanks,

Brad
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: @property and @synthesize not working

[Chris Hanson]

On Aug 13, 2008, at 6:47 PM, Nathan Gilmore wrote:

I am a newbie and I am having trouble getting my setter to work when  
I use @synthesize.  Here is the code:



@interface DayTaskController : NSArrayController {
NSCalendarDate *searchDate;
}



@property(readwrite, assign) NSCalendarDate *searchDate;


This should really be "copy" rather than "assign" as NSDate and  
NSCalendarDate conform to NSCopying.  At the very least, it should be  
"retain" unless you're writing GC-only code.


 -- Chris

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Using Flex/Lex in a Cocoa project

[Michael Ash]

On Fri, Aug 15, 2008 at 10:53 PM, John Joyce
<[EMAIL PROTECTED]> wrote:
> Right now, I'm toying with using Flex/Lex in a Cocoa project.
> Unfortunately, I don't see a reliable or easy way to handle NSStrings
> correctly all the time with Flex.
> Does anybody have any suggestions for such text handling and reliable
> unicode aware regexes?
> I'm seriously not interested in implementing such details in C with Flex.
> Flex is fast and cool for that, but if it's going to be stupidly difficult
> to use reliably with other languages on a mac, it's not a good idea for me.

Depending on exactly what you need, unicode awareness can be fairly
straightforward.

Commonly, unicode in regexes is only needed to pass through
undifferentiated blobs of text, with ASCII delimiters. For example,
imagine parsing a CSV file which potentially has unicode text inside
the quotes. For this case, you can convert the file to UTF-8, and then
constructs like . will accept them. All non-ASCII characters in UTF-8
are represented as bytes 128-255, so if you just pass those through
then you'll be fine. But be aware of some potential problem areas:

- Each non-ASCII character will be more than one byte, and flex will
think of it as more than one character. Write your regexes
accordingly. In particular, avoid length limits on runs of arbitrary
characters, and avoid using non-ASCII characters directly in your
regex.

- It's very difficult to split UTF-8 strings correctly. If you
encounter a run of non-ASCII characters, ensure that you follow that
run through the end, until you get back to ASCII. Don't have a regex
that stops in the middle of it and then expects your code to be able
to do something useful with it.

- If you need to do something with non-ASCII characters besides read
them in one side and write them out the other, for example doing
something special with all accented characters, then Flex is probably
not the right answer.

Besides this it ought to be pretty straightforward. Since Flex just
passes your code straight through to the compiler, you can write
Objective-C in the actions (as long as you compile the result as
Objective-C, of course!), convert the text from UTF-8 back to an
NSString, and take things from there.

Mike
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Changing NSTextFieldCells' editing appearance?

[Ross Carter]

On Aug 15, 2008, at 1:41 PM, [EMAIL PROTECTED] wrote:



-setBackgroundColor: didn't work?



Nope, it didn't. But even if it would've, the background would have  
been
visible at all times. I'm sorry if I didn't write clearly enough,  
but it's

only when the cell is being edited that the background becomes black
(Instead of white like it usually does). When I'm not editing the  
cell,

the cell doesn't have a background.


To change the background color, and the foreground color too for that  
matter, you could supply a custom field editor and override  
setSelectedTextAttributes:.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Making a bound view re-read its value

[Michael Ash]

On Fri, Aug 15, 2008 at 6:43 PM, Quincey Morris
<[EMAIL PROTECTED]> wrote:
> Lastly, before I shut up, in both Markus's question and the thread that Adam
> referred to, the idea was to trigger a KVO update when the property value
> was known to have *not* changed. In those circumstances, I still believe,
> the "emptiness" of the willChange/didChange is moot -- if triggering a KVO
> update is the correct thing to do in that case, then calling
> willChange/didChange is a valid way to do it in that case.

Right, but why are you doing this? If the value hasn't changed, then
there should be no point in triggering a KVO update, because the
entire purpose of a KVO update is to notify when the value changes.
Needing to send such an empty update is indicative of some sort of
problem with your code.

Mike
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Opening an external file in a external application

[has]

John Love wrote:


Really though, what's best/practical/possible all depends on what
you're trying to do, so if you want more advice then you'll need to
provide more information.


Very short info list is as follows (stuff I need to do from within my
Cocoa app):

1) be able to save the Excel spreadsheet


Opening and saving Excel workbooks can be done with Apple events, e.g.  
using objc-appscript [1]:



// To create glue:  osaglue  -o MEGlue  -p ME  Microsoft Excel

MEApplication *microsoftExcel = [MEApplication applicationWithName:  
@"Microsoft Excel"];


// open file specified by HFS path

MEOpenWorkbookCommand *cmd = [[microsoftExcel openWorkbook]
workbookFileName: @"Mac 
HD:Users:foo:Workbook1.xlsx"];

id result = [cmd send]; // result is a by-name reference to the new  
workbook, or nil if an error occurred



// save in new file

MEReference *ref = [[microsoftExcel workbooks] byName:  
@"Workbook1.xlsx"];


MESaveWorkbookAsCommand *cmd = [[ref saveWorkbookAs]
filename: @"Mac HD:Users:foo:Workbook2.xlsx"];

id result = [cmd send]; // result is nil if an error occurred


Two potential problems to be aware of:

1. Excel stupidly uses HFS path strings in its 'open workbook' and  
'save workbook as' commands. This means you'll have big problems if  
you have another volume with the same name as the one you're opening  
from/saving to, as HFS paths can't distinguish between identically  
named volumes. (Better designed applications use alias and file URL  
types to identify filesystem objects and locations.)


You might be able to work around this issue by using the standard  
'open' and 'save' commands, although you lose the additional features  
provided by 'open workbook' and 'save workbook as'. Or you may  
consider using HFS paths to be an acceptable risk and just put up with  
them.


2. References returned by Excel only identify workbook objects by- 
index or by-name references. That makes it tricky to ensure you've a  
stable handle on the workbook for the length of time it's open. (By- 
index specifiers are sensitive to element order; by-name specifiers  
can't distinguish between two elements with the same name. Only by-id  
specifiers are guaranteed to be unique and stable over a target  
process's lifetime, but most apps don't use those.) I did wonder if  
using a by-test specifier would work; something like:


tell app "Excel"
tell first workbook whose full name = HFS_path_to_file
-- do stuff here
end
end

but it doesn't work, so you'll either need to iterate over elements  
and compare their paths yourself or else just use the existing by-name  
references and trust that nobody opens another file with the same name  
while your program is doing its thing.




2) be able to stop any calculation in progress


Dunno myself; you'll need to ask someone with more Excel scripting  
experience.




3) be able to detect if the user closed the spreadsheet "behind the
back" of my Cocoa app, upon which my Cocoa app would raise a NSAlert.



Assuming you've figured out a way to uniquely identify your workbook  
element, you could poll Excel at regular intervals to see if it still  
exists.



HTH

has

[1] Be aware that Office apps are a rather eccentric bunch even by  
AppleScripting standards, but appscript's application compatibility is  
very nearly as good as AppleScript's these days (and sometimes even  
better) so I don't think it'll have any problems.


--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Table column header not highlighted at first

[Graham Cox]

On 16 Aug 2008, at 1:36 am, Graham Cox wrote:

I need to figure out why the second table works even though I'm not  
doing anything special (and none of the autosave stuff you mentioned  
either).



OK, very simple: it was set in the nib. I didn't realise that  
presetting this in the nib was possible, so I must have set it up that  
way more or less by accident. OK, my understanding has improved...  
(Thanks!)



Now I have a new problem which is somewhat related (same tables and to  
do with these sort descriptors).


Table has two columns, one of which contains strings, the other,  
checkboxes. I set up a sort descriptor for the strings column and that  
works great. Then I came to add a sort descriptor to the checkbox  
column. This requires a custom compare method so I wrote one, then set  
that up as the sort descriptor's selector, with 'self' as the keyed  
property.


Something weird happens in IB. As soon as I add this information to  
the column, my two column headers seem to get locked together - they  
both turn blue at the same time, and clicking either one inverts both  
of them together. I can't seem to fix this - even scrapping the table  
and starting over I end up in the same fix. This is in IB long before  
my own code gets a shot at it - and when it does it's the same story -  
the columns lock together.


What on earth is going on, and how to fix it?

tia,

Graham
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Problem with NSImage and .PNG file

[Rainer Brockerhoff]

At 03:26 -0700 16/08/08, [EMAIL PROTECTED] wrote:
>From: Matt <[EMAIL PROTECTED]>
>Date: Fri, 15 Aug 2008 13:54:32 -0700
>Message-ID: <[EMAIL PROTECTED]>
>Subject: Problem with NSImage and .PNG file
>Message: 4
>
>I have an image that is 7200x32 pixels, which is used to store a series of
>32x32 tiles. When drawing from this NSImage, the further towards the end of
>the image (right edge) the subrect goes, the blurrier it gets drawn.
>...
>I found that the .PNG NSImage was returning a width of 7199.099 pixels,
>instead of 7200. Manually setting the NSImage's width to 7200 before drawing
>fixed this issue and resulted in the correct, non-blurry subrectangles being
>drawn.
>
>Has anyone encountered this issue before? Is this a bug within NSImage's
>handling of PNG's or could this be a problem with my image file itself, a
>DPI issue perhaps?

It's a bug in the image itself, or rather, in the generating software. I have a 
bug filed (still open, rdar://5532687) which says, in part:
>When saving .png files, Preview 4.0(467) generates incorrect values for the 
>file's DPI.
>...
>See http://www.libpng.org/pub/png/spec/1.1/PNG-Chunks.html#C.pHYs
>The 'pHYs' chunk can specify either "unknown unit" (which makes the file 
>default to 72 dpi when opened) or "meter". Preview now seems to generate the 
>latter specification. As 72 dpi don't fit exactly into metric units, the 
>measurement is rounded up, producing the 72.009 value.
>Solution:
>When saving 72 dpi pictures, specify "unknown unit" in the 'pHYs' chunk.

I haven't checked if that has been fixed in Leopard Preview, though; I suppose 
not, as the bug's still open.

-- 
Rainer Brockerhoff  <[EMAIL PROTECTED]>
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
 In their own business even sages err."
Weblog: http://www.brockerhoff.net/bb/viewtopic.php
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Core Data, xcdatamodel

[Tim Isted]

I'm assuming that you are using NSArrayControllers in your Interface  
Builder nib/xib file...


Bind the Content Set for the rgb controller to the collection  
controller's 'selection' with a model key path of whatever your  
relationship is called (ie the to-many relationship in the collection  
entity that points to the rgb values objects). This will offer the  
restriction you need to have bound tableviews showing only the rgb  
values that are related to a selected collection object.


You can also then bind the enabled attribute of your Add button to the  
rgb controller's canAdd key. The button will then only be enabled if  
there is an object created and selected in your collection array  
controller.


Tim

On 16 Aug 2008, at 08:20, R T wrote:

From the xcdatamodel of a "Core Data Document-based Application",   
I have two entities...


1st one entity is a set of rgb values.
2nd the other entity is a collection of these sets.

... so the add button of the 1st entity should not be available  
until an object of the 2nd entity is added and selected. The 1st  
entities tableview should show only the set of rgb values of a  
selected 2nd entity object.


I've created these two entities, but I do not know how to restrict  
the add button, nor how to limit whats displayed.

How do I configure these entities so they work correctly?

Thanks
Rick Tschudin


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: what is radar:// supposed to open?

[Wade Tregaskis]

sorry not totally cocoa but this is the 2nd or 3rd time I've seen 'radar://' 
, clicked it, and I get an instant crash of something called  
mobilesafari. What's supposed to open radar:// links? I tried safari  
but it just does the same thing.


I'd actually like to be able to track some of these (and other) bugs.


Apple's bug tracking system is for the most part not open to anyone  
outside the company.  The portion that is, the public interface to it,  
is found at http://bugreport.apple.com/, where you can file new bug  
reports and monitor those you've filed to date.  There are no  
provisions for you to be able to look at anyone else's bug reports -  
other than asking them yourself - though you are welcome to contact  
Developer Technical Support (DTS, [EMAIL PROTECTED]) to ask for feedback.   
Typically though they'll still only provide information about the bugs  
you've filed yourself.  I can't and am not speaking on official policy  
as to why this is as it is, though you can probably appreciate the  
privacy and legal issues involved.


As to the URL syntax itself... in a nutshell, it's for the convenience  
of Apple employees for whom clicking on such links does take them  
directly to the report in question.


Wade
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: creating files to write data to?

[Jason Coco]

On Aug 15, 2008, at 19:35 , Andy Lee wrote:


On Aug 15, 2008, at 6:43 PM, Jason Coco wrote:
Adding the @ just makes it an NSString constant... but writeData  
still requires (NSData *), not (NSString *).


Argh!  Or perhaps, given the nature of this error, which I missed, I  
should say "Arg!"


Surely you got a compiler warning?  If you ignored that, surely a  
runtime error?


Check your errors, both at compile time and runtime (and treat  
warnings as errors).


Yeah... I was thinking the same thing... you /must/ have got  
warnings... eventually you would have gotten an Exception I think :)

smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Core Data, xcdatamodel

[R T]

>From the xcdatamodel of a "Core Data Document-based Application",  I have two 
>entities...

1st one entity is a set of rgb values.
2nd the other entity is a collection of these sets.

... so the add button of the 1st entity should not be available until an object 
of the 2nd entity is added and selected. The 1st entities tableview should show 
only the set of rgb values of a selected 2nd entity object.

I've created these two entities, but I do not know how to restrict the add 
button, nor how to limit whats displayed.
How do I configure these entities so they work correctly?

Thanks
Rick Tschudin


  
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]