date:20081010

On Fri, Oct 10, 2008 at 1:15 AM, Graham Cox [EMAIL PROTECTED] wrote:
 I think I'll do it this way unless I hear some good arguments against.

The user might have very legitimate reason to play with things in
~/Library/Application Support.  As such, I'd hesitate to confuse the
user with weird names.  In the worst case, the user might delete the
folder in confusion.

Your app's bundle isn't named with a reverse domain name, so I
wouldn't do it for the Application Support folder either.

--Kyle Sluder
___

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: Strategy for naming support folder

2008-10-10 Thread j o a r



On Oct 9, 2008, at 11:16 PM, Kyle Sluder wrote:


The user might have very legitimate reason to play with things in
~/Library/Application Support. As such, I'd hesitate to confuse the
user with weird names. In the worst case, the user might delete the
folder in confusion.

Your app's bundle isn't named with a reverse domain name, so I
wouldn't do it for the Application Support folder either.



The same thing could be said about preference files too though, and  
they're stored using the bundle identifier per default.


The name is also not as stable as the bundle identifier. The name of  
the app could, for example, be localized in the Finder. The name of  
many apps also include a variable suffix, like a version number,   
Lite, et.c.


Finally, ~/Library is for all intent and purposes off limits for  
normal users, ie. the type of users who would be confused about a  
bundle identifier.


j o a r


___

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: Strategy for naming support folder

2008-10-10 Thread Rob Keniger



On 10/10/2008, at 4:36 PM, j o a r wrote:

The same thing could be said about preference files too though, and  
they're stored using the bundle identifier per default.


The name is also not as stable as the bundle identifier. The name of  
the app could, for example, be localized in the Finder. The name of  
many apps also include a variable suffix, like a version number,   
Lite, et.c.


Finally, ~/Library is for all intent and purposes off limits for  
normal users, ie. the type of users who would be confused about a  
bundle identifier.


This might be true but I have a lot of apps installed (more than 250,  
not counting the Apple pre-installed apps) and the count of those that  
use a bundle identifier as the name of their folder in the ~/Library/ 
Application Support folder is precisely zero.


--
Rob Keniger



___

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: Strategy for naming support folder

On Fri, Oct 10, 2008 at 2:36 AM, j o a r [EMAIL PROTECTED] wrote:
 The same thing could be said about preference files too though, and they're
 stored using the bundle identifier per default.

Preference files are opaque; the user's interaction with preference
files should be (ideally) through the app's UI or through the
`defaults` tool.  There are legitimate use cases for accessing the
Application Support folder through the Finder, if the files therein
are meant to be treated as such (plugins come to mind).  Ideally such
circumstances should be infrequent and well-defined; most interaction
with Application Support should probably be done with app-specific UI
instead.

(As a side note, I'm not a fan of the naming scheme used for
preference files.  The hierarchical naming scheme used for preference
files is merely conventional; they don't factor into the defaults
hierarchy at all.  The system also provides no conveniences just
because there's a plist file whose name matches your app's bundle
identifier.)

 The name is also not as stable as the bundle identifier. The name of the app
 could, for example, be localized in the Finder. The name of many apps also
 include a variable suffix, like a version number,  Lite, et.c.

So?  There's no mandatory correlation between an app's name and where
it looks in Application Support.  There's nothing preventing BBEdit
Lite.app, for example, to look in both ~/Library/Application
Support/BBEdit{, Lite}.  Version numbers probably shouldn't be used in
the app's name anyway.

 Finally, ~/Library is for all intent and purposes off limits for normal
 users, ie. the type of users who would be confused about a bundle
 identifier.

I disagree, as above.

You're going to be hardcoding the name of the folder anyway, whether
that hardcoding happens to be in the form of a string in your source
code or the CFBundleIdentifier in your Info.plist.  Why needlessly
inconvenience the user when you derive no benefit?

--Kyle Sluder
___

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: Strategy for naming support folder

2008-10-10 Thread j o a r



On Oct 10, 2008, at 12:02 AM, Rob Keniger wrote:

This might be true but I have a lot of apps installed (more than  
250, not counting the Apple pre-installed apps) and the count of  
those that use a bundle identifier as the name of their folder in  
the ~/Library/Application Support folder is precisely zero.



I never claimed that my opinion represents what is in use, quite the  
opposite: See my original reply in this thread. I'm arguing for what I  
consider to be *better*.


j o a r


___

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: Strategy for naming support folder



On 10 Oct 2008, at 6:06 pm, Kyle Sluder wrote:


You're going to be hardcoding the name of the folder anyway, whether
that hardcoding happens to be in the form of a string in your source
code or the CFBundleIdentifier in your Info.plist.  Why needlessly
inconvenience the user when you derive no benefit?



There's an obvious programmer benefit: I can write code that works  
correctly in any app I drop it into to read/write files in that folder  
without having to go in and customise it to each app. However, I would  
agree that programmer convenience should always take a back seat to  
user convenience, so the question remains what's best for the user.


I personally almost never have to dig around in Application Support  
folders. On the very rare occasions I've peeked in there it's not  
always obvious where to look - for example the common hierarchy of  
Company/App Name/Sub folders is particularly irritating for apps where  
the company that produced it is not immediately known. How many people  
recall that Super Blogging App was produced by Back Shed  
Enterprises, or that Office was a product from some outfit called  
Microsoft? I mean, who? ;-) So a simple App name is easier to find,  
but then the potential for name collisions may be higher.


The use of the bundle identifier means that the app name is visible at  
the top level so it should be easier to fix on the right folder, but  
the extra components eliminate collisions. Whether it exposes too much  
geekery to the public? Maybe.


I do tend to agree that it's not a place users should be visiting  
routinely, and the app itself should offer an interface where  
necessary to manage its own stuff in there. As with prefs, odds are  
that the only time a user will ever go in there is to fix a problem  
with a damaged file, so there's no clear advantage to making it  
different from the preferences situation that I can see. Why is anyone  
poking around in there? (Not a rhetorical question, I'm interested in  
knowing what people do visit that folder for).



cheers, 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: How do I debug this?

2008-10-10 Thread Ashley Clark

 Stack trace:

 #00x92badc66 in -[NSException raise]
 #10x901c3283 in -[NSCarbonMenuImpl
 performActionWithHighlightingForItemAtIndex:]
 #20x901a0122 in AppKitMenuEventHandler
 #30x90c79303 in DispatchEventToHandlers
 #40x90c7873d in SendEventToEventTargetInternal
 #50x90c95092 in SendEventToEventTarget
 #60x90cc931d in SendHICommandEvent
 #70x90cefb6f in SendMenuCommandWithContextAndModifiers
 #80x90cefb2c in SendMenuItemSelectedEvent
 #90x90cefa3e in FinishMenuSelection
 #10   0x90ccc5cc in MenuSelectCore
 #11   0x90ccbfb7 in _HandleMenuSelection2
 #12   0x90ccbe2b in _HandleMenuSelection
 #13   0x900dcad3 in _NSHandleCarbonMenuEvent
 #14   0x900438dc in _DPSNextEvent
 #15   0x90042ca0 in -[NSApplication
 nextEventMatchingMask:untilDate:inMode:dequeue:]
 #16   0x9003bcdb in -[NSApplication run]
 #17   0x90008f14 in NSApplicationMain
 #18   0x4e73 in main at main.m:13

 Leading to the message:

 2008-10-10 15:57:59.552 Ortelius[43213:813] *** -[NSCFArray
 objectAtIndex:]: index (0) beyond bounds (0)

 How can I find out what array is being overrun here? There's no code
 of my own in the stack trace at this point, which appears to be the
 tail end of a menu selection (which makes sense, as it occurs during
 loading a file in response to the Open menu command). So far I've
 just been trying to guess what the problem might be by following
 'hunches' but so far drawn a blank.


Have you tried setting a breakpoint on objc_exception_throw? That should
show you the moment the exception is being created and should let you know
who's calling the objectAtIndex:0 method.

Just doing a simple test here I get a stack trace that looks like this:

#0  0x96f9ee17 in objc_exception_throw
#1  0x968a1f2b in +[NSException raise:format:arguments:]
#2  0x968a1f6a in +[NSException raise:format:]
#3  0x95587bbf in _NSArrayRaiseBoundException
#4  0x95505548 in -[NSCFArray objectAtIndex:]
#5  0x0001fdb6 in -[JTApplicationDelegate showInventoryInformation:] at
JTApplicationDelegate.m:35
#6  0x95907b03 in -[NSApplication sendAction:to:from:]
#7  0x959b6540 in -[NSMenu performActionForItemAtIndex:]
#8  0x959b6245 in -[NSCarbonMenuImpl
performActionWithHighlightingForItemAtIndex:]
...snip...
#25 0x2220 in main at main.m:13


-- 
Ashley Clark

___

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]

appscript installation

2008-10-10 Thread John Love

I've downloaded appscript.  I do not know if the appscript folder must  
be placed in a precise spot, so I just placed it where I wanted to.   
Maybe it should be in the Developer folder??


Since objc-appscript is based on py-appscript, I have typed

sudo easy_install appscript

