from:"Ben"

You can subclass the text view and returned an origin point from -  
(NSPoint)textContainerOrigin.  This will give you origin.x 
+inset.width on the left and just inset.width on the right when used  
in conjunction with setTextContainerInset.


-Ben
--
Ben Lachman
Acacia Tree Software

http://acaciatreesoftware.com

[EMAIL PROTECTED]
740.590.0009



On Apr 18, 2008, at 11:44 AM, Ferhat Ayaz wrote:

Hi,

how would I go about setting NSTextView up so its insets are dx1  
from the left and dx2  from the right side?
I guess setTextContainerInset: will set for both left and right the  
same value (dx1 = dx2).



___

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: NSTableView -editColumn:row:withEvent:select: question

Well, you should be able to just override the drawing code, since  
thats really your problem.  Going directly against the docs, while it  
may work fine now, is playing with fire in my opinion.  To get the  
drawing you want, you can just implement  
tableView:willDisplayCell:forTableColumn:row: in the delegate and  
manually switch selection highlighting on or off depending on whether  
the table column passed to you is the selected table column.  You'll  
probably have to have a couple more cases if you're really trying to  
get close to the standard spreadsheet functionality that lets you  
select the full row/column by clicking on the header.  But this  
should get you started, hopefully.


-Ben
--
Ben Lachman
Acacia Tree Software

http://acaciatreesoftware.com

[EMAIL PROTECTED]
740.590.0009



On Apr 18, 2008, at 1:55 PM, John Stiles wrote:

The docs for -editColumn:row:withEvent:select:  ominously claim:
   The row at rowIndex must be selected prior to calling  
editColumn:row:withEvent:select:, or an exception will be raised.


I'm implementing a subclass of NSTableView which behaves a little  
more like an Excel spreadsheet—it maintains a phony selection by  
overloading -mouseDown/Dragged/Up: and coloring cell backgrounds as  
appropriate. It works great. But it means that the table view,  
internally, never actually considers a row to be selected. My  
subclass handles that entirely on its own and leaves the table view  
out of it.


Now I'm getting around to implementing the part where the user can  
edit table cells in place, and since I wanted to follow the rules  
in the docs, I started by implementing it like this:


   [myTableView selectRow:inRow byExtendingSelection:NO];
   [myTableView editColumn:inCol row:inRow withEvent:myEvent  
select:NO];


It worked fine but, of course, the entire row turned blue, ruining  
the spreadsheet illusion.
So just to see what would happen, I tried removing the call to - 
selectRow:: and, lo and behold! No exception. It worked great.  
Looks just like how I want it to look.


Am I getting lucky here? Are the docs just wrong? I don't want to  
do something overtly dangerous, but in practice it does exactly  
what I want... are there any gotchas?


I'm on Leopard FWIW, and don't need to target older OSes.
___

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/blachman%40mac.com

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: Hand style movement inside a NSScrollView


On Apr 18, 2008, at 9:14 PM, Jens Alfke wrote:



On 18 Apr '08, at 12:49 PM, Steve Sheets wrote:

However, I also want to implement a Hand style tool. One that  
allows the user to simple click inside the Scroll View and draw  
the graphics around.


I think you just need to have your view's mouseDragged: handler  
method call -scrollPoint: on self. The only tricky bit is figuring  
out what point (in your view's coords) should become the origin of  
its visible bounds.




I tend to like scrollRect:by: for this sort of thing since it takes a  
offset to a rect.

--
Ben Lachman
Acacia Tree Software

http://acaciatreesoftware.com

[EMAIL PROTECTED]
740.590.0009
___

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: Hand style movement inside a NSScrollView


On Apr 19, 2008, at 12:41 AM, Jens Alfke wrote:



On 18 Apr '08, at 8:59 PM, Ben Lachman wrote:

I tend to like scrollRect:by: for this sort of thing since it  
takes a offset to a rect.


But that method just blits pixels around on the screen; it doesn't  
actually change the coordinate system of the view. The scroll view  
will do the blitting for you automatically when you change its  
coordinates via -scrollPoint:.




Looks like I misread Steve's question.  Jens is right of course.  In  
light of rereading the OP correctly though, I think using


[view scrollRectToVisible:NSOffsetRect([view visibleRect], offsetX,  
offsetY)];


might work and would make more sense (at least to me) when going back  
to the code in a 6 months.


-Ben
--
Ben Lachman
Acacia Tree Software

http://acaciatreesoftware.com

[EMAIL PROTECTED]
740.590.0009

___

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: Chained Migration of Leopard CoreData stores

2008-04-16 Thread Ben Trumbull


Hi,

let's say I have four versions of my data model:

DataModel1.xcdatamodel
DataModel2.xcdatamodel
DataModel3.xcdatamodel
DataModel4.xcdatamodel (this is the current one)

and three model mapping files which always map from version n to 
version n+1:


Mapping1to2.xcmappingmodel
Mapping2to3.xcmappingmodel
Mapping3to4.xcmappingmodel


Now I load a version 1 data file:

NSDictionary *options = [NSDictionary dictionaryWithObject:[NSNumber 
numberWithBool:YES] 
forKey:NSMigratePersistentStoresAutomaticallyOption];

NSError *error = nil;
if (![persistentStoreCoordinator 
addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:url 
options:options error:error])

{
  ...
}

should the data file automatically be migrated to the current version 
4 or do I need a single direct mapping like this:


Mapping1to4.xcmappingmodel


If you want Core Data to do everything, you'll need 1 mapping model, 
since we don't assume that iterative upgrades will necessarily work.


If you're confident that composing your N+1 mapping models together 
makes sense for your app, you can run N+1 migrations in a row to 
avoid needing an umbrella mapping model.

--

-Ben
___

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

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

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

This email sent to [EMAIL PROTECTED]

re: Core Data for managing subtree?

2008-04-13 Thread Ben Trumbull


At 6:13 PM -0700 4/8/08, [EMAIL PROTECTED] wrote:

However, I would like to use Core Data to manage these items. I figure
I could have my add and remove methods insert and remove objects from
the managed object context as well as the KVO-compliant mutable array,
but when I undo such an action, the change will only be reflected in
the managed object context. I could create an extra entity to act as a
collection for those items and have the add and remove methods
manipulate that object, but I don't see how this collection could then
be KVO-related to its parent node as per mutableArrayValueForKey:.


Hamish,

The easiest way to get array and tree controllers to work with Core 
Data results is to put them into Entity mode.  If you want to bind to 
a to-many relationship keypath, you can bind to their 'contentSet'. 
Core Data to-many relationships respond to mutableSetValueForKey:


If you only want only some of the tree using Core Data objects, you 
could try having an array controller manage the extra entity, and 
wire its content into your tree controller.  You don't need a to-many 
relationship for that.  The array controller in entity mode directly 
observes the NSManagedObjectContext with which it is associated.


If you want to customize things even further, you can observe the 
NSManagedObjectContext's 
NSManagedObjectContextObjectsDidChangeNotification yourself, and 
update your custom controllers based on the contents of that 
NSNotification.  The array controller in entity mode is basically 
doing this, plus observing some of the managed object properties 
directly with KVO.


--

-Ben
___

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: Why should we set ivars to nil in dealloc?

2008-04-13 Thread Ben Trumbull


Seriously, we're arguing about this ?


If you want a total hack, just assign (id) 0x1 to any variable that


... please step away from the tequila.

I have a radical suggestion:

Test your software.

Like crazy talk!!

The detection of this class of bugs is extraordinarily easy to 
automate, so my sympathy is lower than its usual nonexistence.


Here are the environment variables to set:

export NSZombieEnabled=YES
export CFZombieLevel=9
export MallocScribble=1
export MallocPreScribble=1
export MallocGuardEdges=1

You don't have to remember to run with these flags.  Because, of 
course, you have unit tests to at least provide some basic code 
coverage.


If you don't, you really need to stop and fix that first.  I can't 
say I enjoy it, but begrudgingly, the results and ROI from unit tests 
have been extremely impressive.  Compared to the previous project I 
worked on (no unit tests), we've been able to make much more 
aggressive changes, and innovate faster, on my current project 
entirely due to the unit testing infrastructure.


And then, you find an old mac mini or imac, and set up a cronjob to 
run your unit tests every night.  Once you have nightly unit tests 
set up, running them again with different env flags is effortless.


If you're wondering wtf CFZombieLevel 9 does, check out Most Awesome 
TechNote Ever:

http://developer.apple.com/technotes/tn2004/tn2124.html

Also, for more paranoia (at 100x slower), you can use (do NOT mix 
with the above):


export DYLD_INSERT_LIBRARIES=/usr/lib/libgmalloc.dylib
export MALLOC_FILL_SPACE=1

Since those two modes behave differently, we run both nightly.

And while we're on this subject, there's another class of bugs that 
nightly testing can really help with: leaks.


There are two easy leak tools to use via scripts.  'leaks' and 
'heap'.  Leaks is a good first pass, which rarely has false 
positives, but very often has false negatives.  Nevertheless, if your 
code can't pass through leaks, you have a pretty big problem.  So 
'heap' fills in the gap to catch the leaks that 'leaks' missed.


To use 'heap' to catch leaks, you'll want to create a black list. 
For example, in Core Data, after each unit test, we grep through the 
heap result to see if there are any NSManaged*, NSEntity*, etc etc. 
We skip over stuff that's hard to sort through, like NSString, but we 
can at least ensure that none of our classes are still present in the 
heap.  That's a pretty thorough leak detection.


This is a bit harder than zombies, because you'll need to white list 
known problems (in other people's code), and for the heap tool create 
a custom black list.  But this is absolutely worth the effort.


Running unit tests through debugging tools (zombies, leaks, etc) 
nightly has been the single highest return on effort debugging 
decisions I've ever seen.


Ever.  Seen.

The second highest was actually writing the unit tests in the first 
place, a necessary prerequisite, but more effort.


Just imagine what you could do mixing this stuff with dtrace ...
--

-Ben
___

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: struct problem

2008-04-12 Thread Ben Lachman


On Apr 12, 2008, at 8:03 AM, Dean Ritchie wrote:


On Apr 12, 2008, at 1:37 AM, Hamish Allan wrote:

On Sat, Apr 12, 2008 at 2:58 AM, Dean Ritchie  
[EMAIL PROTECTED] wrote:



   columnCount = [[LASize cellAtIndex:0] intValue];
   rowCount = [[LASize cellAtIndex:1] intValue];



When I stop right after initializing the NSRect local variable, the
debugger reports miniscule values for the portions of the  
rectangle, like it

got overlaid with integers instead of float values.


Where are columnCount and rowCount declared, and as what types?


They are class variables, type int.


In general the naming convention used in Objective-C is that class  
names start with capitals and variable names start with lower-case  
characters (both use bumpy case which I think you know).  For  
instance NSWindow (class) and aWindow (variable).  However in your  
code you have LASize, which looks a whole lot like NSSize (which  
happens to be a struct).  However you're assigning sender to it which  
is of type id.  This introduces some confusion, since you assumedly  
assign an object variable to something that looks very much like a  
struct type.  This may not be a bug (we don't know what type sender  
or LASize are so it's hard to say), but it leaves the code nearly  
unreadable for the casual observer.  If you want someone to help you  
out, try to post more clear code.  In a more general sense, it's good  
to write code that follows the general naming conventions anyway  
since if you ever have to share your code or go just back and read it  
in a year you'll have less work understanding it.


-Ben

--
Ben Lachman
Acacia Tree Software

http://acaciatreesoftware.com

[EMAIL PROTECTED]
740.590.0009

___

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: Highlight color of a NSTableView row

2008-04-12 Thread Ben Lachman

Sorry, perhaps I should have been a bit more specific.  That  
implementation both overrides highlightColorWithFrame: and  
drawWithFrame:.  As you noticed, the draw with draw bit just just  
draws the text white if the cell is selected.  This is nice for dark  
selection highlight colors and most of Apple's iApps that contain  
table views do it.  To remove that behavior just remove:



NSColor *oldColor = [self textColor];
[self setTextColor:[NSColor alternateSelectedControlTextColor]];
[super drawWithFrame:cellFrame inView:controlView];
[self setTextColor:oldColor];


Which saves the original color, set the color of the text to white,  
draws it and then restores the original color.  Calling super's draw  
method just draws the cell as it would normally given the current  
settings (color, title, etc.).


HTH,

-Ben
--
Ben Lachman
Acacia Tree Software

http://acaciatreesoftware.com

[EMAIL PROTECTED]
740.590.0009



On Apr 12, 2008, at 1:23 PM, Eric Gorr wrote:


On Apr 11, 2008, at 12:21 AM, Ben Lachman wrote:

I do something like this:

@implementation HilightingTextFieldCell

- (void)drawWithFrame:(NSRect)cellFrame inView:(NSView *) 
controlView {	

if( [self isHighlighted] ) {
NSColor *oldColor = [self textColor];
[self setTextColor:[NSColor alternateSelectedControlTextColor]];
[super drawWithFrame:cellFrame inView:controlView];
[self setTextColor:oldColor];
} else {
[super drawWithFrame:cellFrame inView:controlView]; 
}
}

- (NSColor *)highlightColorWithFrame:(NSRect)cellFrame inView: 
(NSView *)controlView {

return nil;
}

@end



So, based on your code, I have written this...

@implementation CustomHighlightTextFieldCell

- (void)drawWithFrame:(NSRect)cellFrame inView:(NSView *)controlView
{   
	NSColor	*evenColor = [NSColor colorWithCalibratedRed:.9 green:0  
blue:0 alpha:1.0];


if ( [self isHighlighted] ) {
[evenColor set];
NSRectFill( cellFrame );

NSColor *oldColor = [self textColor];
[self setTextColor:[NSColor blackColor]];
[super drawWithFrame:cellFrame inView:controlView];
[self setTextColor:oldColor];
}
else {
[super drawWithFrame:cellFrame inView:controlView]; 
}
}



- (NSColor *)highlightColorWithFrame:(NSRect)cellFrame inView: 
(NSView *)controlView

{
return nil;
}

@end


I just want to draw the entire cell with a background color with  
black text.


For a selected row, what I get is a cell drawn with the background  
color, but white text. I cannot figure out how to get the text  
drawn with a black color.


Will I need to replace:

  [super drawWithFrame:cellFrame inView:controlView];

with my own code to draw the text?



At this point, actually seeing my specific case might be helpful...

I have placed my project at:

http://ericgorr.net/acc.zip

The application is a (not entirely complete) calculator for the  
board game Advanced Civilization ( http://www.boardgamegeek.com/ 
game/177 ). What it does is keep track of what civ. cards you have  
purchased throughout the game and keep track of the current cost of  
the cards which you can still purchase. Each row corresponds to one  
of the civ. cards.


What I have written, which only uses highlightSelectionInClipRect  
to control the highlighting, has nearly all of the highlighting I  
want.


1. Row, in groups of three, have either a light blue or white  
background, if the card has not been purchased (rantI _hate_ the  
look of the alternating light blue  white...groups of three is  
_vastly_ superior/rant)


2. If a card has been purchased, it's background is yellow.

3. For #1  #2, the text remains black - my guess as to why this is  
the case is that the process of highlighting a selected row changes  
the text to white and if a row is not selected, it get the black  
text with either the light blue, white or yellow background.


4. When I select a row, it's get the highlight color specified by  
the system preference - the default blue highlight color on my  
machine.


5. There is no space between the columns

6. If two cards have been purchased and are in adjacent rows, there  
is no space between the rows, which have been colored yellow.


The only thing I would like to change about how this is working is  
when I select a row of a card which has been purchased, I would  
like to use a darker yellow color.


just a usage note...to be able to purchase a card, first enter  
a number (like 200) into the 'Trade Cards' field, this will cause  
the purchase button to be enabled. Second, select a row, which  
isn't grayed out. Third, press the purchase button.










___

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

Re: Convert NSArray to NSString

2008-04-12 Thread Ben Lachman

I assume you mean selectedRanges, which returns an NSArray of  
ranges.  This array contains NSValue objects that represent ranges of  
selected text, not actually the text that is selected.  To get the  
text that is selected you have to do a bit more work.  First you need  
to the get string of text from the textview.  You can either do this  
using [aTextView string] or extract a string from the textStorage  
object that Michael mentioned. Then, for each NSValue in the array  
you must retrieve an NSRange using rangeValue, and then call  
substringWithRange: on the string you got in the first part.  You can  
do whatever you want with this string--append it to a mutable string  
or just store it--just make sure you retain it if you plan on keeping  
it around since it is an autoreleased object that is returned by  
substringWithRange (ignore this is if you're using GC).


If you just want the full text you can just call [aTextView string].   
selectedRange just returns a single range and so you would only have  
to do the operation described above once, but may not get all the  
text selected if the textview supports multiple selections.  Make  
sure you also check that ranges returns by selectedRange(s) doesn't  
contain the NSNotFound marker as well.


-Ben
--
Ben Lachman
Acacia Tree Software

http://acaciatreesoftware.com

[EMAIL PROTECTED]
740.590.0009


On Apr 12, 2008, at 8:49 PM, Michael Vannorsdel wrote:
The textStorage of the NSTextView is actually an  
NSMutableAttributedString subclass so you can treat it as such and  
get the text and attributes from it.



On Apr 12, 2008, at 6:48 PM, Lincoln Green wrote:

 I am trying to store the selected text in an NSTextView in an  
NSString/NSMutableString. I have found the selectedRange method,  
but can't figure out how to turn the NSArray into an NSString. Any  
help would be greatly appreciated. Thanks!



___

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: Tips to deploy applications to multiple Mac OS X versions

2008-04-10 Thread Ben Lachman



On Apr 10, 2008, at 6:19 PM, Chris Suter wrote:
One caveat, though, is that you should probably have a runtime  
check for the minimum OS version you expect so that you don't end  
up with a crash if someone tries to use your nifty Leopard  
features on Tiger. Adding something to main() would probably be  
easiest, either checking against NSAppKitVersionNumber or calling  
Gestalt() to get the OS version.


There's something you can put in the Info.plist that does this for  
free. I forget exactly what it is but I'm sure it's easily found.


LSMinimumSystemVersion is the key.

--
Ben Lachman
Acacia Tree Software

http://acaciatreesoftware.com

[EMAIL PROTECTED]
740.590.0009

___

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: Highlight color of a NSTableView row

2008-04-10 Thread Ben Lachman


I do something like this:

@implementation HilightingTextFieldCell

- (void)drawWithFrame:(NSRect)cellFrame inView:(NSView *)controlView {  
if( [self isHighlighted] ) {
NSColor *oldColor = [self textColor];
[self setTextColor:[NSColor alternateSelectedControlTextColor]];
[super drawWithFrame:cellFrame inView:controlView];
[self setTextColor:oldColor];
} else {
[super drawWithFrame:cellFrame inView:controlView]; 
}
}

- (NSColor *)highlightColorWithFrame:(NSRect)cellFrame inView:(NSView  
*)controlView {

return nil;
}

@end

HTH,
-Ben

--
Ben Lachman
Acacia Tree Software

http://acaciatreesoftware.com

[EMAIL PROTECTED]
740.590.0009



On Apr 10, 2008, at 8:47 PM, Eric Gorr wrote:


On Apr 10, 2008, at 8:30 PM, Corbin Dunn wrote:



Playing with this a bit more, it appears that I need to also do:

- (id)_highlightColorForCell:(NSCell *)cell
{
// we need to override this to return nil
	// or we'll see the default selection rectangle when the app is  
running

// in any OS before leopard

	// you can also return a color if you simply want to change the  
table's default selection color

  return nil;
}

Or it will ignore my highlight drawing entirely. It appears this  
is an undocumented API or, at least, I cannot locate it in the  
documentation.


If a method starts with an underscore, don't even bother looking  
it up in the documentation :) -- not only is it undocumented, but  
it is unsupported and might change in the future.


The proper thing to do:

1. Subclass NSCell, NSTextFieldCell, or whatever other cell you want.
2. Override:

- (NSColor *)highlightColorWithFrame:(NSRect)cellFrame inView: 
(NSView *)controlView


and return nil.


How would I go about subclassing NSTextFieldCell  NSImageCell and  
then using these cell with my NSTableView?


___

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: Highlight color of a NSTableView row

2008-04-09 Thread Ben Lachman


Look at:

http://katidev.com/blog/2008/02/22/styling-an-nstableview-dttah/

but make sure you read the comments.  John Randolph's comments are  
worth considering.


-Ben

--
Ben Lachman
Acacia Tree Software

http://acaciatreesoftware.com

[EMAIL PROTECTED]
740.590.0009



On Apr 10, 2008, at 12:27 AM, Eric Gorr wrote:
I've got a NSTableView and when I select a row, it is highlighted  
with the color specified in the Appearance System Preference panel.


Is there a way to take control over what color gets used to  
highlight a row when selected?


I need to be able to set the highlight color used based on what row  
in the table is selected.

___

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: Problems with Split Views?

2008-04-07 Thread Ben Einstein

For the most part, anything you want to do with NSSplitView you can do  
with RBSplitView (or others) and vice versa. Where RBSplitView really  
excels is its ease of implementation. Even though NSSplitView in 10.5  
is significantly better, I still find that RBSlitView has the upper  
hand in terms of time-to-deployment. If you need specifics, just  
compare the documentation of RBSplitView and NSSplitView.


I continue to use Rainer's implementation every time I need a split  
view.


Hope that helps,
Ben

On Apr 6, 2008, at 10:21 PM, Peter Zegelin wrote:

I am quite new to Cocoa and have been experimenting with split views  
in Interface Builder. It's basically 3 vertical splits with each end  
view also split in half horizontally. It seems to do more or less  
what I want. However looking around for example projects I get the  
impression that the split views are somehow buggy and I'm better off  
using a third party split view such as RBSplitView. Can someone  
explain what sort of problems - if any - I'm likely to encounter  
using the regular split view?


What I need is to have 3 vertical splits with each end view also  
split (horizontally). These end views should not resize as the  
window is resized - just the center view. I know in IB you don't  
seem to be able to prevent a split from resizing when its parent is  
resized (or am I wrong here?) but I presume that wouldn't be a  
problem with some code.


Thanks!

Peter
___

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/beinstein%40comcast.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: Custom Buttons - Tutorial/Examples...

2008-04-05 Thread Ben Lachman

This isn't a subject that I've ever seen addressed really thoroughly  
in a tutorial type walk though, its more a journey of gleaning all  
the info you need to create new buttons and controls.  Personally I'd  
call custom control creation the dark art of Cocoa ;-).


For your case though I think looking at setShowsStatesBY: and  
setHighlightsBy: should suffice to solve your problem.  Also make  
sure you look at all the constants that are valid, not just the ones  
the developer docs talk about (NSNoCellMask and siblings).


-Ben
--
Ben Lachman
Acacia Tree Software

http://acaciatreesoftware.com

[EMAIL PROTECTED]
740.590.0009



On Apr 5, 2008, at 6:08 PM, John Joyce wrote:
Does anybody know a tutorial or example on creating custom buttons  
in Cocoa?
I can certainly set an image in IB or programmatically, but how can  
I determine the actual hitmask? Or even set the mouseOver type of  
event for something like a rollover ?
I know I'm talking about stepping on Apple's HIG, but it is  
something I'd like to know how to do without delving into CG or CA  
right now.
I've been toying with it a bit today, and I can certainly set the  
images, but on mouse down, the background changes to the image with  
a darkened state inside of a white rectangle... surely I'm missing  
something stupidly obvious...?

Any tips or links are greatly appreciated!

Cheers,
JJ
___

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/blachman%40mac.com

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]

Bindings on Contextual Menu Items when to unbind:

2008-04-03 Thread Ben Lachman

I have a few contextual menus that have items that are generated  
dynamically and are bound in code to my model.  I'm not sure if/when  
I should unbind them however.  Is there a good place to do this?  Do  
I even need to?


Thanks,
-Ben
--
Ben Lachman
Acacia Tree Software

http://acaciatreesoftware.com

[EMAIL PROTECTED]
740.590.0009



___

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: Propagate changes/insertions in main context

2008-04-03 Thread Ben Lachman

There was quite an extensive conversation about this a couple days  
ago.  Try to check the archives before posting...


http://www.cocoabuilder.com/archive/message/cocoa/2008/3/30/202687  
and following


-Ben
--
Ben Lachman
Acacia Tree Software

http://acaciatreesoftware.com

[EMAIL PROTECTED]
740.590.0009



On Apr 3, 2008, at 8:34 AM, malcom malcom wrote:

Dear List,
I'm working with CoreData. I need to insert lots of objects and  
make relationship with these and I've decided to perform this  
operation deteaching a new thread that pool an NSArray where data  
is placed.
This thread make the object and insert it in a second managed  
object context, perform linking operations and save the context.
What's the right way to work with multithread and more than an  
context?
Need I to perform insertion in a second context, then save the  
context itself (the save operation need to be perfomed inside  
thread or in main thread?) and make a  
refreshObject:mergeChanges:YES with the main thread?


Cheers,
Dex Morgan

___

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/blachman%40mac.com

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: test if another app has hung

2008-04-01 Thread Ben Dougall



On 1 Apr, 2008, at 11:49 am, Ron Fleckner wrote:



On 01/04/2008, at 9:28 PM, Ben Dougall wrote:

Hello,

What's the best way to test if another app has likely hung or not? 
Programmatically of course. I want to be able to kill an often 
hanging app and restart it -- when it's hung that is. (10.3.9+)


Thanks, Ben.



Hi Ben,

This question was exhaustively examined in a thread a few weeks ago.  
Start here: 
http://www.cocoabuilder.com/archive/message/cocoa/2007/10/20/191068


HTH,
Ron


Excellent, thanks for the pointer.
Ben.

___

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: NSNoCellMask differences in Leopard vs. Tiger

2008-03-31 Thread Ben Lachman

So it ends up that while NSNoCellMask works on Tiger it really isn't  
the way to do what I was wanting.  NSPushInCellMask does the same  
thing (darken the un-bezeled icon), makes more sense, and works on  
both Tiger and Leopard.  The problem is that the documentation  
doesn't mention NSPushInCellMask unless you look at the state masks  
leading me to believe that it wasn't a supported value for  
setHighlightsBy:.  Anyway, hope this helps someone at some point.


-Ben
--
Ben Lachman
Acacia Tree Software

http://acaciatreesoftware.com

[EMAIL PROTECTED]
740.590.0009

On Mar 20, 2008, at 5:50 AM, Ben Lachman wrote:
On Tiger one could set up borderless, momentary light square  
button with an icon and call setHighLightsBy: with NSNoCellMask  
and you'd get a nice darkening on the non-transparent parts when  
the user pressed the button.  However these same buttons on Leopard  
don't change at all during a user's press.  Is there a way to get a  
similar effect on Leopard without using an alternate image (some of  
my buttons already have alternate images)?



___

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: Threads and Core Data, bindings results in view corruption

2008-03-31 Thread Ben Lachman


On Mar 31, 2008, at 2:47 PM, Jeff LaMarche wrote:


On Mar 31, 2008, at 2:36 PM, David wrote:


On Mon, Mar 31, 2008 at 2:26 PM, Jeff LaMarche  
[EMAIL PROTECTED] wrote:
4) You can, as Ben mentioned, use performSelector:onMainThread: to  
actually have the object inserted on the main thread's context.  
It's a bit of a pain, but threads are always at least a little  
painful.