in Terminal and the usual long output resulted.

But no where can I find the osaglue tool so I can then go to Terminal  
(?) and type such things as:


osaglue -o TEGlue TE /Applications/TextEdit.app

Terminal does not understand the osaglue command.

My elevator is definitely not up on this one.

John Love

___

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: Key filtering in the NSSavePanel?

2008-10-10 Thread Fritz Anderson


On 10 Oct 2008, at 7:15 AM, Bob Stuller wrote:

I have a need to restrict filenames coming out of a NSSavePanel.  Is  
there anyway to hook in there  vet the keystrokes?


Not at the keystroke level, and that's a tricky level to work at; the  
usual philosophy on text fields is to stay out of the user's face  
until he's committed himself to his intended entry.


Tell us why the delegate methods panel:isValidFilename: and  
panel:userEnteredFilename:confirmed: don't suit your needs. Or, why  
you can't let the user press save, examine the results, and post an  
informative alert explaining the problem.


— F

--
Fritz Anderson -- Xcode 3 Unleashed: Now in its second printing -- http://x3u.manoverboard.org/ 



___

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: Finder Crashes on File Open

2008-10-10 Thread Negm-Awad Amin



Am Do,09.10.2008 um 19:47 schrieb Brian Miller:


Hi All,

I have a Cocoa Core Data Document based application.  When files  
created with this application are opened via the Finder (or double  
clicked), the Finder crashes and restarts every time.  Opening files  
from within the application work fine, using Open With works fine.


The Finder crashes before the application is launched.

This happens even on a clean Leopard install.

This only happens on Leopard, works fine in Tiger.

I have changed store types to SQL, etc. problem persists.  I have  
changed extension, etc. and problem persists.


I am including Finder Crash report, I can provide other info as  
needed.  Since my app doesn't launch, I can't figure out what is  
going on.


Any help would be greatly appreciated.

http://www.apple.com/support/downloads/





Thanks,
Brian Miller


Process: Finder [13544]
Path:/System/Library/CoreServices/Finder.app/Contents/ 
MacOS/Finder

Identifier:  com.apple.finder
Version: 10.5.6 (10.5.6)
Build Info:  Finder_FE-6071900~15
Code Type:   X86 (Native)
Parent Process:  launchd [109]

Date/Time:   2008-10-09 00:13:50.397 -0700
OS Version:  Mac OS X 10.5.5 (9F33)
Report Version:  6

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0005
Crashed Thread:  0

Thread 0 Crashed:
0   com.apple.CoreFoundation0x952332d4 CFRetain + 36
1   com.apple.CoreFoundation  	0x95203282 CFDictionaryAddValue +  
530

2   com.apple.CoreFoundation0x95203894 CFDictionaryCreate + 132
3   com.apple.LaunchServices  	0x96fd9cb0  
CFDictionary::CFDictionary(unsigned int, void const**, void const**)  
+ 74
4   com.apple.LaunchServices  	0x96feb395  
_LSFindApplicationsItem + 39

5   com.apple.LaunchServices0x96fd4b30 _LSOpenStuff + 1924
6   com.apple.LaunchServices  	0x96ff5462  
_LSOpenItemsWithRole_Common(FSRef const*, long, unsigned long,  
AEKeyDesc const*, LSApplicationParameters_V1 const*,  
ProcessSerialNumber*, long, FSRef*) + 374

7   com.apple.LaunchServices0x96ff2916 LSOpenFromRefSpec + 708
8   com.apple.finder0x0008f576 0x1000 + 583030
9   com.apple.finder0x0008f145 0x1000 + 581957
10  com.apple.finder0x0008e1e1 0x1000 + 578017
11  com.apple.finder0x00082f9f 0x1000 + 532383
12  com.apple.finder0x000d5a70 0x1000 + 871024
13  com.apple.finder0x000898b6 0x1000 + 559286
14  com.apple.finder0x0002bced 0x1000 + 175341
15  com.apple.finder0x00031a25 0x1000 + 199205
16  com.apple.finder0x00026822 0x1000 + 153634
17  com.apple.finder0x000266a2 0x1000 + 153250
18  com.apple.finder0x0002 0x1000 + 153190
19  com.apple.HIToolbox   	0x92166303  
DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*,  
HandlerCallRec*) + 1181
20  com.apple.HIToolbox   	0x9216573d  
SendEventToEventTargetInternal(OpaqueEventRef*,  
OpaqueEventTargetRef*, HandlerCallRec*) + 405
21  com.apple.HIToolbox   	0x921655a2  
SendEventToEventTargetWithOptions + 58

22  com.apple.finder0x00080359 0x1000 + 521049
23  com.apple.finder0x00045067 0x1000 + 278631
24  com.apple.finder0x0004483f 0x1000 + 276543
25  com.apple.finder0x00026822 0x1000 + 153634
26  com.apple.finder0x000266a2 0x1000 + 153250
27  com.apple.finder0x0002 0x1000 + 153190
28  com.apple.HIToolbox   	0x92166303  
DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*,  
HandlerCallRec*) + 1181
29  com.apple.HIToolbox   	0x9216573d  
SendEventToEventTargetInternal(OpaqueEventRef*,  
OpaqueEventTargetRef*, HandlerCallRec*) + 405
30  com.apple.HIToolbox   	0x92182092 SendEventToEventTarget  
+ 52
31  com.apple.HIToolbox   	0x92194268  
ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*,  
OpaqueEventRef*, void*) + 1208
32  com.apple.HIToolbox   	0x921666bc  
DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*,  
HandlerCallRec*) + 2134
33  com.apple.HIToolbox   	0x9216573d  
SendEventToEventTargetInternal(OpaqueEventRef*,  
OpaqueEventTargetRef*, HandlerCallRec*) + 405
34  com.apple.HIToolbox   	0x92182092 SendEventToEventTarget  
+ 52
35  com.apple.HIToolbox   	0x921eec60 ToolboxEventDispatcher  
+ 86
36  com.apple.HIToolbox   	0x921eb4ba  
RunApplicationEventLoop + 222

37  com.apple.finder0x00023ab1 0x1000 + 142001
38  com.apple.finder0x000f39cd 0x1000 + 993741
39  com.apple.finder0x9a6e 0x1000 + 35438

Thread 1:
0   libSystem.B.dylib   0x9364b4a6 mach_msg_trap + 10
1   libSystem.B.dylib

Re: KVC Question

2008-10-10 Thread Nathan Kinsinger



On Oct 9, 2008, at 8:04 PM, Joseph Crawford wrote:

The issue I am running into is that when I run a search only the  
first row in the table view is populated with data from my results  
array.  I am thinking this is because the valueForKey method is not  
passed the row index so it does not know which result object to  
return.


I have the model key path for my first name column set to  
primaryPerson.firstName, this is calling the primaryPerson method  
which returns an instance of the person object.  Then it will use  
the value of the firstName property to populate the table column.


The problem is with the following in CBSManagingViewController:


- (CBSPerson *)primaryPerson
{
// This will loop over all objects in the result people  
array and find the primary person
// IB will bind to this method to get at the data for the  
table view

// arrangedObject.primaryPerson.firstName
NSMutableArray *res = [self results];
if( [res count]  0 )
{
for(CBSSearchNameResult *result in res)
{
NSMutableArray *people = [result people];
if( [people count]  0)
{
for(CBSPerson *person in people)
{
if([[person rank]  
isEqualToString:@primary])

{
return person;
}
}
}
}
}
}


This will only ever return the first primary person of the first  
result. Every time it is called it will start over and again return  
the first primary person of the first result. Note that the return  
statement will jump out of the routine immediately and the rest of the  
iterations of the loops will never execute.


You need to move the primaryPerson: (and primaryPhone:) logic out of  
the CBSManagingViewController and into the CBSSearchNameResult class.  
You just need the part above where it starts with: for(CBSPerson  
*person in people).


On a side note, you don't need to check the count of the arrays before  
each for-in loop, if the array is empty the loop will skip over it's  
code.


Given that the tableview is showing the one row, and your  
primaryPerson: method is in the controller, I'm guessing that you set  
the NSArrayController's binding to the CBSManagingViewController  
itself. You need to bind to the results array of  
CBSManagingViewController. If the view controller is File's Owner then  
the binding for the content array should be:

Bind to: File's Owner
Model Key Path: results
Or you can go the tableview data source route and get rid of the  
existing bindings. Just make sure to bind the dataSource outlet of the  
tableview to File's Owner.


--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]

Re: __memcpy crash with [NSData -getBytes:range:]

2008-10-10 Thread Clark Cox

On Fri, Oct 10, 2008 at 2:48 AM, Daniel Kennett [EMAIL PROTECTED] wrote:
 Hi list,

 I'm having trouble reproducing (and fixing) a rare bug that I sometimes get
 reports about.

 Here's the code that causes the crash. streamPosition and length are checked
 to make sure they're within the range of the NSData object:

 // Allocate a buffer.
 void *buffer = malloc(length);

 // Fill the buffer with the requested bytes.
 [_data getBytes:buffer range:NSMakeRange(streamPosition, length)];

 Very occasionally, this fails with this crash:

 Exception:  EXC_BAD_ACCESS (0x0001)
 Codes:  KERN_PROTECTION_FAILURE (0x0002) at 0x