How? Core data says that to use NSManagedObjects between threads  
you need to pass an ID and access it from another context. But you  
don't even get an ID until you perform a save on the original  
context. I'm then back to my original problem where the save  
itself takes too long.


From what I've read so far, my current thinking is that I need to  
give up on Core data. I can easily create my own objects, handle  
my own locking or synchronization. I was thinking to still use  
NSTreeController bound to my objects.


Its a shame because core data sounds so cool. I love the data  
modeling aspects. Nice way to think through the problem even if I  
end up not using it.


Well, I don't know exactly what you're doing in your thread, but  
you could create a method that that took, for example, a dictionary  
as an argument, then when you're ready to insert the object in your  
thread, pass that method the values you need having it fire on the  
main thread and then create the Core Data entity based on the  
passed values and then insert it into the main thread's context.   
If you needed to do further work on that entity, like adding  
relationships to it, then it would get to be trickier, as you'd  
also need to get its managedObjectID back to your thread.


Actually this isn't true.  You can add relationships, etc. without  
having to pass them around since you will be doing a save at some  
point and that will sync everything back to the persistent store.   
Then, once you pass the OID of your newly inserted object back to you  
main thread you can fetch it from the store and the relationships you  
added to it, etc. will be intact.



My worker thread looks something like this (pseudo-code):