Since the address above is 0x, I suspect that buffer is NULL.
Are you checking malloc's return value? You may be exceeding your
process' 4GB address space.

-- 
Clark S. Cox III
[EMAIL PROTECTED]
___

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: How do I debug this?

2008-10-10 Thread Jens Miltner



Am 10.10.2008 um 07:13 schrieb Graham Cox:


Stack trace:

#0  0x92badc66 in -[NSException raise]
#1	0x901c3283 in -[NSCarbonMenuImpl  
performActionWithHighlightingForItemAtIndex:]

#2  0x901a0122 in AppKitMenuEventHandler
#3  0x90c79303 in DispatchEventToHandlers
#4  0x90c7873d in SendEventToEventTargetInternal
#5  0x90c95092 in SendEventToEventTarget
#6  0x90cc931d in SendHICommandEvent
#7  0x90cefb6f in SendMenuCommandWithContextAndModifiers
#8  0x90cefb2c in SendMenuItemSelectedEvent
#9  0x90cefa3e in FinishMenuSelection
#10 0x90ccc5cc in MenuSelectCore
#11 0x90ccbfb7 in _HandleMenuSelection2
#12 0x90ccbe2b in _HandleMenuSelection
#13 0x900dcad3 in _NSHandleCarbonMenuEvent
#14 0x900438dc in _DPSNextEvent
#15	0x90042ca0 in -[NSApplication  
nextEventMatchingMask:untilDate:inMode:dequeue:]

#16 0x9003bcdb in -[NSApplication run]
#17 0x90008f14 in NSApplicationMain
#18 0x4e73 in main at main.m:13

Leading to the message:

2008-10-10 15:57:59.552 Ortelius[43213:813] *** -[NSCFArray  
objectAtIndex:]: index (0) beyond bounds (0)



How can I find out what array is being overrun here? There's no code  
of my own in the stack trace at this point, which appears to be the  
tail end of a menu selection (which makes sense, as it occurs during  
loading a file in response to the Open menu command). So far I've  
just been trying to guess what the problem might be by following  
'hunches' but so far drawn a blank.


If you know which menu item to call and what part of your code is  
being called that eventually leads to raise that exception, you could  
break somewhere in your code, then add a breakpoint for -[NSCFArray  
objectAtIndex:] and run and note who calls this until the exception is  
raised (the exception logging feature might help here).


Apart from that, are you sure it's not -[NSCarbonMenuImpl  
performActionWithHighlightingForItemAtIndex:] that is calling - 
[NSArray objectAtIndex:] with an invalid index?
Not sure why that would happen, but from the backtrace, this too might  
be what's happening...


HTH,
-jens

___

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]

__memcpy crash with [NSData -getBytes:range:]

2008-10-10 Thread Daniel Kennett


Hi list,

I'm having trouble reproducing (and fixing) a rare bug that I  
sometimes get reports about.


Here's the code that causes the crash. streamPosition and length are  
checked to make sure they're within the range of the NSData object:


// Allocate a buffer.
void *buffer = malloc(length);

// Fill the buffer with the requested bytes.
[_data getBytes:buffer range:NSMakeRange(streamPosition, length)];

Very occasionally, this fails with this crash:

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:  KERN_PROTECTION_FAILURE (0x0002) at 0x

Thread 6 Crashed:
0   0x0d3f __memcpy + 1439 (cpu_capabilities.h:228)
1   com.apple.Foundation	0x9282e456 -[NSConcreteData  
getBytes:range:] + 267


I don't think it's the file that the NSData is created from - indeed,  
the customer sent me a copy of the file in question and it works  
perfectly on my machine. Any help in debugging this would be greatly  
appreciated! Surrounding the code in a @try block doesn't help - it  
still ends up with a hard crash (which is what I was expecting, given  
that is a EXC_BAD_ACCESS).


 Thanks,

-- Daniel

 ___

   [EMAIL PROTECTED]
   http://www.kennettnet.co.uk

Please include previous messages in any reply you send.



___

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: __memcpy crash with [NSData -getBytes:range:]

2008-10-10 Thread Matt Gough



On 10 Oct 2008, at 11:48, Daniel Kennett wrote:


// Allocate a buffer.
void *buffer = malloc(length);

// Fill the buffer with the requested bytes.
[_data getBytes:buffer range:NSMakeRange(streamPosition, length)];


Are you sure that buffer has actually been created? Maybe you are  
running out of RAM?


Matt
___

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]

Key filtering in the NSSavePanel?

2008-10-10 Thread Bob Stuller


Folks, Greetings!

I have a need to restrict filenames coming out of a NSSavePanel.  Is  
there anyway to hook in there  vet the keystrokes?


Peace,
Bob




As soon as we started programming, we found to our surprise that it  
wasn't as easy to get programs right as we had thought.  Debugging had  
to be discovered.  I can remember the exact instant when I realized  
that a large part of my life from then on was going to be spent in  
finding mistakes in my own programs.

-- Maurice Wilkes discovers debugging, 1949

___

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]

Fwd: Finder Crashes on File Open

2008-10-10 Thread Shawn Erickson

Oops missed the list...

On Thu, Oct 9, 2008 at 10:47 AM, Brian Miller [EMAIL PROTECTED] wrote:
 Hi All,

 I have a Cocoa Core Data Document based application.  When files created
 with this application are opened via the Finder (or double clicked), the
 Finder crashes and restarts every time.  Opening files from within the
 application work fine, using Open With works fine.

 The Finder crashes before the application is launched.

What does your Info.plist look like? All I can guess is that your
plist has some entries in it that are causing Launch Services grief.

-Shawn
___

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: NSCoding protocol

2008-10-10 Thread Negm-Awad Amin



Am Fr,03.10.2008 um 21:00 schrieb [EMAIL PROTECTED]:

I want MyClass to conform to the NSCoding protocol. But I'm puzzled  
about how to implement the initWithCoder: method.


Suppose I have this in MyClass.h:

NSString *S1, *S2, *S3;


and this in its init function:

S1 = @a string;
S2 = [[NSString alloc] init];
S3 = [NSString string];

So to conform to the protocol, I'd have something like this in  
MyClass.m too:

In addition to the replies I want to give a hint to something else:


- (id)initWithCoder:(NSCoder *)decoder {

self = [super init];
This is only correct, if your base class does not support NSCoding.  
Otherwise you have to call -initWithCoder: (super).


Because this depends of the base class, we have a fragile base class  
problem. (Adding NSCoding to the base class looks like doing  
everything correct inside the base class, but will cause MyClass as a  
subclass to a malfunction.) Keep in mind, that NSCoding can be added  
through a category. So it looks safer to do:


if( [super respondsToSelector:@selector( initWithCoder: )] {
   self = [super initWIthCoder:decoder];
} else {
   self = [super init];
}

I never had this problem in practice, but theoretically … (But maybe I  
got a paranoia.)


Cheers







S1 = [decoder decodeObjectForKey:@S1];
S2 = [[decoder decodeObjectForKey:@S2] retain];
S3 = [[decoder decodeObjectForKey:@S3] retain];
return self;
}

(I'm not posting the encodeWithCoder: method.)

So finally, my question: am I right to retain S2 and S3, and not S1?
___

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/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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]

CalendarStore sync failure

2008-10-10 Thread Dale Jensen

I'm trying to get iCal syncing going, and have followed the  
instructions given in the CalendarStore documentation right along, but  
I'm getting this thrown when I try to add an event:


2008-10-10 11:12:53.349 iCalExternalSync[30033:10b] SyncServices  
precondition failure in [ISyncConcreteSession  
pushChangesFromRecord:withIdentifier:]: you can't change the record's  
entity name from com.apple.calendars.DisplayAlarm to  
com.apple.calendars.AudioAlarm in {

com.apple.ical.sound = Basso;
com.apple.syncservices.RecordEntityName =  
com.apple.calendars.AudioAlarm;

owner = (
Event/p475
);
sound = Basso;
triggerduration = -64800;
}

This comes up whether I've an alarm attached to the event or not.  The  
event does get added, but I would like to clear up what's happening  
here.


Any ideas?  Thanks!


dale

--
Dale Jensen, CEO
Ntractive, LLC
[EMAIL PROTECTED]
http://www.ntractive.com
mobile: 701-215-0687



___

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: Multithreaded Core Data app design

2008-10-10 Thread Ron Lue-Sang

On Oct 9, 2008, at 2:44 AM, Ruotger Skupin wrote:

Hi,

Since Ron asked, let's move this to an own thread (no pun intended):

Am 08.10.2008 um 18:23 schrieb Ron Lue-Sang:

Hi,

I have a core data database with two contexts attached to it. One
read-only for the main thread and bindings, one read/write for a
background thread that takes data from the network and feeds it
into the database. I know this is an effed-up design you shouldn't
copy, but it won't change.
(For why this is a bad idea: http://lists.apple.com/archives/Cocoa-dev/2007/May/msg00066.html
but please let's not discuss this here, thx)

Where shall we discuss this then? I have comments =)

Here. Go ahead!

Ok! From the historical post, there are these items

4. The context seems to lock the store coordinator during a save!!!
(ouch!)

Yea. For multi-threaded programming correctness, you want this. The
coordinator level snapshots need to be updated, if you have multiple
contexts all in different threads and connected to the same
coordinator, you really want those contexts to leave the coordinator
in a consistent state. So, locking – Yay! And don't forget that when
YOUR code is fiddling with the coordinator, you're gonna want to lock
it too – like when adding or removing a store.

5. The data of an object is not automatically obtained from the
store. When the data is accessed and it's not there, it then is
obtained from the store. This is called a fault, firing a fault or
faulting. (I haven't got the hang of this part of the terminology yet)

Fault - your managed object when it doesn't have any of your data in
it yet.

Firing a fault - filling in your managed object with your data
Faulting - the general technique for making objects cheap by not
filling in their data until it's asked for

Read this link.

http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles/cdFaultingUniquing.html#/
/apple_ref/doc/uid/TP30001202-185436-TPXREF147

Read it like you mean it.

6. The context locks the store coordinator during the firing of a
fault (at least partially).

I'm not sure whether this is meant as a bad thing or not. Like item #4
above, it's a necessary thing when doing MT programming. The
coordinator keeps a cache of object values. When a fault gets fired,
its data comes from the coordinator. The coordinators cache can be
updated. The lock is necessary to ensure consistency.

7. Bindings tend to sometimes access an object's data at surprising
(or at least uncontrollable) times.

For the most part, if a view is onscreen, its bound properties are
going to need data. Your textField bound to your arrayController of
Person's showing the selection's firstName – the textField's gonna
need to get aPerson object's firstName. If your aPerson object is a
fault, when the binding asks [aPerson valueForKeyPath:@firstName],
that'll fire the fault. Yes, that'll mean locking the context and the
coordinator.

Now, after all that, hopefully this next part will make more sense.

If you hate lock contention on your main thread, use a separate
CoreData stack for each thread. Not just a different context, a
different stack.

See item 2 here
http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles/cdMultiThreading.html#/
/apple_ref/doc/uid/TP40003385-SW2

You don't get the shared row cache between threads, but the only
locking that'll happen is at the store file level, which for the
SQLite store is fast (I'm directly disputing item 3 in the post, which
I haven't copied here). With this design, long save operations on the
background thread shouldn't hang your UI thread.

--
RONZILLA

___

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: Strategy for naming support folder

On Fri, Oct 10, 2008 at 3:27 AM, j o a r [EMAIL PROTECTED] wrote:
Can you give a concrete example? I would argue that you're doing something
wrong if you ask your user to muck around in ~/Library. There are better
ways of solving the plugin problem - as demonstrated by both System
Preferences and Dashboard.

Reveal in Finder. Always a better option than implementing my own
half-assed file management utility when the user really wants to work
with files.

(As a side note, I'm not a fan of the naming scheme used for
preference files. The hierarchical naming scheme used for preference
files is merely conventional; they don't factor into the defaults
hierarchy at all. The system also provides no conveniences just
because there's a plist file whose name matches your app's bundle
identifier.)

I'm not sure that I get what you're saying here, but I think I have to
disagree: The functionality of NSUserDefaults is directly tied to your
bundle identifier.

This is true, but the user never sees that. It would be different if
the system used that bundle identifier to find the display name of the
associated application and used that for the preferences. (Ooh,
enhancement request time!)

My comment was not on how the application itself would find it's support
folder. You suggested that using the name of the bundle would make it easier
for the user to find the support folder, and I argued that this is not
always the case - in particular for localized versions.

If the app's bundle is localized, so too should its Application
Support folder.
http://developer.apple.com/documentation/MacOSX/Conceptual/BPFileSystem/Articles/DisplayNames.html#//apple_ref/doc/uid/20002298-109019-CJBHCGGA

I don't agree. Using a predictable, rather than arbitrary, naming scheme for
auxiliary resources benefits everyone. I also get the added benefit of
having a unique name for my support folder, avoiding potential collisions.

This is indeed a benefit. However, we're not talking about FourCCs
here, we have a lot more room to work with. I don't believe that the
potential for collisions is anywhere near the order of magnitude
FourCCs has.

I don't think that we need to take this any further though. Let's just agree
to disagree.

Agreed. :P Though I'm going to file that enhancement request anyway.
I don't think that telling users to categorically avoid the ~/Library
folder is a good idea.

--Kyle Sluder
___

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: NSCoding protocol

2008-10-10 Thread Clark Cox

On Fri, Oct 10, 2008 at 9:09 AM, Negm-Awad Amin [EMAIL PROTECTED] wrote:

 Am Fr,03.10.2008 um 21:00 schrieb [EMAIL PROTECTED]:

 I want MyClass to conform to the NSCoding protocol. But I'm puzzled about
 how to implement the initWithCoder: method.

 Suppose I have this in MyClass.h:

NSString *S1, *S2, *S3;


 and this in its init function:

S1 = @a string;
S2 = [[NSString alloc] init];
S3 = [NSString string];

 So to conform to the protocol, I'd have something like this in MyClass.m
 too:

 In addition to the replies I want to give a hint to something else:

 - (id)initWithCoder:(NSCoder *)decoder {

self = [super init];

 This is only correct, if your base class does not support NSCoding.
 Otherwise you have to call -initWithCoder: (super).

 Because this depends of the base class, we have a fragile base class
 problem. (Adding NSCoding to the base class looks like doing everything
 correct inside the base class, but will cause MyClass as a subclass to a
 malfunction.) Keep in mind, that NSCoding can be added through a category.
 So it looks safer to do:

 if( [super respondsToSelector:@selector( initWithCoder: )] {
   self = [super initWIthCoder:decoder];
 } else {
   self = [super init];
 }

No, this will not work. Unless you've implemented -respondsToSelector:
yourself, [super respondsToSelector:] and [self respondsToSelector:]
will always return the exact same value (because they call the exact
same method).



 I never had this problem in practice, but theoretically … (But maybe I got a
 paranoia.)

 Cheers






S1 = [decoder decodeObjectForKey:@S1];
S2 = [[decoder decodeObjectForKey:@S2] retain];
S3 = [[decoder decodeObjectForKey:@S3] retain];
return self;
 }

 (I'm not posting the encodeWithCoder: method.)

 So finally, my question: am I right to retain S2 and S3, and not S1?
 ___

 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/negm-awad%40cocoading.de

 This email sent to [EMAIL PROTECTED]

 Amin Negm-Awad
 [EMAIL PROTECTED]




 ___

 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/clarkcox3%40gmail.com

 This email sent to [EMAIL PROTECTED]




-- 
Clark S. Cox III
[EMAIL PROTECTED]
___

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]

inconsistent float behaviour

2008-10-10 Thread Steven Hamilton


Hi folks,
I think I need some help understanding floats.

I have a class that calculates a balance and places it in a table  
column. At the end of this method I NSLog the output like so;


NSLog(@current balance is: %@,balance);

and get

current balance is: 18976.69

in the console. So far so good.

The method plonks the balance into a table and returns it to whence it  
came. The table is sourced by the normal datasource delegate methods  
and the column has a number formatter on it set to Decimal #,##0,00##  
with half even rounding. I placed the last ##'s in there to check that  
the floats weren't producing decimals with more than 2 places but in  
my table column I get 18976.6995 which doesn't make sense. The float  
calculation is exactly 2 decimal places, I know that for a fact and  
NSLog proves it. Yet somehow, the table datasource appears to produce  
random decimal digits where i have the last ##.


Am I totally misunderstanding something about floats? Or is the extra  
##'s in the formatter making things up?

___

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: NSCoding protocol

2008-10-10 Thread Negm-Awad Amin



Am Fr,10.10.2008 um 18:17 schrieb Clark Cox:

On Fri, Oct 10, 2008 at 9:09 AM, Negm-Awad Amin [EMAIL PROTECTED] 
 wrote:


Am Fr,03.10.2008 um 21:00 schrieb [EMAIL PROTECTED]:

I want MyClass to conform to the NSCoding protocol. But I'm  
puzzled about

how to implement the initWithCoder: method.

Suppose I have this in MyClass.h:

  NSString *S1, *S2, *S3;


and this in its init function:

  S1 = @a string;
  S2 = [[NSString alloc] init];
  S3 = [NSString string];

So to conform to the protocol, I'd have something like this in  
MyClass.m

too:


In addition to the replies I want to give a hint to something else:


- (id)initWithCoder:(NSCoder *)decoder {

  self = [super init];


This is only correct, if your base class does not support NSCoding.
Otherwise you have to call -initWithCoder: (super).

Because this depends of the base class, we have a fragile base class
problem. (Adding NSCoding to the base class looks like doing  
everything
correct inside the base class, but will cause MyClass as a subclass  
to a
malfunction.) Keep in mind, that NSCoding can be added through a  
category.

So it looks safer to do:

if( [super respondsToSelector:@selector( initWithCoder: )] {
 self = [super initWIthCoder:decoder];
} else {
 self = [super init];
}


No, this will not work. Unless you've implemented -respondsToSelector:
yourself, [super respondsToSelector:] and [self respondsToSelector:]
will always return the exact same value (because they call the exact
same method).

Yup, you are complelty right. The correct code:

if( [BaseClass  
[EMAIL PROTECTED]( initIWithCoder: )] ) {

…

Sorry for that!

Cheers









I never had this problem in practice, but theoretically … (But  
maybe I got a

paranoia.)

Cheers







  S1 = [decoder decodeObjectForKey:@S1];
  S2 = [[decoder decodeObjectForKey:@S2] retain];
  S3 = [[decoder decodeObjectForKey:@S3] retain];
  return self;
}

(I'm not posting the encodeWithCoder: method.)

So finally, my question: am I right to retain S2 and S3, and not S1?
___

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/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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/ 
clarkcox3%40gmail.com


This email sent to [EMAIL PROTECTED]





--
Clark S. Cox III
[EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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: CalendarStore sync failure

2008-10-10 Thread Nick Zitzmann



On Oct 10, 2008, at 10:19 AM, Dale Jensen wrote:

This comes up whether I've an alarm attached to the event or not.   
The event does get added, but I would like to clear up what's  
happening here.


Any ideas?  Thanks!



It looks like your local sync state is somehow wedged. Try hitting the  
reset button in iSync's preferences. That ought to un-wedge syncing by  
forcing a re-sync of everything.


Nick Zitzmann
http://www.chronosnet.com/

___

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: inconsistent float behaviour

2008-10-10 Thread Dave Carrigan



On Oct 10, 2008, at 4:04 AM, Steven Hamilton wrote:


Hi folks,
I think I need some help understanding floats.

I have a class that calculates a balance and places it in a table  
column. At the end of this method I NSLog the output like so;


NSLog(@current balance is: %@,balance);

and get

current balance is: 18976.69

in the console. So far so good.

The method plonks the balance into a table and returns it to whence  
it came. The table is sourced by the normal datasource delegate  
methods and the column has a number formatter on it set to Decimal  
#,##0,00## with half even rounding. I placed the last ##'s in there  
to check that the floats weren't producing decimals with more than 2  
places but in my table column I get 18976.6995 which doesn't make  
sense. The float calculation is exactly 2 decimal places, I know  
that for a fact and NSLog proves it. Yet somehow, the table  
datasource appears to produce random decimal digits where i have the  
last ##.


Am I totally misunderstanding something about floats? Or is the  
extra ##'s in the formatter making things up?


There are an infinite number of floating point values between any two  
integer numbers, so it is not possible to represent every single  
possible float value using a fixed-width binary number. You're most  
likely seeing a number that can't be exactly represented.


If you're dealing with currency, you should probably be using integer  
arithmetic, and store all values as pennies or tenths of pennies,  
depending on the precision you need.


--
Dave Carrigan
[EMAIL PROTECTED]
Seattle, WA, USA



PGP.sig
Description: This is a digitally signed message part
___

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: inconsistent float behaviour

2008-10-10 Thread Nick Zitzmann



On Oct 10, 2008, at 5:04 AM, Steven Hamilton wrote:

Am I totally misunderstanding something about floats? Or is the  
extra ##'s in the formatter making things up?



Floating point values of either float or double are not guaranteed to  
be super precise, and should never be used to represent currency  
values. Try using a long long instead, and have the first two digits  
represent a fractional unit of currency.


Nick Zitzmann
http://www.chronosnet.com/

___

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: Strategy for naming support folder

2008-10-10 Thread Quincey Morris

On Oct 10, 2008, at 00:31, Graham Cox wrote:

I do tend to agree that it's not a place users should be visiting
routinely, and the app itself should offer an interface where
necessary to manage its own stuff in there. As with prefs, odds are
that the only time a user will ever go in there is to fix a problem
with a damaged file, so there's no clear advantage to making it
different from the preferences situation that I can see. Why is
anyone poking around in there? (Not a rhetorical question, I'm
interested in knowing what people do visit that folder for).

I can't document this completely, but my understanding is that
Application Support is one folder in Library that users *may* visit
routinely. In particular, a drag-installed application may put files
in Application Support, and if such an application is drag-uninstalled
(i.e. moved to the trash) the user gets to decide whether to keep the
stuff it put in Application Support, or whether to drag that stuff to
the trash too.

From:

http://developer.apple.com/documentation/MacOSX/Conceptual/BPFileSystem/Articles/LibraryDirectory.html#/
/apple_ref/doc/uid/20002282

Application Support
Contains application-specific data and support files such as ... .
By convention, all of these items should be put in a subdirectory
named after the application. For example, third-party resources for
the application MyApp would go in Application Support/MyApp/. Note
that required resources should go inside the application bundle
itself.

And from:

http://developer.apple.com/documentation/MacOSX/Conceptual/BPFileSystem/Articles/WhereToPutFiles.html

Don’t Pollute User Space

... Even if your application provides clip art or sample files that
the user would normally manipulate, you should place those files in
either the local or user’s Library/Application Support directory by
default. The user can move or copy files from this directory as
desired. If you are concerned about the user finding these files,
you should include a way for the user to browse or access them
directly from your application’s user interface.

Whether or not it would be better for users to see bundle identifiers
in Application Support -- and I happen to think it would not -- the
current state of play seems to mandate the application name, not the
bundle identifier.

FWIW

___

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: inconsistent float behaviour

2008-10-10 Thread Gary L. Wade

I've not used it myself, but there is also NSDecimal that may be an 
alternative.  Also, I recall seeing an IBM-released class that I believe had 
been part of ICU that also did decimal arithmetic using 32 or 64 bits.


On Oct 10, 2008, at 5:04 AM, Steven Hamilton wrote:

 Am I totally misunderstanding something about floats? Or is the  
 extra ##'s in the formatter making things up?


Floating point values of either float or double are not guaranteed to  
be super precise, and should never be used to represent currency  
values. Try using a long long instead, and have the first two digits  
represent a fractional unit of currency.

Nick Zitzmann
http://www.chronosnet.com/

___

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: inconsistent float behaviour

2008-10-10 Thread Michael Ash

On Fri, Oct 10, 2008 at 7:04 AM, Steven Hamilton [EMAIL PROTECTED] wrote:
 The float calculation is exactly 2
 decimal places

This is unlikely. There are very few numbers with two decimal places
which can be perfectly represented in floating-point numbers. (Those
would be numbers with fractional values that can be composed from
powers of two, i.e. 0.25, 0.5, and 0.75.)

You'll probably want to read this:

http://docs.sun.com/source/806-3568/ncg_goldberg.html

And then stop using floating point math for anything which you require
to produce an exact result.

For money, the best thing to do is to simply perform calculations in
cents using integers, then divide by 100 for display purposes only.

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: Finder Crashes on File Open

2008-10-10 Thread Brian Miller


Hi,

Here is the plist, thanks in advance for taking a look at it:

?xml version=1.0 encoding=UTF-8?
!DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd 


plist version=1.0
dict
keyCFBundleDevelopmentRegion/key
stringEnglish/string
keyCFBundleDocumentTypes/key
array
dict
keyCFBundleTypeExtensions/key
array
stringpbpshow/string
/array
keyCFBundleTypeIconFile/key
stringfileIcon/string
keyCFBundleTypeMIMETypes/key
array
stringapplication/octet-stream/string
/array
keyCFBundleTypeName/key
stringInstaCue/string
keyCFBundleTypeOSTypes/key
array
string/string
/array
keyCFBundleTypeRole/key
stringEditor/string
keyLSTypeIsPackage/key
false/
keyNSDocumentClass/key
stringMyDocument/string
keyNSPersistentStoreTypeKey/key
stringBinary/string
/dict
/array
keyCFBundleExecutable/key
string${EXECUTABLE_NAME}/string
keyCFBundleIconFile/key
stringICIcon/string
keyCFBundleIdentifier/key
stringcom.DTvideolabs.instaCue/string
keyCFBundleInfoDictionaryVersion/key
string6.0/string
keyCFBundleName/key
string${PRODUCT_NAME}/string
keyCFBundlePackageType/key
stringDTVL/string
keyCFBundleShortVersionString/key
string2.1.5/string
keyCFBundleSignature/key
string/string
keyCFBundleVersion/key
string2/string
keyNSMainNibFile/key
stringMainMenu/string
keyNSPrincipalClass/key
stringICApplication/string
/dict
/plist


Brian



On Oct 10, 2008, at 8:32 AM, Shawn Erickson wrote:


Oops missed the list...

On Thu, Oct 9, 2008 at 10:47 AM, Brian Miller [EMAIL PROTECTED]  
wrote:

Hi All,

I have a Cocoa Core Data Document based application.  When files  
created
with this application are opened via the Finder (or double  
clicked), the
Finder crashes and restarts every time.  Opening files from within  
the

application work fine, using Open With works fine.

The Finder crashes before the application is launched.


What does your Info.plist look like? All I can guess is that your
plist has some entries in it that are causing Launch Services grief.

-Shawn
___

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/bmvdeveloper 
%40cox.net


This email sent to [EMAIL PROTECTED]


___

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: inconsistent float behaviour

2008-10-10 Thread ghe

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nick Zitzmann wrote:
 
 On Oct 10, 2008, at 5:04 AM, Steven Hamilton wrote:
 
 Am I totally misunderstanding something about floats? Or is the extra
 ##'s in the formatter making things up?
 
 
 Floating point values of either float or double are not guaranteed to be
 super precise, and should never be used to represent currency values.
 Try using a long long instead, and have the first two digits represent a
 fractional unit of currency.

Keep in mind that despite the decimal point (US $$), money is an
integer. If you're using a 64 bit int, there's room to shift it over 8
bits or so to give a little roundoff space for division and percents and
the like.

Unless you're working with your losses in the stock market (Oct 2008)...

- --
Glenn English
[EMAIL PROTECTED]

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjvkQ4ACgkQ04yQfZbbTLYj8QCdEHM8nQplWqwsLHn9j8yCcqmT
qvIAn12OoUgbvZURYvP+VOnU3/h2CuV2
=8jm1
-END PGP 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: Strategy for naming support folder

2008-10-10 Thread Uli Kusterer


On 10.10.2008, at 07:15, Graham Cox wrote:

On 10 Oct 2008, at 11:30 am, j o a r wrote:
Most apps use just the name, but I've never liked that and I  
support your idea of using the bundle identifier. Makes a lot of  
sense.


Yep, seemed to make sense to me too, but I don't think I've ever  
seen it, which is why I hesitated.


I think I'll do it this way unless I hear some good arguments against.



 I actually think that's Apple's recommendation. That said, I don't  
like using bundle identifiers for this, as I prefer old-Mac-style  
readable file names. And since all apps so far seem to be using the  
readable names for folders in there, so do I.


Cheers,
-- Uli Kusterer
The Witnesses of TeachText are everywhere...
http://www.zathras.de





___

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: inconsistent float behaviour

2008-10-10 Thread Uli Kusterer


On 10.10.2008, at 13:04, Steven Hamilton wrote:

NSLog(@current balance is: %@,balance);

and get

current balance is: 18976.69

in the console. So far so good.

(...) The float calculation is exactly 2 decimal places, I know that  
for a fact and NSLog proves it.


 You may want to be aware that NSLog gives no guarantees as to the  
output of its formats if you use [EMAIL PROTECTED] All it does is call the - 
description method of the requisite object. -description is only  
intended for debugging, and as such what it returns for a particular  
object may change from release to release, or even from instance to  
instance (e.g. when you log an NSArray, you occasionally get more  
detailed output than when logging a toll-free-bridged CFArrayRef).


Cheers,
-- Uli Kusterer
The Witnesses of TeachText are everywhere...
http://www.zathras.de





___

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: CalendarStore sync failure

2008-10-10 Thread Dale Jensen



On Oct 10, 2008, at 11:52 AM, Nick Zitzmann wrote:



On Oct 10, 2008, at 10:19 AM, Dale Jensen wrote:

This comes up whether I've an alarm attached to the event or not.   
The event does get added, but I would like to clear up what's  
happening here.


Any ideas?  Thanks!



It looks like your local sync state is somehow wedged. Try hitting  
the reset button in iSync's preferences. That ought to un-wedge  
syncing by forcing a re-sync of everything.


Nope, still happens.  Googling for some of the keywords nets a couple  
of hits that also reference possible corruption problems, but  
resetting things hasn't changed the error.



dale

--
Dale Jensen, CEO
Ntractive, LLC
[EMAIL PROTECTED]
http://www.ntractive.com

___

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: Strategy for naming support folder

2008-10-10 Thread Ricky Sharp

 
On Friday, October 10, 2008, at 01:04PM, Uli Kusterer [EMAIL PROTECTED] 
wrote:
On 10.10.2008, at 07:15, Graham Cox wrote:
 On 10 Oct 2008, at 11:30 am, j o a r wrote:
 Most apps use just the name, but I've never liked that and I  
 support your idea of using the bundle identifier. Makes a lot of  
 sense.

 Yep, seemed to make sense to me too, but I don't think I've ever  
 seen it, which is why I hesitated.

 I think I'll do it this way unless I hear some good arguments against.


  I actually think that's Apple's recommendation. That said, I don't  
like using bundle identifiers for this, as I prefer old-Mac-style  
readable file names. And since all apps so far seem to be using the  
readable names for folders in there, so do I.

I also use readable names for all folders/files.

For example, for my main math app, my folder hierarchy is:

Instant Interactive  Math Series  Drills


Such a hierarchy is duplicated in various places as needed (e.g. Documents, 
Preferences, etc.)


Along with being readable, all my customers can easily back up everything from 
my company (since all files ultimate resides in that Instant Interactive 
folder).  Or, they can choose individual nested folders in case they have 
different backup rules for each app (or series of apps).

--
Rick Sharp
Instant Interactive(tm)


___

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]

CATextLayers text alignment?

2008-10-10 Thread Tim Andersson


Hi there.

I'm using a CATextLayer to display some text which the user can change  
the font size of. When the user changes the font size, I still want my  
text to be centered, both vertically and horizontally.
As far as I know you can only set the the CATextLayers alignmentMode  
to kCAAlignmentCenter to get it centered on one of the axis (I never  
know which one is which), but is there any way that it can be centered  
on both axis?


Yours sincerely,
Tim Andersson
___

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]

NSNull and @

2008-10-10 Thread DKJ

I've made an NSDictionary where the values are strings. Is there a  
difference between setting a value as [NSNull null] and setting it as  
@? (I've been using the former.)


dkj
___

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: NSNull and @

2008-10-10 Thread Seth Willits


On Oct 10, 2008, at 3:20 PM, DKJ wrote:

I've made an NSDictionary where the values are strings. Is there a  
difference between setting a value as [NSNull null] and setting it  
as @? (I've been using the former.)


Is there a difference? Definitely. One is an instance of NSString, the  
other is an instance of NSNull. NSNull is not special. It's an object  
just like any other.


Whether you want to use an empty string or an NSNull is up to you. If  
an empty string is a legal value, then you could use NSNull to  
represent there being no value given. (Or just simply don't have  
anything in the dictionary.)



--
Seth Willits




___

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: NSNull and @

2008-10-10 Thread Colin Barrett

On Fri, Oct 10, 2008 at 3:20 PM, DKJ [EMAIL PROTECTED] wrote:
 I've made an NSDictionary where the values are strings. Is there a
 difference between setting a value as [NSNull null] and setting it as @?
 (I've been using the former.)

It's up to you. Unlike other languages, Cocoa dictionaries are not
type homogenous (ObjC in general has a weak type system and its
objects are statically typed). It is up to the caller of objectForKey:
(which returns id) to check the type of the returned object and make
sure it is what you are expecting it to be.

-Colin
___

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: NSNull and @

2008-10-10 Thread Shawn Erickson

On Fri, Oct 10, 2008 at 5:11 PM, Colin Barrett [EMAIL PROTECTED] wrote:

 It is up to the caller of objectForKey:
 (which returns id) to check the type of the returned object and make
 sure it is what you are expecting it to be.

To go further... it isn't important what the type is are run time,
just if the object responds to the messages you want to send it in a
way that is reasonable for the situation.

-Shawn
___

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: NSNull and @


On 11/10/2008, at 9:33 AM, Seth Willits wrote:


On Oct 10, 2008, at 3:20 PM, DKJ wrote:

I've made an NSDictionary where the values are strings. Is there a  
difference between setting a value as [NSNull null] and setting it  
as @? (I've been using the former.)


Is there a difference? Definitely. One is an instance of NSString,  
the other is an instance of NSNull. NSNull is not special. It's an  
object just like any other.


I'm just trying to work out what NSNull really is in the Cocoa  
context. Is it an object in Cocoa? I think (from other environments)  
that it is a type signifying no object. Since NSNull may be a  
valid value of any other type, is it counted as a subtype of every  
other type (hence the ultimate subclass)? I think a good and simple  
(one that doesn't make my brain hurt) definition of NSNull is  
important in order to ensure software correctness.


Passing paths that climb half way into the void

Whether you want to use an empty string or an NSNull is up to you.  
If an empty string is a legal value, then you could use NSNull to  
represent there being no value given. (Or just simply don't have  
anything in the dictionary.)



--
Seth Willits


___

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: NSNull and @

2008-10-10 Thread Seth Willits


On Oct 10, 2008, at 5:40 PM, Ian Joyner wrote:

I'm just trying to work out what NSNull really is in the Cocoa  
context. Is it an object in Cocoa?



As I said, yes. It's truly an object. (A singleton, as well.)



Since NSNull may be a valid value of any other type, is it counted  
as a subtype of every other type (hence the ultimate subclass)? I  
think a good and simple (one that doesn't make my brain hurt)  
definition of NSNull is important in order to ensure software  
correctness.


Woah. Talk about brain hurt. You're thinking about this far too much.

There's no inheritance, there's no nothing. It's an object. It's  
absolutely in no way different than you creating your own IJNull  
class, and sticking an instance of it anywhere. It doesn't behave any  
differently.



As for use, the documentation says it pretty clearly:

The NSNull class defines a singleton object used to represent null  
values in collection objects (which don’t allow nil values).



You can't stick nil into dictionaries and arrays. So either you stick  
an empty string, an NSNumber with 0, etc if those are OK, or you can  
use NSNull.




--
Seth Willits




___

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: NSNull and @

On Fri, Oct 10, 2008 at 8:40 PM, Ian Joyner [EMAIL PROTECTED] wrote:
 I'm just trying to work out what NSNull really is in the Cocoa context. Is
 it an object in Cocoa? I think (from other environments) that it is a type
 signifying no object. Since NSNull may be a valid value of any other
 type, is it counted as a subtype of every other type (hence the ultimate
 subclass)? I think a good and simple (one that doesn't make my brain hurt)
 definition of NSNull is important in order to ensure software correctness.

The type system can, and often must, be willingly ignored, so you
can't rely on it to demonstrate anything about your program's
correctness.

If it's a strong type system you seek, I suggest you look elsewhere.
Like, somewhere other than desktop Macintosh software development, for
which all the popular languages have incredibly weak type systems.

--Kyle Sluder
___

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: inconsistent float behaviour

2008-10-10 Thread Steven Hamilton


Thanks guys,
I'm still unsure why I'm getting 4 decimal places as I know for fact  
that the data is 2 decimal places. However, it seems my approach is  
wrong. I'll convert to int's and NSDecimalNumbers instead and remove  
all floats.


On 11/10/2008, at 4:14 AM, Uli Kusterer wrote:


On 10.10.2008, at 13:04, Steven Hamilton wrote:

NSLog(@current balance is: %@,balance);

and get

current balance is: 18976.69

in the console. So far so good.

(...) The float calculation is exactly 2 decimal places, I know  
that for a fact and NSLog proves it.


You may want to be aware that NSLog gives no guarantees as to the  
output of its formats if you use [EMAIL PROTECTED] All it does is call the - 
description method of the requisite object. -description is only  
intended for debugging, and as such what it returns for a particular  
object may change from release to release, or even from instance to  
instance (e.g. when you log an NSArray, you occasionally get more  
detailed output than when logging a toll-free-bridged CFArrayRef).


Cheers,
-- Uli Kusterer
The Witnesses of TeachText are everywhere...
http://www.zathras.de







___

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: inconsistent float behaviour

On Fri, Oct 10, 2008 at 9:33 PM, Steven Hamilton [EMAIL PROTECTED] wrote:
 I'm still unsure why I'm getting 4 decimal places as I know for fact that
 the data is 2 decimal places. However, it seems my approach is wrong. I'll
 convert to int's and NSDecimalNumbers instead and remove all floats.

The problem is that you don't really know that the data has two
decimal places.  As Mike Ash pointed out, IEEE floating point can
rarely exactly specify a number that only has two decimal places.  So
though you might write a literal 1.23 in your code, the compiler
converts it to a number like 1.2301.  In fact, go ahead
and launch Terminal.app and run `python`.  Type 1.23, and the
interpreter will give you back 1.23.  Then type 1.23 * 10, and
watch as the interpreter gives you 12.301.

This article, 7 Top Tips for Coding with Currency, just made it to
progamming.reddit.com about four days ago.  It gives a very nice
summary of the issues involved when dealing with currency -- not
surprisingly, the first one is work with integer minor units, and
never ever ever use floating point numbers.

--Kyle Sluder
___

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: inconsistent float behaviour

On Fri, Oct 10, 2008 at 9:58 PM, Kyle Sluder
[EMAIL PROTECTED] wrote:
 This article

It would help if I provided the link.
http://www.setfiremedia.com/blog/7-top-tips-for-coding-with-currency
___

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: inconsistent float behaviour

2008-10-10 Thread Clark Cox

On Fri, Oct 10, 2008 at 6:33 PM, Steven Hamilton [EMAIL PROTECTED] wrote:
 Thanks guys,
 I'm still unsure why I'm getting 4 decimal places as I know for fact that
 the data is 2 decimal places.

That is because floating point numbers don't have decimal places;
forget all about decimal places. Please read this:
http://docs.sun.com/source/806-3568/ncg_goldberg.html, it is, as the
title says: what every computer scientist should know about
floating-point arithmetic.

 However, it seems my approach is wrong. I'll
 convert to int's and NSDecimalNumbers instead and remove all floats.

 On 11/10/2008, at 4:14 AM, Uli Kusterer wrote:

 On 10.10.2008, at 13:04, Steven Hamilton wrote:

 NSLog(@current balance is: %@,balance);

 and get

 current balance is: 18976.69

 in the console. So far so good.

 (...) The float calculation is exactly 2 decimal places, I know that for
 a fact and NSLog proves it.

 You may want to be aware that NSLog gives no guarantees as to the output
 of its formats if you use [EMAIL PROTECTED] All it does is call the 
 -description method of
 the requisite object. -description is only intended for debugging, and as
 such what it returns for a particular object may change from release to
 release, or even from instance to instance (e.g. when you log an NSArray,
 you occasionally get more detailed output than when logging a
 toll-free-bridged CFArrayRef).

 Cheers,
 -- Uli Kusterer
 The Witnesses of TeachText are everywhere...
 http://www.zathras.de






 ___

 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/clarkcox3%40gmail.com

 This email sent to [EMAIL PROTECTED]




-- 
Clark S. Cox III
[EMAIL PROTECTED]
___

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: NSNull and @


On 11/10/2008, at 11:58 AM, Seth Willits wrote:


On Oct 10, 2008, at 5:40 PM, Ian Joyner wrote:

I'm just trying to work out what NSNull really is in the Cocoa  
context. Is it an object in Cocoa?



As I said, yes. It's truly an object. (A singleton, as well.)



Since NSNull may be a valid value of any other type, is it  
counted as a subtype of every other type (hence the ultimate  
subclass)? I think a good and simple (one that doesn't make my  
brain hurt) definition of NSNull is important in order to ensure  
software correctness.


Woah. Talk about brain hurt. You're thinking about this far too much.


I don't think you can think about anything too much. If one doesn't  
have a clear understanding of the semantics of programming constructs  
then resultant software full of bugs (I'm sure Confuscious said  
something like this several thousand years ago). Perhaps that's why we  
have become so test dependent – don't think, just test. Well, I'll  
refrain from going further into a philosophical debate at this point.


There's no inheritance, there's no nothing. It's an object. It's  
absolutely in no way different than you creating your own IJNull  
class, and sticking an instance of it anywhere. It doesn't behave  
any differently.


As for use, the documentation says it pretty clearly:

The NSNull class defines a singleton object used to represent null  
values in collection objects (which don’t allow nil values).



You can't stick nil into dictionaries and arrays. So either you  
stick an empty string, an NSNumber with 0, etc if those are OK, or  
you can use NSNull.


So it's really a workaround for this situation. I think therefore  
there are several constructs to represent the same concept of lack of  
presence – nil, Nil, Null, and NSNull.


Sorry, but NULL values need very careful reasoning and handling. (See  
C.J. Date Database Systems 5.6 Nulls (A Digression).) Thanks for  
your insights.


Ian___

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: NSNull and @


On 11/10/2008, at 12:31 PM, Kyle Sluder wrote:


On Fri, Oct 10, 2008 at 8:40 PM, Ian Joyner [EMAIL PROTECTED] wrote:
I'm just trying to work out what NSNull really is in the Cocoa  
context. Is
it an object in Cocoa? I think (from other environments) that it is  
a type
signifying no object. Since NSNull may be a valid value of any  
other
type, is it counted as a subtype of every other type (hence the  
ultimate
subclass)? I think a good and simple (one that doesn't make my  
brain hurt)
definition of NSNull is important in order to ensure software  
correctness.


The type system can, and often must, be willingly ignored, so you
can't rely on it to demonstrate anything about your program's
correctness.


So we must be dependent on testing, which I find compelling like agile  
programming, but ultimately very hit and miss.



If it's a strong type system you seek, I suggest you look elsewhere.


Insofar as strong typing helps software correctness, but as such, not  
necessarily strong typing. I appreciate the flexibility of dynamic  
languages, but one can have this also in strong typing.


Like, somewhere other than desktop Macintosh software development,


Why would I want to do that?


for
which all the popular languages have incredibly weak type systems.


Popular does not necessarily imply good, only democratic.

Ian
___

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: NSNull and @

On Fri, Oct 10, 2008 at 10:33 PM, Ian Joyner [EMAIL PROTECTED] wrote:
 So we must be dependent on testing, which I find compelling like agile
 programming, but ultimately very hit and miss.

Luckily the Developer Tools come with the OCUnit unit testing framework.

 If it's a strong type system you seek, I suggest you look elsewhere.

 Insofar as strong typing helps software correctness, but as such, not
 necessarily strong typing. I appreciate the flexibility of dynamic
 languages, but one can have this also in strong typing.

Perhaps I should use the terms more correctly.  ObjC is late-bound,
and *very* frequently Cooca will go and change the class identity of
the objects you're working with.  A great example is KVO: if you
register as an observer of a MyObject, then KVO will actually
completely replace your MyObject instance with an instance of some
dynamically-generated _KVONotifyingMyObject class, and your code will
be none the wiser.

Essentially, you are giving up a lot of static analysis opportunities
in order to avoid the behavioral restrictions they impose.  In this
case, you have mentioned NSNull in a context that is more familiar to
languages with well-developed type systems such as Haskell.
Objective-C foregoes this formal type system so that things like KVO
can function.  It's a tradeoff, to be sure.

 Like, somewhere other than desktop Macintosh software development,

 Why would I want to do that?

I'm not advocating that you do!  It was a rhetorical device.

 for
 which all the popular languages have incredibly weak type systems.

 Popular does not necessarily imply good, only democratic.

I'm just noting that no reasonably well-supported development
environment on the Mac will provide you features such as a type system
in which a null type exists that is a subtype of all other types.
Pattern-matching languages, like Scala for example, are great for this
sort of thing, but you won't find one that is suitable for developing
desktop Mac applications.  Perhaps that will change in the future.

--Kyle Sluder
___

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]

NSTableView and drag and drop

2008-10-10 Thread Chris Idou

I want to be able to drag strings out of a table into another field, but I must 
be missing something major because drags never get initiated. I've added the 
delegate, registered drag types and added delegate methods, but clicking and 
dragging within the table simply selects rows in the table, dragging is never 
initiated.

Is there some option I'm missing to turn on drag and drop?





  
___

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: NSPersistentDocument No Support Save To (Save As?)

2008-10-10 Thread Jerry Krinock



On 2008 Oct, 09, at 2:27, chaitanya pandit wrote:


On 09-Oct-08, at 2:52 AM, Mike Abdullah wrote:

But why? NSPersistentDocument provides this automatically for you.  
It's only Save To that's not supported. Or is there a good reason  
to provide a custom implementation that I'm missing?


You're right NSPersistentDocument provides that already, actually i  
did the app. a while back and i found that my app had some weird  
document structure so i had to do it myself, you ain't missing  
anything


Well, maybe it's not just me then.  I have submitted Document  
Feedback to Apple.


___

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: NSNull and @


On 11/10/2008, at 2:18 PM, Kyle Sluder wrote:


On Fri, Oct 10, 2008 at 10:33 PM, Ian Joyner [EMAIL PROTECTED] wrote:
So we must be dependent on testing, which I find compelling like  
agile

programming, but ultimately very hit and miss.


Luckily the Developer Tools come with the OCUnit unit testing  
framework.



If it's a strong type system you seek, I suggest you look elsewhere.


Insofar as strong typing helps software correctness, but as such, not
necessarily strong typing. I appreciate the flexibility of dynamic
languages, but one can have this also in strong typing.


Perhaps I should use the terms more correctly.  ObjC is late-bound,
and *very* frequently Cooca will go and change the class identity of
the objects you're working with.  A great example is KVO: if you
register as an observer of a MyObject, then KVO will actually
completely replace your MyObject instance with an instance of some
dynamically-generated _KVONotifyingMyObject class, and your code will
be none the wiser.

Essentially, you are giving up a lot of static analysis opportunities
in order to avoid the behavioral restrictions they impose.  In this
case, you have mentioned NSNull in a context that is more familiar to
languages with well-developed type systems such as Haskell.


Hmm, I have both the Smalltalk and Haskell books sitting on my desk  
for restudy. I think you have given me the impetus to study them  
together from this angle. Thanks.


Objective-C foregoes this formal type system so that things like KVO
can function.  It's a tradeoff, to be sure.


I'll have to think more about this. I'm not sure that KVO can't be  
done in a type-safe manner.



Like, somewhere other than desktop Macintosh software development,


Why would I want to do that?


I'm not advocating that you do!  It was a rhetorical device.


Glad to hear that. I won't be abandoning Mac after 20 years anytime  
soon for that hopeless case Windows.




for
which all the popular languages have incredibly weak type systems.


Popular does not necessarily imply good, only democratic.


I'm just noting that no reasonably well-supported development
environment on the Mac will provide you features such as a type system
in which a null type exists that is a subtype of all other types.
Pattern-matching languages, like Scala for example, are great for this
sort of thing, but you won't find one that is suitable for developing
desktop Mac applications.  Perhaps that will change in the future.


I don't think the two are mutually exclusive. In a type-safe  
environment, type errors are caught (tested) by the compiler (so you  
don't need to develop tests for these cases). There are known  
situations where you don't want this, but to defer the exception to  
run time. A language can easily be defined to allow for this. It came  
up a while ago and I wrote an article on it:


http://web.me.com/ianjoyner/Ian_Joyner/Typing.html

I also wouldn't discount it happening in the future, after all Obj-C  
2.0 gave us garbage collection.


Ian
___

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: Strategy for naming support folder



On 11 Oct 2008, at 5:30 am, Ricky Sharp wrote:

Along with being readable, all my customers can easily back up  
everything from my company (since all files ultimate resides in that  
Instant Interactive folder).  Or, they can choose individual  
nested folders in case they have different backup rules for each app  
(or series of apps).



While this is tidy, and seems logical to you, are your users as keenly  
aware of your company name as you are? I put it to you that they are  
not. They may be familiar with the app's name, but the company that  
wrote it? Much less likely unless you're overdoing its presence in the  
app. This is probably not a major issue, but if I wanted to find out  
where my math drills were stored, I might not immediately realise that  
the Instant Interactive folder was the place to look.


For the product I'm working on now the company name is likely to be  
highly minimised, being only part of the small print in the copyright  
notice. This is a deliberate choice - it's the product that matters,  
not who we are.


Still, the consensus appears to be to use the app's name rather than  
the bundle identifier. So I'll probably go with that just for the sake  
of fitting in.



cheers, 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: How do I debug this? [SOLVED]

Thanks to everyone who responded - I found the problem. Though I had  
breakpoints set on [NSException raise], by the time the breakpoint was  
hit there was nothing on the stack trace from my code. Breaking on  
objc_exception_throw didn't work either (that's called even later).  
However by temporarily adding try/catch around the code that I  
suspected contained the fault allowed me to stop in the catch block  
which had a stack trace that revealed the problem.


Curiously, it turned out one of my earlier 'hunches' was right on the  
money.


I'm a bit mystified why the stack trace wasn't showing up in the first  
case, it otherwise works fine AFAICS. Anyhoo, this one's fixed.


thanks, Graham


On 11 Oct 2008, at 12:36 am, Ashley Clark wrote:


Stack trace:

#0  0x92badc66 in -[NSException raise]
#1  0x901c3283 in -[NSCarbonMenuImpl
performActionWithHighlightingForItemAtIndex:]
#2  0x901a0122 in AppKitMenuEventHandler
#3  0x90c79303 in DispatchEventToHandlers
#4  0x90c7873d in SendEventToEventTargetInternal
#5  0x90c95092 in SendEventToEventTarget
#6  0x90cc931d in SendHICommandEvent
#7  0x90cefb6f in SendMenuCommandWithContextAndModifiers
#8  0x90cefb2c in SendMenuItemSelectedEvent
#9  0x90cefa3e in FinishMenuSelection
#10 0x90ccc5cc in MenuSelectCore
#11 0x90ccbfb7 in _HandleMenuSelection2
#12 0x90ccbe2b in _HandleMenuSelection
#13 0x900dcad3 in _NSHandleCarbonMenuEvent
#14 0x900438dc in _DPSNextEvent
#15 0x90042ca0 in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
#16 0x9003bcdb in -[NSApplication run]
#17 0x90008f14 in NSApplicationMain
#18 0x4e73 in main at main.m:13

Leading to the message:

2008-10-10 15:57:59.552 Ortelius[43213:813] *** -[NSCFArray
objectAtIndex:]: index (0) beyond bounds (0)

How can I find out what array is being overrun here? There's no code
of my own in the stack trace at this point, which appears to be the
tail end of a menu selection (which makes sense, as it occurs during
loading a file in response to the Open menu command). So far I've
just been trying to guess what the problem might be by following
'hunches' but so far drawn a blank.



Have you tried setting a breakpoint on objc_exception_throw? That  
should
show you the moment the exception is being created and should let  
you know

who's calling the objectAtIndex:0 method.

Just doing a simple test here I get a stack trace that looks like  
this:


#0  0x96f9ee17 in objc_exception_throw
#1  0x968a1f2b in +[NSException raise:format:arguments:]
#2  0x968a1f6a in +[NSException raise:format:]
#3  0x95587bbf in _NSArrayRaiseBoundException
#4  0x95505548 in -[NSCFArray objectAtIndex:]
#5  0x0001fdb6 in -[JTApplicationDelegate showInventoryInformation:] at
JTApplicationDelegate.m:35
#6  0x95907b03 in -[NSApplication sendAction:to:from:]
#7  0x959b6540 in -[NSMenu performActionForItemAtIndex:]
#8  0x959b6245 in -[NSCarbonMenuImpl
performActionWithHighlightingForItemAtIndex:]
...snip...
#25 0x2220 in main at main.m:13


--
Ashley Clark



___

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]

Opening a document from stationery