Main thread:

[NSThread detachNewThreadSelector:@selector(workLoop:)  
toTarget:newWorker withObject:self];


Worker thread executes work loop which inserts new managed objects,  
saves them and sends the new oids back to the main thread by calling:


[owner performSelectorOnMainThread:@selector(addResults:) withObject: 
[newManagedObjectSet valueForKey:@objectID] waitUntilDone:NO];


The worker also notifies its owner (which was passed to detach...)  
just before exit.


This is loosely based on SIWorkerThread by Daniel Vollmer http:// 
www.maven.de/2007/01/cocoa-worker-thread/ with use of  
performSelectorOnMainThread to pass OIDs back.



You also should try using an SQLite store.  It will be faster than a  
binary store for saving incrementally since it only touches part(s)  
of the file.  However if you are adding lots of objects make sure you  
look at how often you save and if there are ways to decrease that  
frequency.


Lastly, I kind of wonder if there might be some way to integrate a  
secondary In-Memory store into this setup for use in passing the  
objects created by the worker thread back to the main thread, it  
seems like it might introduce some more complexity but might also be  
worthwhile performance-wise since saving to the SQL store does have a  
certain amount of latency due to how it hits the disk (particularly  
on Tiger).  Any thoughts on this Ben?


-Ben
--
Ben Lachman
Acacia Tree Software

http://acaciatreesoftware.com

[EMAIL PROTECTED]
740.590.0009




___

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: Threads and Core Data, bindings results in view corruption

2008-03-31 Thread Ben Trumbull

request you should file. There are better ways
to implement this than locking at the NSManagedObject level.

I have interpreted that to mean that locking the
managedObjectContext would be sufficient. I hadn't realized that
bindings would try to obtain locks.

No, it doesn't. But it needs to obtain locks to honor your locking.

The list archives also have these, which you should read:
http://lists.apple.com/archives/cocoa-dev/2007/May/msg00222.htmlhttp://lists.apple.com/archives/cocoa-dev/2007/May/msg00222.html
http://lists.apple.com/archives/cocoa-dev/2008/Jan/msg01889.htmlhttp://lists.apple.com/archives/cocoa-dev/2008/Jan/msg01889.html

It's possible to shuttle pending changes between threads by hand using KVC.

Are you describing in general or specifically with Core Data? Can
you give more insight on this? Are you saying that I manually track
changes from core data?

For updates objects, you can just pass a dictionary of deltas between
threads if you don't want to save.

For inserted objects, you'd need a proxy insert. But, yes this works
generally and with Core Data (although not conveniently).

Both KVC and Core Data have methods to make this somewhat less painful.

Manually tracking changes from Core Data is pretty easy. We post the
NSManagedObjectContextObjectsDidChangeNotification every time you
call -processPendingChanges.

On Leopard, in the scenarios under which you can save, you can also
use -mergeChangesFromContextDidSaveNotification:

But isn't a notification received on the same thread on which it was posted?

Yes, but that's not what the API is for. It takes the notification
object, and merges it into the current MOC's state.

You could grab the notification object from the save on your
background thread, and pass it to the main thread with
-performSelectorOnMainThread: and this method will merge all the
changes into the main thread's MOC.

It still requires inserts be saved, but otherwise handles all the
merging logic efficiently.

Finally, in 4 years no one has filed a bug about this.

File a bug about what?

Everything you don't like. Documentation, example code, Core Data,
Bindings, performance, enhancements, feature requests ...

Do you consider the threading behavior in bindings and Core data to be a bug?

This is about what you consider to be suboptimal.
--

-Ben
___

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]

scrollRangeToVisible from within mouseDown causing crash?

2008-03-30 Thread Ben Lachman

I just added a call to scrollRangeToVisible: that is sometimes called  
from my text view's mouseDown method.  Now, whenever  
scrollRangeToVisible: is called on a range that is not visible, the  
next drawRect of the text view crashes with the exception: ***  
NSLayoutManager, _getGlyphBuffer(): NSZoneMalloc  
failed! (EXC_BAD_ACCESS).  I had assumed that this was just a memory  
management bug on my part, but the fact that I can basically turn the  
crash on or off based on whether I call scrollRangeToVisible has me a  
bit confused.  Anyone know what this could be?


-Ben
--
Ben Lachman
Acacia Tree Software

http://acaciatreesoftware.com

[EMAIL PROTECTED]
740.590.0009



___

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 Revert Question


Mike,

Each persistent document has its own Core Data stack.  When you close 
one, and reopen it, it has a new NSPersistentStoreCoordinator, 
NSManagedObjectModel, and NSManagedObjectContext.


So any bindings to managed objects or their entity descriptions from 
the old, deallocated persistent document are effectively invalid.

--

-Ben
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Core Data and NSOperation


Daniel,

Each NSOperation is, conceptually, its own thread.  In addition to 
using NSInvocationOperation to easily dispatch a work function to an 
object, you'll also need to follow the multi-threading rules 
described in the Core Data Programming Guide.

--

-Ben
___

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

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

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

This email sent to [EMAIL PROTECTED]

re: Core Data migration


David,


To sum up:
Relationships to entities from which another entity inherits are not
automatically set up properly.


Unfortunately.  This is a known issue.


Anyone have any experience with this, or know how to handle this
situation? I suppose I could write a whole bunch of custom code to
handle it, but it seems as if the migration system should handle the
inheritance.


I'll trade you a bug report for a work around.
--

-Ben
___

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

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

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

This email sent to [EMAIL PROTECTED]

re: Core Data Client/Server Application


Philip,

Core Data doesn't support client server applications.

Some developers have successfully used it on the client for its data 
management (undo, change tracking, notifications, etc) and Cocoa 
Bindings support, with an in-memory store they manage themselves.  A 
few developers have done more sophisticated things with a Core Data 
sqlite store that is effectively a cache of a subset of the server's 
database.


But there's no back end support for MySQL or Postgres besides what 
you do for yourself.

--

-Ben
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Core Data faulting and bindings: recursive KVO notifications?


Dennis,

Well, it might be far from ideal for CD performance, but that doesn't 
mean it's bound poorly.  It is done exactly to do what we need it to 
do, otherwise this binding would have been the first to be targeted 
for rewrite.


Creating a gigantic autoreleased NSArray from valueForKeyPath: and 
simultaneously observing tens of thousands of objects is an awful lot 
of work for little reward.


The user cannot *see* tens of thousands of things.

I really do require the app to be able to show the user the values of 
about 1000 items at once, e.g. for a stack of related items.  If they 
are the same for every item, it is important that that value be

visible to the user.


You want distinct values, not tens of thousands of them.  Too much 
data is unmanageable from a user experience perspective.


Since your data is mostly read only, observing all these values is a 
horrific waste.  Just get the distinct values once, and invalidate 
the cache in the rare case the user edits one of them.


And this is one thing Bindings as it is, cannot do properly:  The 
creation of all observation info (one dictionary for each bound 
property of each item in the selection) when selecting is just too 
much overhead.  Plus you easily encounter the aforementioned stack

overflow.


You should file a bug report on this.  Also, I still don't see a bug 
report for your earlier problem with KVO  faulting.



Properties should be propagatable to 1000 objects at once for my
users, as they work equally with individual images and up till 1000-
image stacks.


Your 30 monitor must be a lot larger than mine.

I guess this calls for an extra layer of indirection, 
with a real separate entity representing the image stack and 
propagating the changes, without having 1000s of observers-observed

object relationships.


Exactly. Now that's an idea that can scale.
--

-Ben
___

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: Threads and Core Data, bindings results in view corruption


David, Jeff, Ben

There are a few issues here.

First, enough pieces of AppKit and Cocoa Bindings are not thread safe 
that, even without Core Data, you just can't do this in this 
particular fashion.


If you want multi-threaded work with the view and controller classes 
in Cocoa, you'll need to perform your background operations, and 
communicate back to the main thread (view  controllers) via the run 
loop.  -performSelectorOnMainThread and its friends in NSThread.h are 
your best bet.


Using a run loop on a background thread and communicating from the 
main thread to it with the new 10.5 -performSelector... methods is 
often conceptually simpler (easier to debug) than many other 
threading patterns.


Sharing a MOC with Cocoa Bindings and a background thread will end in 
tears.  Cocoa Bindings doesn't lock its bound MOC, so you're 
basically SOL.


Even if it did work, though, it'd be a bad idea.  Sharing a MOC means 
a background thread would still at times block the main thread and 
SPOB your app.


These 3 points (can't work, doesn't work, shouldn't work) are why the 
Core Data Programming Guide says don't do this.


This isn't to say what what you intend to accomplish is wrong or 
undesirable. Quite the contrary.  Just that this 'how' is going in 
the wrong direction.



The Core data programming guide says its best to maintain a separate
managedObjectContext per thread. But this appears to require the data to be
written to persistent store to make it work (file). That not reasonable in
my case where I'm adding many objects to an object tree. It takes a
significant amount to time to write it out, negating the benefit of trying
to make the UI seem responsive.


The list archives also have these, which you should read:
http://lists.apple.com/archives/cocoa-dev/2007/May/msg00222.html
http://lists.apple.com/archives/cocoa-dev/2008/Jan/msg01889.html

It's possible to shuttle pending changes between threads by hand using KVC.

On Tiger, saves are especially expensive as the default behavior was 
to use a more correct/aggressive version of fsync, specifically 
fcntl(...,F_FULLFSYNC).  This is 100-1000x slower than fsync, which 
technically is incorrect on nearly all consumer grade hard drives at 
a hardware level.


On Leopard, we made significant performance optimizations, so the 
user experience can vary greatly between the two OS's.


If you're inserting a large number of new objects, you really should 
just batch the operation together, save, and present the user with 
new objects in the tree view in batches.


On Leopard, in the scenarios under which you can save, you can also 
use -mergeChangesFromContextDidSaveNotification:


While AppKit  Bindings makes it impossible to share a MOC with a 
background thread, theoretically all your background threads can 
share a MOC if you lock and unlock them.  Or you could just have 1 
background thread processing asynchronous operations.  That'd be a 
lot easier to debug.


You should also use the Debug libraries and Core Data multi-threaded 
assertions:

http://lists.apple.com/archives/cocoa-dev/2008/Mar/msg01098.html

Life's a lot easier when your app halts in gdb as soon as you make a 
mistake.  'thread apply all bt' is your friend.


Finally, in 4 years no one has filed a bug about this.

If one developer has a problem, it's unfortunate.  If three 
developers have a problem, it's an issue.  If two hundred developers 
have a problem, it's a crisis.


Kinda hard to tell the difference if developers can't be bothered to 
speak up in the only way that really matters: bugerport.apple.com


Feature requests, performance problems, and enhancement suggestions 
are all bugs

--

-Ben
___

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: Threads and Core Data, bindings results in view corruption



On Mar 30, 2008, at 7:50 PM, Ben Lachman wrote:

I'm guessing the bugs really should be filed on the documentation  
since one page on performance of a highly complex API like CD is  
nowhere near enough.  My guess is that documentation doesn't get as  
many bugs as it should since it is, at the point of the developer  
filing the bug, no longer a road block and therefore is kind of seen  
(wrongly) as a waste of time since it is just for the greater good  
of the dev community not getting your project done.


There are two sets of bugs you should file.  (1) better documentation  
for the current state of affairs and (2) better support for your work  
pattern in a future version of the framework.


Developers need to file their own bugs.

There are several reasons for that.  First, to be able to check the  
status of an issue and track it over however long it takes to get  
fixed. Second, to be accessible to ADC for follow ups, clarifications  
in case we can't reproduce it, or receiving work arounds for known  
issues.   Especially since once in a while, you might actually get  
back a work around that's better than what you came up with yourself.   
Of course, filing the issue before spending lots of time developing a  
workaround might also save you some effort once in a while.


And so my shadowy masters actually believe real live developers have  
this problem, as opposed to my imaginary friends.  Oddly 20  
developers requested this seems to work better than  we should spend  
lots of time on this because I feel like it


And that just covers the problems we already know about.  There are a  
few more reasons for filing bugs you've worked around ...


Thanks for the feedback it was quite helpful.  Any thoughts or  
tricks to reduce the frequency of saving in worker threads would be  
welcome, but I think I'm now on the right path.



Batching and coalescing are both good ideas, so you're on the right  
track.  Your other alternative is a proxy object for inserts, as I  
describe in one of the list archived messages I referenced earlier.


You could also consider evaluating whether or not requiring Leopard  
makes sense for your customer base.  At some point, there's a  
diminishing return on your effort to address a problem that $130 can  
mitigate.  A compromise is to not perform the same threading on Tiger,  
or not in the same way, and accept a somewhat different user  
experience on older systems.


- Ben

___

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]

iPhone Interface builder

2008-03-28 Thread Ben Densmore

Hi everyone,
 I'm new to doing iPhone development and trying to get up to speed on the 
interface builder for iPhone. I see some basic tutorials on doing Cocoa based 
apps but can't seem to find anything on Cocoa touch and the interface builder. 

I know it was just released in Beta 2 but are there any walk through examples 
of creating a Cocoa Touch interface in IB?

Thanks,
Ben

___

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

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

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

This email sent to [EMAIL PROTECTED]

re: Core Data faulting and bindings: recursive KVO notifications?

2008-03-28 Thread Ben Trumbull




The problem I'm having arises when selecting all images at once
(Command+A), if they are fairly large in number (in my store: ~2000).
This takes an enormous time that is definitely  O(n).


Command-A should be instantaneous, even for selections 10x larger. 
The typical performance problems I've seen with array controller 
selections are (1) complex KVO observer actions cascade (2) tripping 
faults unnecessarily (3) using expensive array controller options.


(1) Complex KVO observer actions need to be carefully constrained. 
If they simply grow organically, then it's pretty easy to fall into 
the trap of observers creating side effects that trigger other 
observers that cascade to yet more observers.  This (a) makes your 
code impossible to understand, since no one ever intentionally 
designed their app that way from the beginning, and (b) sucks for 
performance.


It's often easier to understand, and much faster, to use 
NSNotificationCenter to defer and coalesce observations for a batch 
operation like operating upon 2000 objects.  One way to achieve this 
with the array controller is to remove all the objects from the 
controller, do your batch operation, and then add them back.


(2) Firing faults unnecessarily is the canonical performance issue 
for Core Data developers.  Our SQL logging 
(-com.apple.CoreData.SyntaxColoredLogging 1 
-com.apple.CoreData.SQLDebug 1) and our Instruments template can help 
you find this, and identify which entities you're faulting 
excessively.


If you need that data, it's much (10-100x) better to batch fetch the 
data instead.  This is described in the Core Data Programming Guide 
under Performance.


(3) Auto rearrange content can be very expensive.  It can make the 
notification cascading from (1) worse.  Also, Avoid empty selection  
Preserve selection can force the array controller to fire faults it 
otherwise wouldn't, which is expensive.



Regarding the call into _didChangeValuesForKeys:, the API contract 
for KVO requires Core Data call -willChange/-didChange during 
faulting.  This is pretty undesirable.


This recurses further with all images in the controller selection 
until the whole object graph is in-memory.  It is much slower (1 
minute on a MBP with 2000 elements in the controller set) than loading 
the data in a normal manner, probably because of spread faulting and 
the large stack depth.


If it's actually recursing through the entire graph, then it's 
probably a bug in your observer method.  If it's looping, then it 
could simply be toggling off a few array controller options will 
address the issue.


You should file a bug with bugreport.apple.com, and include the 
entire stack trace.  Without the rest of it, it's hard for me to say 
if this is the expected stack depth or not.  It may be a problem with 
one of your custom observation methods not coexisting happily with 
faulting, but it's a bit hard to tell from this excerpt.

--

-Ben
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Core Data faulting and bindings: recursive KVO notifications?

2008-03-28 Thread Ben Trumbull



On Mar 28, 2008, at 7:38 PM, Dennis Lorson wrote:



On 28 Mar 2008, at 20:24, Ben Trumbull wrote:




The problem I'm having arises when selecting all images at once
(Command+A), if they are fairly large in number (in my store:  
~2000).

This takes an enormous time that is definitely  O(n).


Command-A should be instantaneous, even for selections 10x larger.  
The typical performance problems I've seen with array controller  
selections are (1) complex KVO observer actions cascade (2)  
tripping faults unnecessarily (3) using expensive array controller  
options.


(1) Complex KVO observer actions need to be carefully constrained.  
If they simply grow organically, then it's pretty easy to fall into  
the trap of observers creating side effects that trigger other  
observers that cascade to yet more observers.  This (a) makes your  
code impossible to understand, since no one ever intentionally  
designed their app that way from the beginning, and (b) sucks for  
performance.


This seems like an easy mistake indeed.  However, I checked my code  
for this when originally debugging the issue, and while it is  
difficult to eliminate all cases, no custom KVO observer triggers  
other observers as for my subclass implementation -- and if they do,  
they relate to disjunct entity objects that should not trigger others.


You've bound the text fields to the selection poorly.  That's the  
easiest and best fix.  Other workarounds for your edification below.


The good news is that the issue is entirely avoidable by batch  
faulting using the 10.5 [NSFetchRequest  
setReturnsObjectsAsFaults:NO] and executing the fetch on all objects  
in the selection.


Yes.  You can also do something like this to ignore KVO notifications  
around faulting:


#import Cocoa/Cocoa.h

@interface SubObject : NSManagedObject {
@private
BOOL _isAccessible;
}
- (BOOL) isAccessible;
@end

@implementation SubObject
- (void) awakeFromInsert {
[super awakeFromInsert];
_isAccessible = YES;
}
- (void) awakeFromFetch {
[super awakeFromFetch];
_isAccessible = YES;
}
- (void) willTurnIntoFault {
[super willTurnIntoFault];
_isAccessible = NO;
}
- (void) didTurnIntoFault {
[super didTurnIntoFault];
_isAccessible = NO;
}
- (BOOL) isAccessible {
return _isAccessible;
}
@end

and elsewhere:

- (void) observeValueForKeyPath:(NSString *)keyPath ofObject: 
(id)object change:(NSDictionary *)change context:(void *)context

{
if ([object isKindOfClass:[SubObject class]]) {
SubObject* mine = (SubObject*)object;
if (![mine isAccessible]) {
return;
}
}
// stuff
}



But still, I have two questions:

- Am I overlooking something obvious?  If it is the correct  
approach, someone else must have experienced this in a larger master- 
detail set, right?


Yes, you should disable Allows Editing Multiple Values Selection  
when you expect selection to include more than a handful of objects.


- While I understand the constraints the CD API imposes, shouldn't  
this be labeled as a bug?  I'm not sure here, if so, I'll file it  
with bugreporter.


You should file a bug and attach your sample app as well.

(2) Firing faults unnecessarily is the canonical performance issue  
for Core Data developers.  Our SQL logging (- 
com.apple.CoreData.SyntaxColoredLogging 1 - 
com.apple.CoreData.SQLDebug 1) and our Instruments template can  
help you find this, and identify which entities you're faulting  
excessively.
If you need that data, it's much (10-100x) better to batch fetch  
the data instead.  This is described in the Core Data Programming  
Guide under Performance.


While I'm certain to perform some optimization here, the delay I was  
having was almost fully due to the issue above.
It is indeed very useful, but in my case mostly to avoid the  
critical stack overflow.  I will not be having 100.000+ stores so  
the excessive faulting has still little impact.


Each fault is an I/O.  Do a few batches v.s. 1,000 individual ones is  
much much better.  You can see this in Instruments Core Data template,  
with the Cache Miss instrument.


If it's actually recursing through the entire graph, then it's  
probably a bug in your observer method.  If it's looping, then it  
could simply be toggling off a few array controller options will  
address the issue.


You should file a bug with bugreport.apple.com, and include the  
entire stack trace.  Without the rest of it, it's hard for me to  
say if this is the expected stack depth or not.  It may be a  
problem with one of your custom observation methods not coexisting  
happily with faulting, but it's a bit hard to tell from this excerpt.


As you can verify from the test project, I don't use any custom KVO  
logic.  Still, the crash should occur almost every time, after a  
variable amount of time (seconds range).


Yes, thanks.  Sample projects

NSNoCellMask differences in Leopard vs. Tiger

2008-03-20 Thread Ben Lachman

On Tiger one could set up borderless, momentary light square button  
with an icon and call setHighLightsBy: with NSNoCellMask and you'd  
get a nice darkening on the non-transparent parts when the user  
pressed the button.  However these same buttons on Leopard don't  
change at all during a user's press.  Is there a way to get a similar  
effect on Leopard without using an alternate image (some of my  
buttons already have alternate images)?


Thanks,
-Ben
--
Ben Lachman
Acacia Tree Software

http://acaciatreesoftware.com

[EMAIL PROTECTED]
740.590.0009



___

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: dataCellForTableColumn method

2008-03-19 Thread Ben Lachman

Make sure the field editor isn't getting in the way.  The field  
editors inserts itself into the first responder chain and grabs  
textual input during editing.


http://developer.apple.com/documentation/Cocoa/Conceptual/ 
TextEditing/Tasks/FieldEditor.html


HTH,

-Ben
--
Ben Lachman
Acacia Tree Software

http://acaciatreesoftware.com

[EMAIL PROTECTED]
740.590.0009



On Mar 19, 2008, at 2:58 PM, Hans Hansen wrote:

Anyone know how best to use multiple NSTextCell subclasses, in a  
table/outline column?


When I use the dataCell... methods in NSTableColumn, NSTableView,  
or NSOutlineView, it works great until I try to edit the cell, at  
which point the cells never receive the edit/select actions. I've  
tried lots of things but can't figure out what's happening, nor a  
better why to do this overall.


In other words:

When I use the dataCellForTableColumn method, my table does display  
the different textcell subclasses returned. But when I send the  
table/outline [self editColumn:1 row:[self selectedRow]  
withEvent:theEvent select:YES] message it seems to get lost -- my  
specified cells don't receive an editWithFrame/selectWithFrame  
action. If I remove this method and only use one cell class in the  
column, it works as expected.


- (NSCell *)outlineView:(NSOutlineView *)outlineView  
dataCellForTableColumn:(NSTableColumn *)tableColumn item:(id)item {


if ([item isKindOfClass:[Project class]]) return projectTextCell;
if ([item isKindOfClass:[Action class]]) return actionTextCell;
if ([item isKindOfClass:[Item class]]) return itemTextCell;
if ([item isKindOfClass:[Note class]]) return noteTextCell;

return nil;
}

The point of this is to breakout my cell designs for efficiency and  
comprehension. But so far it's just making me nuts. ;-).



___

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: CoreData code working on Tiger - not on Leopard

2008-03-18 Thread Ben Trumbull


Steve,

You can get some more information.  Add an @try/@catch block to your 
AppDelegate.m:700 line, and log both the exception and its userInfo 
dictionary.


Also, if you search the archives for my recent post
[ANN] 10.5.2 Core Data debug library available

you can run against a version of Core Data that has assertions 
enabled.  In addition to the multi-threading assertions, it has more 
just plain old assertions.


Most of the problems I've seen like this have been issues with custom 
accessor methods doing things they shouldn't, or fetching within 
-awakeFromFetch:, or some odd edge cases involving delegate calls.


If you build against the 10.4 SDK, and your application still doesn't 
work on Leopard, that's a bug, and you should file it with 
bugreport.apple.com.  If it only fails building against the 10.5 SDK, 
then it could be helpful to review


http://developer.apple.com/releasenotes/Cocoa/CoreDataReleaseNotes/index.html
--

-Ben
___

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]

NSButtonCell doesn't visually update during trackMouse:inRect:ofView:untilMouseUp:

2008-03-17 Thread Ben Lachman

I have a few NSButtonCells that I'm using in a custom view.  I need  
them to track the mouse during clicks and do this by calling NSCell's  
trackMouse:inRect:ofView:untilMouseUp:.  This works fine except that  
the button cells never update their graphical state by highlighting  
or whatever.  However if I call performClick: on them the button  
updates as it should.  Is the only solution to this to implement  
mouse tracking at the view instead of at the cell level?


Thanks,
-Ben
--
Ben Lachman
Acacia Tree Software

http://acaciatreesoftware.com

[EMAIL PROTECTED]
740.590.0009



___

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: NSButtonCell doesn't visually update during trackMouse:inRect:ofView:untilMouseUp:

2008-03-17 Thread Ben Lachman

So my view is a NSControl subclass and after playing with this some  
it seems you have to do one more thing.  If you're going to have a  
control handle multiple cells (in my case button cells) you have to  
call setCell: for the correct cell in mouseDown: and then let super  
handle the mouse event.  This seems to work much better than trying  
to handle the event yourself.


Does this sound right to you Ken?

In any case I think there should really be more info on how to  
subclass NSControl and NSCell.  The developer docs are really sparse  
on this. I filed a bug asking for a guide on this topic (rdar:// 
5804311).


-Ben
--
Ben Lachman
Acacia Tree Software

http://acaciatreesoftware.com

[EMAIL PROTECTED]
740.590.0009

On Mar 17, 2008, at 4:25 PM, Ken Ferry wrote:

On Mon, Mar 17, 2008 at 8:49 AM, glenn andreas [EMAIL PROTECTED]  
wrote:


 On Mar 17, 2008, at 1:42 AM, Ben Lachman wrote:


I have a few NSButtonCells that I'm using in a custom view.  I need
them to track the mouse during clicks and do this by calling
NSCell's trackMouse:inRect:ofView:untilMouseUp:.  This works fine
except that the button cells never update their graphical state by
highlighting or whatever.  However if I call performClick: on them
the button updates as it should.  Is the only solution to this to
implement mouse tracking at the view instead of at the cell level?



 You need to set the control view of the cell to your view and then
 implement the appropriate [update|draw]cell[inside]: methods in your
 view.


Or, a bit more specifically, setControlView: will fail to store
anything if the passed view is not an NSControl.  You can use an
NSCell to purely stamp out drawing in an NSView, but more complicated
interaction requires the view to be an NSControl, so that the cell can
message the control in various ways.  It isn't just updateCell:.

Ken Ferry
Cocoa Frameworks


 Basically a cell expects to be inside a control and needs to be
 able to tell that control to draw itself (and thus redraw the cell).
 One would think that the parameters to trackMouse would be  
sufficient
 to have the cell handle this by itself, but since a control could  
have
 a background behind the cell, it's really up to the control to  
decide

 how to redraw the cell.


___

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: NSSpeechSynthesizer/UKSpeechSynthesizer speechSynthesizer:didFinishSpeaking: called immediarely [Solved]

I found the problem.  I was having the speech synth speak a tag line  
before the main string and was getting the didFinishSpeaking: call  
back when the tag was cut off by the main string starting to be  
spoken.  Thanks for confirming that it was my own fault. :-)


-Ben
--
Ben Lachman
Acacia Tree Software

http://acaciatreesoftware.com

[EMAIL PROTECTED]
740.590.0009



On Mar 13, 2008, at 11:30 AM, Dave Verwer wrote:


I have been using this callback extensively recently in the way you
describe and have not seen this issue either.

On 3/13/08, Paul Bruneau [EMAIL PROTECTED] wrote:

On Mar 13, 2008, at 5:27 AM, Ben Lachman wrote:


According to the NSSpeechSynthesizer docs:

speechSynthesizer:didFinishSpeaking: is invoked when the speaking of
the string ends. The second parameter of this method indicates
whether the text was entirely spoken or was disrupted (as might
happen if the user dismisses a spoken alert).

This make me think that I should get my delegate method called when
the speech stops in the users perception.  However in my code I have
it speak fairly long strings and the didFinishSpeaking: delegate
method gets called back almost immediately.  Is this correct
behavior?   I tried Uli's UKSpeechSynthesizer replacement for
NSSpeechSynthesizer, but it seems to have the same issues.  If this
is the correct behavior, is there a way to figure out when the
speech is actually done form the user's perspective (ie the audio
output actually stops)?   I'm trying to get a slide show type
animation synced with speaking text and if I can't find out when the
speech is done I'm not sure how I'm going to advance the animation
at the correct time.

Thanks,

-Ben



Hi-

 I don't see the behavior you are reporting. Aaron's book has a  
famous
 example that uses -didFinishSpeaking to disable a Stop button  
on an

 interface when the current speech completes, and it gets called
 exactly when the speech stops speaking.

 You can download his code and try it:
 http://bignerdranch.com/products/cocoa1.shtml

 Look for the solutions to the exercises link. The example I  
looked at

 is in the 05_HelperObjects folder and is called SpeakLine_D



 ___

 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/dave.verwer% 
40shinydevelopment.com


 This email sent to [EMAIL PROTECTED]




--
e-mail: [EMAIL PROTECTED]
web: http://shinydevelopment.com

Shiny Development Ltd. is registered in England, Registration Number:
05805802. Registered Office: 4 Claridge Court, Lower Kings Road,
Berkhamsted, Herts., HP4 2AF.
___

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/blachman%40mac.com

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: File upload with NSURLRequest fails

I do this with a perl script on the back end.  My experience was that  
its was more cajoling the perl script into working that the PHP side,  
but that may be because I'm not much of a perl wizard (maybe only  
level 8 or so :-).  I found it was important to declare a filename if  
you're transferring data like this.


Here is my code:

NSMutableURLRequest *postRequest = [NSMutableURLRequest  
requestWithURL:aURL cachePolicy:NSURLRequestReloadIgnoringCacheData  
timeoutInterval:30.0];


NSString *boundary = @Boundary+AaB03x;

[postRequest setHTTPMethod:@POST];
[postRequest addValue:[aURL] absoluteString]  
forHTTPHeaderField:@Referer];
[postRequest setValue:[NSString stringWithFormat:@multipart/form- 
data; boundary=%@, boundary, nil] forHTTPHeaderField:@Content-Type];


NSEnumerator *dictionaryEnumerator = [postDictionary keyEnumerator];
NSString *currentKey = nil;

NSMutableData *multipartData = [NSMutableData data];

while( (currentKey = [dictionaryEnumerator nextObject]) ) {
	[multipartData appendData:[[NSString stringWithFormat:@[EMAIL PROTECTED] 
\n, boundary] dataUsingEncoding:NSASCIIStringEncoding  
allowLossyConversion:NO]];


id currentValue = [postDictionary objectForKey:currentKey];

	if( [currentValue isKindOfClass:[NSData class]]  [NSImageRep  
imageRepClassForData:currentValue] != nil ) {
		[multipartData appendData:[[NSString stringWithFormat:@Content- 
Disposition: form-data; name=\[EMAIL PROTECTED]; filename=\image.jp2\\r\n,  
currentKey] dataUsingEncoding:NSASCIIStringEncoding]];


		[multipartData appendData:[@Content-Type: image/jp2\r\n  
dataUsingEncoding:NSASCIIStringEncoding]];
		[multipartData appendData:[@Content-Transfer-Encoding: binary\r\n\r 
\n dataUsingEncoding:NSASCIIStringEncoding]];


[multipartData appendData:currentValue];
}   
}

[multipartData appendData:[[NSString stringWithFormat:@[EMAIL PROTECTED] 
\n, boundary] dataUsingEncoding:NSASCIIStringEncoding  
allowLossyConversion:NO]];


[postRequest setHTTPBody:multipartData];

Hope this helps,

-Ben

--
Ben Lachman
Acacia Tree Software

http://acaciatreesoftware.com

[EMAIL PROTECTED]
740.590.0009



On Mar 13, 2008, at 4:50 PM, Tom Harrington wrote:


I'm trying to upload a file with the NSURL* API, but on the server end
the PHP code is unable to decode the $_FILES array.  The PHP code
works fine when posted from an HTML form (and from clients on other
platforms).

Traffic sniffed on the wire looks good as far as I can tell, so what
would be the problem?  The code in question follows.

NSString *urlString = @http://server:8080/php/post.php;;
NSURL *url = [NSURL URLWithString:urlString];
NSString *requestMethod = @POST;

NSMutableURLRequest *req = [NSMutableURLRequest requestWithURL:url];
[req setHTTPMethod:requestMethod];

NSString *headerFieldName;
NSString *headerFieldValue;

NSString *boundary = @-1234567890;

headerFieldName = @Content-Type;
headerFieldValue = [NSString stringWithFormat:@multipart/form-data;
boundary=%@, boundary];
[req addValue:headerFieldValue forHTTPHeaderField:headerFieldName];

NSString *phone = @7195554321;
NSDate *currentDate = [NSDate date];
	NSDateFormatter *dateFormatter = [[[NSDateFormatter alloc] init]   
autorelease];

[dateFormatter setDateFormat:@MMddHHmmss];
NSString *dateString = [dateFormatter stringFromDate:currentDate];

// Will look something like this: form-data; name=file;
filename=7195554321_1_20080311132327_jpg
headerFieldValue = [NSString stringWithFormat:@form-data;
name=\file\; filename=\[EMAIL PROTECTED]@_jpg\, phone, dateString];

NSMutableData *postBody = [NSMutableData data];
// Add boundary
[postBody appendData:[[NSString stringWithFormat:@[EMAIL PROTECTED], 
boundary]
dataUsingEncoding:NSUTF8StringEncoding]];
// Add form-data with filename
[postBody appendData:[[NSString
stringWithFormat:@Content-Disposition: [EMAIL PROTECTED], headerFieldValue]
dataUsingEncoding:NSUTF8StringEncoding]];
// Add content-type
[postBody appendData:[[NSString stringWithString:@Content-Type:
null\r\n\r\n] dataUsingEncoding:NSUTF8StringEncoding]];
// Add image data
[postBody appendData:imageData];
// Add boundary--
[postBody appendData:[[NSString stringWithFormat:@[EMAIL PROTECTED],
boundary] dataUsingEncoding:NSUTF8StringEncoding]];

[req setHTTPBody:postBody];

NSHTTPURLResponse *res = nil;
NSError *err = nil;

NSData *data = [NSURLConnection sendSynchronousRequest:req
 
returningResponse:res

Re: Can core data save to a remote file?


On Mar 14, 2008, at 2:02 AM, Kyle Sluder wrote:

On Fri, Mar 14, 2008 at 1:34 AM, mmalc crawford  
[EMAIL PROTECTED] wrote:

 The canonical description is, it's an object graph management and
 persistence framework.  It is not in and of itself an object store,
 and persistence is only one of its functions -- in some respects the
 less interesting one.


So it manages a graph of objects and stores them.  You can't do the
second part without the first, and how often have you used Core Data
without persistence in mind?



You can in fact persistently store files without managing them as a  
really nifty easy to use, well performing, bindings enabled, undo- 
able object graph.  Its called a filesystem.  But most of us don't  
think they're so nifty anymore*.


Also, it is quite attractive in some cases to use CoreData with only  
an in memory store, which isn't persistent as far as CoreData is  
concerned... and I'm guessing mmalc has some experience with this.


-Ben

*excepting ZFS, etc.
--
Ben Lachman
Acacia Tree Software

http://acaciatreesoftware.com

[EMAIL PROTECTED]
740.590.0009

___

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: Custom View drawn twice?