from:"j o a r"



On Jun 16, 2008, at 7:44 AM, David wrote:


While I've been investigating this, I have found more documentation on
thread safety issues in the "Threading Programming Guide". I'd read it
before but it helps to re-read. It says that NSView classes ARE thread
safe... to an extent.



Very interesting that it says that NSView is "generally thread-safe",  
but then immediately afterwards limits you to "perform other  
operations [...] only from the main thread". Note the "other", which  
is as broad in scope as the "generally" used earlier. I'm going to  
file an enhancement request for improved documentation here.


I think that what they want to call out there is that you can draw  
from background threads. I could be wrong, but I don't think that you  
should read more into it than that.


Also note that just because there are some operations on the NSView  
class that are thread safe, that doesn't mean that subclasses have  
even the same level of thread safety - unless explicitly called out in  
the documentation.


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: awakeFromNib



On Jun 16, 2008, at 8:07 AM, David Harper wrote:

I am setting up a preferences window, and I would like awakeFromNib:  
to be invoked earlier than it does.  Currently, it only gets invoked  
when the preferences window is shown / opened.



You can call:   -[NSWindowController loadWindow]

But I'm not sure if that's really what you should be doing - see my  
comments below.



I expected that there might be an option to specify this in the .nib  
file itself, and I got my hopes up with the "deferred" check box  
which is enabled by default - the tooltip said "Sets whether the  
window server creates a window device for the window immediately.   
When YES, the window server defers creating the window device until  
the window is moved onscreen."



No, this checkbox controls something else at a lower level, something  
you shouldn't mess with.
I have to say, I'm not even sure why we have a checkbox for this in  
IB...



Right now the reason I want to do this is that the contents of the  
controls in the preferences windows can themselves be used to save  
the preferences.  For example I'd stick [backgroundColor color] in a  
dictionary (where backgroundColor is a color well) instead of  
managing my own NSColor * and responding to delegate methods.



If I read this correctly, you use the controls in your window as model  
objects to store preferences that are accessed by other parts of your  
application? If so, I'd suggest that this is a design flaw that you  
should fix. The view objects in your application should not double as  
model objects - See: The MVC design pattern.


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: NSOutlineView threading problem



On Jun 16, 2008, at 9:05 AM, Adam R. Maxwell wrote:

This level of vagueness is persistent throughout the framework docs,  
though, and gives them an absolute value |v| < 0 with respect to  
threading (my opinion, of course).  And yes, I know the "file a bug  
report" mantra, but a) I don't get paid for filing bug reports, and  
b) it can take years even for a doc bug to be fixed (my oldest is  
from 2005, but I expect it's just forgotten).



You're clearly right in that Apple needs to provide much better  
documentation with regards to thread safety.


While I would also have to respect your "I'm not paid for filing bug  
reports" standpoint, just keep in mind that bug reports does matter -  
a lot - and I can assure you that it's much easier to get a feature  
request on improved documentation fixed, than it is to get a feature  
request on a software product fixed. The reason why this is the case  
should be clear to anyone working in the software industry. For this  
reason it is my experience that it's typically rather gratifying to  
file doc bugs - give it another chance!


If you have a very old bug open for a simple documentation fix I'd  
suggest that you contact ADC and ask for an update. There might be  
some sort of misunderstanding:


<http://developer.apple.com/contact/>


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: NSOutlineView threading problem



On Jun 16, 2008, at 3:59 PM, Adam R. Maxwell wrote:

The confusion between "thread safe" and "main thread only" on this  
list hasn't helped, either...



From a documentation perspective there is no single or simple  
definition of "thread safe", it all depends on the context.


Some objects are not thread safe, and also have the restriction that  
they can only be used on the main thread. Other objects, while still  
not being thread safe, can be used on a non-main thread - As long as  
they're only used on one thread. Other objects, while still not thread  
safe, can be used from different threads - As long as they're only  
ever used from one thread at a single time. Et.c., et.c.


The complexity of this topic makes it difficult to create the same  
type of documentation that we enjoy for the simple API reference of  
classes and methods.



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: NSSound thread-safety?



On Jun 16, 2008, at 5:07 PM, Jens Alfke wrote:

Is NSSound thread-safe? Now that I look, I can't find any  
documentation; the Cocoa thread safety docs don't refer to NSSound  
at all.



That would indicate that it isn't thread safe.

I think that you can use QTKit to load and play sound files  
asynchronously.


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: Send Key Event to Focused Window

2008-06-18 Thread j o a r

On Jun 18, 2008, at 12:31 AM, Daniel wrote:

I'm developing a tool for assistive input and my question is how can I
send a key event (like a keyboard press event) to the current window
(whatever this one could be), for data input.

Have you looked at the Quartz Event Services?

<http://developer.apple.com/documentation/Carbon/Reference/QuartzEventServicesRef/Reference/reference.html 
>

I assume that you've already familiarized yourself with the  
Accessibility APIs:

<http://developer.apple.com/documentation/Cocoa/Conceptual/Accessibility/cocoaAXIntro/cocoaAXintro.html 
>

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: Send Key Event to Focused Window

2008-06-18 Thread j o a r



On Jun 18, 2008, at 4:25 AM, Daniel wrote:


Basically, I've noticed that the code I'm using works (as it sends the
right event), but it is sent to the wrong "receiver". That means I'm
sending it to my current application, instead I should be able to
click on a button (representing a key stroke) and sending the event
(e.g. Safari) to the right application.



Cocoa is not a "cross-process" API, for the most part, so that would  
be expected.


In the code you posted you used a reference to "NSApp". This is a  
reference to your own application, it's not a reference to some other  
application. The OS prevents you from interacting directly with the  
internals of other applications for stability and security reasons.


You should be able to do what you want using Quartz Event Services.



Is there a way to build a focus-less application/window?



Can you explain what you mean by that?

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: Problem with NSWindow setFrame

2008-06-19 Thread j o a r



On Jun 18, 2008, at 11:50 PM, kalpana k wrote:


window setFrame: NSMakeRect(0,0,1024,1200)



Should this not be something more like:

NSMakeRect(0.0, -768.0, 1024.0, 1200.0)

Also note that, according to the documentation:

	"Note that any NSWindow with a title bar automatically constrains  
itself to the screen."


	<http://developer.apple.com/documentation/Cocoa/Conceptual/WinPanel/Tasks/SizingPlacingWindows.html#//apple_ref/doc/uid/2228-135785 
>


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: Creating a Bundle via Code

2008-06-20 Thread j o a r



On Jun 20, 2008, at 3:28 PM, Grant Limberg wrote:

Initially I was storing the data in Core Data.  In my app, the user  
has the ability to attach an image to a record in Core Data.  
Unfortunately, changing from a JPEG to NSData inflates a 1.5MB JPEG  
to over 20 MB.  In talking with some folks at the local Cocoaheads  
meeting on wednesday, one person suggested making a bundle or  
package in Application Support to store the images and just have a  
referencing URL in the Core Data store. This is what I'm trying to  
do now.



It doesn't sound to me that you actually need to have a bundle. You  
can just store the image data as files in the file system.


I'm also curious as to why you decompress the JPEG file? If you got  
the image as a compressed JPEG, why not store it as is?


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: Creating a Bundle via Code

2008-06-20 Thread j o a r



On Jun 20, 2008, at 3:43 PM, Grant Limberg wrote:

As far as I know, you can't store a raw jpeg in Core Data directly  
without turning it into an NSData object first which in turn  
decompresses it.



It sounds quite possible that Core Data only support images in the  
form of NSData. That said, I see no reason why you would have to  
decompress the JPEG to generate this NSData.


We need to know more about your application to provide more detailed  
assistance. Where do you get your JPEG images from? Over the network?  
From files in the file system? Pasted into an image view by the user?


It sounds like you go from JPEG -> NSImage -> NSData? Instead of  
creating a NSImage, how about just storing the JPEG as is to the file  
system first, and only later generating NSImages as needed for display  
in your application.


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: Creating a Bundle via Code

2008-06-20 Thread j o a r



On Jun 20, 2008, at 4:00 PM, Grant Limberg wrote:

Currently, the user drags an existing image from their filesystem to  
an NSImageView bound to an NSData attribute in the sqlite data  
store.  This causes the decompression from 1.5MB to 20MB.  As you  
can see, this isn't exactly efficient.   Hence the question on  
package/bundle creation.  I'm wanting to just store the jpeg  
directly to disk and just store a URL to it in the sqlite data store.



You can always re-compress the image file before writing it out to the  
file system. But that seems kind of silly...


I would suggest that you intercept the drag operation and copy the  
file directly. You should be able to do this quite easily if you  
subclass the image view:


<http://developer.apple.com/documentation/Cocoa/Conceptual/DragandDrop/DragandDrop.html 
>


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: How to prevent NSControl from graying out when sent to background?

2008-06-24 Thread j o a r



On Jun 24, 2008, at 9:28 AM, Greg wrote:

Hi, I'm making little notification windows that contain some  
NSControls in them, one particular one is the NSProgressIndicator  
(as a bar).  These windows are similar to the default growl windows,  
and so appear above all other windows and appear "active" while  
actually being hosted by a background application.  As such, the  
progress indicator in one of them is grayed out, how do I prevent it  
from doing that?



Create a custom NSWindow / NSPanel subclass that overrides "- 
isKeyWindow" to always return YES.


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: Help getting custom cell layout in NSOutlineView column

2008-06-27 Thread j o a r



On Jun 27, 2008, at 8:55 AM, Sebastian Nowicki wrote:

I've been trying to find some documentation as to how to do this,  
and as far as I can tell I'm supposed to subclass NSCell and somehow  
draw both labels. I'm completely new to creating views and such, and  
I'm unable to find any good sample code as how to do it. The layout  
I want looks something like this:


+---+
| |  Foobar
|   (Image)|
| |  Some description that can be quite  
long, but should never

| |  exceed the height of the image...
+--+

I hope that doesn't come out too mangled, but you get the picture.  
I'm mostly worried about the two text fields, since the image could  
probably go in a separate column.


How do I go about this?



This is a good piece of sample code to show how to create a complex  
custom cell subclass:


<http://developer.apple.com/samplecode/PhotoSearch/>

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: Garbage Collection woes...

2008-06-29 Thread j o a r

On Jun 27, 2008, at 12:31 PM, John Engelhart wrote:

Lesson #1: If you have any interest in performance, you must avoid,
at all costs, "writing" to a __strong pointer.

That's almost like saying:

"If you have any interest in performance, you must avoid, at all
costs, using a high level language like C."

It's only true if you ignore other things that are also both true, and
that many consider to have a higher priority. For one, using higher
level languages and libraries allows us to be more productive and to
build software that delivers more functionality while at the same time
being easier to maintain.

-(BOOL)doSomething:(id)obj error:(NSError **)error
{
if(error != NULL) { *error = NULL; } // Make sure we clear the
error object

}

It's sort of ambiguous as to what should be returned by the indirect
error pointer on the condition of success. I could think of several
neat ideas if the expected behavior were defined up front, even
requiring the caller to initialize the pointer to a default NSError
singleton and allowing errors to accumulate in a stack like
fashion. Alas, the only clearly defined behavior is that one
failure, a NSError object is indirectly returned.

The relevant documentation is found here:

<http://developer.apple.com/documentation/Cocoa/Conceptual/ErrorHandlingCocoa/CreateCustomizeNSError/chapter_4_section_4.html#//apple_ref/doc/uid/TP40001806-CH204-SW5
>

If you have suggestions for improvements, please file formal
enhancement requests.

The write barrier penalty is substantial. I benchmarked a tight
loop that called a function that did nothing but the naive clearing
of the value. The result (on a 1.5GHz G4) was that it was 2429.55%
(or, over 24 times) slower with -fobjc-gc enabled. So, best to
avoid updating a __strong pointer at any and all costs.

If you're a developer who cares about performance, your #1 priority is
to implement the actual functionality. Your #2 priority to run
meaningful benchmarks. Your #3 priority to address any performance
problems that you find, in order of severity.

Synthetic / micro benchmarks are typically of limited value. Most
Cocoa application developers will find that their performance problems
are higher level and more algorithmic in nature, rather than on this
very low level.

typedef struct {
NSString *aString;
__weak NSString *aWeakString;
NSInteger anInteger;
} MYStructType;

MYStructType globalStructTypeArray[42]; // <-- Global!

The pointer to 'aString' in the above (or any of my other __strong
pointers in my actual code) were clearly not being treated as
__strong, and the GC system was reclaiming them causing all sorts of
fun and random crashes.

Bugs are bad, and if you think that you have found one, it would be
great if you could file a formal bug report.
That said, this is Cocoa-Dev, and the code above has very little to do
with Cocoa / Objective-C development in practice.
Most Cocoa developers will find that Garbage Collection works
absolutely fine, and that runtime performance is about the same
(sometimes better, sometimes worse) compared with using manual memory
management.

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: Creating AppControllers in InterfaceBuilder 3.1

2008-06-30 Thread j o a r



On Jun 30, 2008, at 7:14 AM, [EMAIL PROTECTED] wrote:

I'm writing my first project in Leopard and can't figure out how to  
accomplish the old
"Subclass NSObject/Generate Files/Instantiate" series of steps in  
Interface Builder 3.1.



What you typically do is to create the subclass in Xcode, and not in  
IB. Once you've done that, switch back to IB and drag in a generic  
NSObject from the Library (it looks like a blue cube). Hit Cmd+6 to  
open the identity inspector, and type the name of the class that you  
want to instantiate.




On Jun 30, 2008, at 7:20 AM, Tommy Nordgren wrote:

You create the files from an XCode file template, and drag the  
header file into IB



The thinking here is indeed that Xcode handles the creation of  
classes, while IB handles instances of classes and their  
configuration. The last part of that sentence is no longer required  
though: Xcode and IB are now on better speaking terms, so you don't  
have to manually tell IB to read header files for it to learn about  
changes to classes in the project, it stays up to date automatically.



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: Responder Chain and NSViewController in non-doc applications

2008-06-30 Thread j o a r



On Jun 30, 2008, at 9:52 AM, Jerry Isdale wrote:

Again, the NSViewController doesnt appear in the responder chain,  
unless it was designated by the initial Event Responder.  If it was  
designated, but doesnt respond, what happens? An Error or does it go  
back to the responder chain?



I'm not clear on what you mean by "designated by the initial Event  
Responder".



The NSViewController is a Responder, but the associated view does  
not patch it into the responder chain for either event or action  
responding. Correct?



Correct. Unless you manually insert it into the responder chain, in  
that case typically right after its view.



But if my design explicitly specifies the target (connecting  
IBActions in InterfaceBuilder), I dont have to worry about the  
Responder chain for actions.  Correct?



Correct.


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: Newbie question: Timers

2008-06-30 Thread j o a r



On Jun 30, 2008, at 2:36 PM, Matthew Youney wrote:

In the VS environment, there is a “timer” control that can be  
dropped onto a
form, and will generate timer events every X milliseconds.  How  
would I
impliment similar functionality in Cocoa, or what would you gurus  
suggest

that I look into?  What is best?



There is no way to do that in IB, you would have to set up the timer  
in code, but that's easy enough - Check the documentation for the  
NSTimer class. What are you going to use the timer for? There might be  
something else that would be better for you to use in Cocoa.


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: Importing Xcode 2.x projects into Xcode 3

2008-07-08 Thread j o a r



On Jul 8, 2008, at 6:03 PM, John Joyce wrote:

Are there any caveats when importing an XCode 2.x project into XCode  
3?

I seem to have NIBs that are no longer connected properly...
It could be something I did (or did not do properly), but just  
curious if anybody else has had any issues.



I think that would be considered a bug in IB 3, and not an expected  
side effect. If you can verify that this is the case, and in  
particular if you can reproduce the problem, you should file a bug  
report here:


<http://developer.apple.com/bugreporter/>

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: Problem on reload data source of a table view

2008-07-15 Thread j o a r



On Jul 15, 2008, at 10:17 AM, JArod Wen wrote:

Thanks for fast reply! Just as Jens said, I have checked the table  
and I am sure that it is not nil:


Printing description of dataTable:

(gdb) continue



You should probably also verify that the NSTableView knows where to  
get data from - Using the "dataSource" property of the table view. At  
this point it sounds like a good thing to double-check that this  
connection is set up properly in IB.


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: Problem on reload data source of a table view

2008-07-15 Thread j o a r



On Jul 15, 2008, at 10:36 AM, JArod Wen wrote:

The dataSource of TableView is connected to tableSource. There is a  
TableController containing two IBOutlets to both tableSource and  
dataTable. Then dataTable.dataSource is connected to tableSource in  
IB. Anything I lost here?



You might want to verify, at runtime, that this connection is set. You  
can do this either in the debugger, or just using a standard debug log  
statement.


Btw.: Have you set up any bindings for this table view?

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: Blue lines

2008-07-15 Thread j o a r



On Jul 15, 2008, at 5:31 PM, Andrew Thompson wrote:

How do Interface Builder and Quartz Composer draw the blue line  
connections

from object to object?
I have been looking through the APIs, but I can't find anything that  
looks

right.

I thought of just drawing my own line on a custom view (shouldn't be  
that
hard), but interface builder manages to do it between objects that  
aren't

connected by ANY view, and I am not sure how to do that.



IB probably uses one or more separate transparent windows to hold the  
connection lines.


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: Attributed string to an Image without window

2008-07-16 Thread j o a r



On Jul 16, 2008, at 9:59 AM, Nethan Aryan wrote:

I have to write a command line utility which will create an image  
from another source image by adding some attributed text onto the  
source image.



Before thinking about how you would implement this, you should read  
about the concept of "daemon-safe frameworks":


	<http://developer.apple.com/technotes/tn2005/tn2083.html#SECLAYEREDFRAMEWORKS 
>


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: just don't get it...

2008-07-17 Thread j o a r



On Jul 17, 2008, at 2:24 PM, Nick Zitzmann wrote:

How on earth to I communicate with an object that has been  
instantiated by Interface Builder???


Declare an IBOutlet pointer connecting an instantiated class to the  
instantiated object. Then read the instantiated class's header file  
into IB, which is normally done automatically, but you may have to  
do it manually if you're working on a framework.



...but note that this is not how James would solve the concrete  
problem mentioned in the original message.


In a document based application you don't have "the document", you  
have any number of documents. The AppDelegate doesn't just want a  
reference to any document, it's looking for some specific document.  
Typically that would be the document associated with the "main  
window" (check the documentation for more on what "main" and "key"  
window is in Cocoa). You could find that document like this:


    NSApp > Main Window > Window Controller > Document


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: NSMutableDictionary autorelease chrashes application

2008-07-18 Thread j o a r



On Jul 18, 2008, at 11:51 AM, Andy Lee wrote:


I don't see the difference from the caller's point of view.



There isn't any, and that was not MMalcs point. His point was that you  
were using the term "autoreleased" incorrectly.


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: observers removed?

2008-07-27 Thread j o a r



On Jul 27, 2008, at 7:36 PM, James Maxwell wrote:

Stupid question, probably, but if an object is deleted, is it  
automatically removed as an observer of notifications? Or should I  
write a removeObserver into my dealloc?



If you're talking about NSNotification/Center, then the answer is: "It  
depends".
If you're using GC, you wouldn't have to remove the observer. If  
you're not using GC, you would.


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: IKSlideshow Question

2008-08-07 Thread j o a r



On Aug 5, 2008, at 5:37 PM, Robert McCullough wrote:

The IKSlideshowDataSource protocol for IKSlideshow includes several  
optional methods, one of which is "nameOfSlideshowItemAtIndex".  
However, this method NEVER seems to be called. Anyone know why?



I think that it's simply a bug - most likely a very well known bug.
You might still want to file a bug report to indicate interest in  
getting this API fixed for some future release.


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: Get specified window from nib

2008-08-11 Thread j o a r



On Aug 11, 2008, at 8:08 PM, Fosse wrote:


In fact, in my another application, there are more than one hundred
windows.. split them into one hundred nib? and create one hundred  
Outlet?


Seems a little too crazy!



Over a hundred different windows seems a little crazy too   ;-)

If you describe your application, and your use of nib files, it might  
be that we could provide some suggestions for cutting down on that  
number.


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: how to implement the auto-complement function like Xcode 3.x?

2008-08-13 Thread j o a r



On Aug 12, 2008, at 8:24 PM, Leopard x86 wrote:

Then here comes the question: how can we implement this function for  
our editor-like application?
Because I am working on an editor project which concerns about the  
user experience,  I think the auto-complement function is an  
indispensable one. Moreover, the Xcode-style of auto-implement is  
exactly what I want. This feature can improve the efficiency and  
productivity of users greatly.



Have a look at the NSTextView "- 
textView:completions:forPartialWordRange:indexOfSelectedItem:"  
delegate method.


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: @try @catch

2008-08-14 Thread j o a r



On Aug 14, 2008, at 5:34 PM, Andrew Farmer wrote:

Python has been optimized to handle exceptions quickly, so it's  
often faster to catch exceptions than to check for exceptional  
situations in Python code. Objective-C has not been similarly  
optimized*, so checking for errors before attempting operations will  
be much faster than catching exceptions unless the exceptions are  
exceedingly rare.


*: Or, more accurately, the overhead of setting up exceptions is  
much higher compared to the overhead of checking for situations that  
would trigger them.



The cost, and where you pay it, depends on many factors: The type of  
exceptions handler you use, and the version of Mac OS X and the  
version of the Objective C runtime you happen to execute on.


That said, and has been pointed out earlier in this thread, the  
decision to use exceptions for control flow or not is not simply one,  
perhaps not even primarily one, of performance considerations.


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: Clearing a Memory Buffer?

2008-08-18 Thread j o a r



On Aug 18, 2008, at 6:19 AM, Dave wrote:

I'm fairly new to Cocoa and was wondering if there are OS functions  
to Copy and Clear/Fill Memory available?



In addition to the lower level C API:s that have been mentioned so  
far, there is also the object oriented Cocoa NSData + NSMutableData  
API:s that might provide some / all of what you're looking for.


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: Question about respondsToSelector

2008-08-18 Thread j o a r



On Aug 18, 2008, at 11:17 AM, Carmen Cerino Jr. wrote:

Does the id type have enough information for the respondsToSelector  
method to work. I have a class with an ivar of type id, and when I  
invoke the respondsToSelector method it fails when it should  
succeed. I am assuming it should work fine, because if I skip  
checking with the respondsToSelector method and just make the call,  
it executes the method. Can someone please tell me what I am doing  
wrong?



Perhaps you've misspelled the name of the selector - just like you've  
done above with "respondsToSelector:" (note the trailing ":").


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: passing an object between views

2008-08-19 Thread j o a r



On Aug 19, 2008, at 5:31 PM, John Greene wrote:


Hopefully this is a generic enough question that it applies to general
Cocoa development:  How do I pass an object between views?  That is: I
have an array of objects that I've built using NSXMLParser, and that
populates a table, and clicking on a cell changes my view to another
table with a separate controller.  I had originally thought that I  
could

just write a method, setTableData in the secondary controller, that
takes an object as an argument, and then use that object to build the
secondary table.  This is apparently forbidden by the language, so
what's the proper approach?  I could make the array available  
somehow to
the new controller, since I can pass the integer index, but I'm not  
sure

how!



It sounds like you might be trying to implement a Master-Detail  
Interface. Possibly.


If so, you might have a look at this:

	<http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaBindings/Tasks/masterdetail.html 
>


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: !foo vs foo == nil

2008-08-20 Thread j o a r



On Aug 20, 2008, at 4:56 PM, John C. Randolph wrote:

Personally, I prefer "if (!foo)" over "if (foo == nil)", because the  
latter has the hazard of a typo that compiles.  You can lose a fair  
bit of time staring at "if (foo = nil)" before you spot the mistake.



There is a GCC warning to help you with that, but in addition, you can  
learn to type:


if (nil == foo)

Problem solved!   :-)

I personally much prefer to have if-statements that clearly evaluate  
to a boolean value. More intention revealing, and to me that's more  
important than being terse.


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: NSWindowController, owner, "primary window"...

2008-08-21 Thread j o a r



On Aug 21, 2008, at 10:12 AM, Negm-Awad Amin wrote:

Probably because the GoF prefers combination over (?) subclassing.  
Subclassing always discloses parts of the implementation of a class.  
("white-boxing") So generally it is a good idea, to look for  
alternatives for subclassing, esp. delegates.



You are right in that Cocoa programmers often look to other design  
patterns before choosing to subclass one of the framework provided  
classes. That said, NSWindowController is one of the classes in Cocoa  
designed and intended to be subclassed, so that's not a consideration  
in this particular case.


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: Undocumented Leopard support for overlapping sibling views

2008-08-28 Thread j o a r



On Aug 28, 2008, at 1:28 PM, Nathan Vander Wilt wrote:

According to two list postings (http://lists.apple.com/archives/cocoa-dev/2007/Nov/msg01760.html,http://lists.apple.com/archives/cocoa-dev/2007/Nov/msg01764.html 
) both by Apple employees, overlapping sibling subviews are fully  
supported in Leopard (and presumably beyond).


However, the official documentation (http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaViewsGuide/WorkingWithAViewHierarchy/chapter_5_section_5.html 
) still says:
"Cocoa does not enforce clipping among sibling views or guarantee  
correct invalidation and drawing behavior when sibling views  
overlap. If you want a view to be drawn in front of another view,  
you should make the front view a subview (or descendant) of the rear  
view."


And Interface Builder 3.1 on the one hand has options like "Layout >  
Send to Front" that change the ordering of subviews, yet on the  
other still warns about "Illegal geometry" when a view overlaps one  
of its siblings even when the deployment target is set to 10.5.



I can't find anything in the documentation (or even release notes)  
that describes that/how overlapping views are supported. Why isn't  
this documented? Can we rely on overlapping sibling views working  
now and in the future? Are there any caveats we should be aware of?



Hello,

Please file a couple of bug reports on this:

<http://developer.apple.com/bugreporter/>

Thanks!

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: What to use observeValueForKeyPath: context

2008-08-29 Thread j o a r



On Aug 29, 2008, at 9:56 AM, Michael Ash wrote:


It really just needs to be unique in your class hierarchy, right?


True, but not particularly useful. Your class hierarchy includes
NSObject, which is free to observe whatever it feels like in your
objects.



No this is not generally true, so just forget about that and instead  
ensure that the context pointers are globally unique.




If you use a constant string, you should make sure that the
string *contents* are unique, in order to ensure uniqueness of the
pointer to it. So don't call it @"context", use @"MyFunkyClass KVO
observer context". After all there's no penalty for being verbose in
this case. Of course using a pointer to a global solves this too.



The penalty for using constant strings is that they will end up  
wasting space in your binary...

Rons suggestion is probably optimal.


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: Creating movie on background thread

2008-09-02 Thread j o a r



On Sep 2, 2008, at 12:55 AM, Roger Herikstad wrote:


Since the Carbon stuff is not 64 bit



Not correct: Some of it is, some of it isn't. Read the API reference  
documentation and release notes to figure out which is what. Besides,  
QTKit is a Cocoa framework.


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: Creating movie on background thread

2008-09-02 Thread j o a r



On Sep 2, 2008, at 1:14 AM, Roger Herikstad wrote:

But I do need the Carbon headers to use the functions  
AttachMovieToCurrentThread, DetachMovieFromCurrentThread, etc, no?



It doesn't seem like that's the case:

"With Mac OS X 10.5 and QuickTime 7.3 or later installed, QTKit  
provides the framework level support that is required to use QTKit  
objects on background threads. This includes the ability to tell QTKit  
when you want to use a QTMovie instance on a background thread, when  
you're attaching or detaching a QTMovie instance from the current  
thread and also allows control of the QTMovie idle state."


<http://developer.apple.com/technotes/tn/tn2125.html>

I'm not an expert on this - you might want to consult a QT specific  
mailing list for a definitive answer.


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: NSDate autorelease problem

2008-09-03 Thread j o a r



On Sep 3, 2008, at 10:02 AM, [EMAIL PROTECTED] wrote:

I'm trying to calculate the elapsed time by calling this twice and  
getting the difference.


double Seconds()
{
  return [[NSDate date] timeIntervalSince1970];
}



How about replacing that with:

return [NSDate timeIntervalSinceReferenceDate];

That said, I would bet that there are simple C APIs that would be more  
efficient to use for this purpose.



This is being called from an audio play back proc which is being  
called about 100 times a second.  I'm getting this error message in  
the log window a whole bunch of times.


2008-09-03 09:39:30.766 App[321] *** _NSAutoreleaseNoPool(): Object  
0x36acd0 of class NSCFDate autoreleased with no pool in place - just  
leaking



The reason is that you're executing the code above on a non-main  
thread. See the documentation for NSAutoReleasePool for details (or  
just use Google), but in general:


"Cocoa expects there to be an autorelease pool always available. If a  
pool is not available, autoreleased objects do not get released and  
you leak memory. NSAutoreleasePool objects are automatically created  
and destroyed in the main thread of applications based on the  
Application Kit, so your code normally does not have to deal with them."


On threads that you set up, you have to manage the top level  
autorelease pool manually.



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: when should my NSWindowController be released?

2008-09-13 Thread j o a r



On Sep 13, 2008, at 1:43 PM, Markus Spoettl wrote:

Not true, I can think of many scenarios where you have no other  
choice.



Like what? Seth is right in general, app termination is very much a  
special case.


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: NSUInteger in for-loop?

2008-09-14 Thread j o a r



On Sep 14, 2008, at 9:15 PM, Alex Reynolds wrote:

I'm wondering if I'm using unsigned integers (specifically  
NSUInteger) properly or not.


I was under the impression that unsigned integers run from 0 to  
MAX_INT, but when I use them in a "for" loop within these bounds,  
the loop does not seem to always obey these constraints.


For example:

for (NSUInteger counter = 5; counter >= 0; --counter)
{
NSLog(@"NSUInteger: %d", counter);
}

keeps running well after the "counter" variable turns negative:



NSUInteger runs from 0 -> NSUIntegerMax.

This is how you print a NSUInteger:

NSLog(@"NSUInteger: %lu", ((unsigned long)counter));

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: How to create a new window initially zoomed to the maximal size?

2008-09-20 Thread j o a r



On Sep 20, 2008, at 11:02 AM, Oleg Krupnov wrote:


What I want to achieve is that when a new window is created, it has
the maximal size allowed by the screen, menu and the dock, exactly
like if someone clicked the green zoom button in the window's title
bar. I don't want any resizing animation or flickering though.



You would have to resize the window manually. To find out how to size  
and position it, ask NSScreen for the appropriate frame. To avoid  
flickering, do this in "awakeFromNib" or similar, before the window is  
put on screen.


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: How to create a new window initially zoomed to the maximal size?

2008-09-20 Thread j o a r



On Sep 20, 2008, at 11:11 AM, Benjamin Stiglitz wrote:

Alternatively, you can set its frame to [[window screen]  
defaultFrame], which is the same frame

that -zoom: will use, subtracting space for any visible drawers.



I think that should be:

"-[NSScreen visibleFrame]"

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: unrecognized selector sent to instance



On Sep 25, 2008, at 4:01 AM, pan xuan wrote:

Hi, I am having a strange problem of my class declaration. I used to  
declare some methods of a class in a category, "Private". After I  
have done some refactoring work (basically moving some classes into  
another framework), it seems those methods declared in the category,  
"Private" do not belong to the object anymore. If I load the code in  
my debugger and try to invoke a method declared as "Private", the  
program receives a doesNotRecognizeSelector error and crashes after  
receiving the signal SIGTRAP. And if I move those methods into the  
main implementation of the class, it all works out. Any idea why is  
that? Thanks for your help. BR, Pan



Perhaps a memory management error somewhere? Try to run your app with  
NSZombieEnabled (Google for the details) and see what that turns up.


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: [NSCFNumber intValue]: unrecognized selector



On Sep 25, 2008, at 6:22 AM, Steve Rossi wrote:

I've deduced that he crash seems to be something timing related  
which occurs only at application startup, and only under certain  
conditions (i.e. reproduce occassionlly by opening an NSOpenPanel  
modal dialog before the application is fully up and running). When I  
say the application is fully up and running, I mean a secondary  
thread has retrieved data from a network source and populated a  
model class. This secondary thread cyclically updates the data about  
8x per second by means of a timer in the secondary thread's run loop.
I use Cocoa bindings to display the data in the UI. I'm sure the  
problem is happening in the bindings, but I'm having trouble finding  
where.



In the general case, and with few exceptions, you can't call your UI  
on non-main threads. This means that you can't drive UI updates based  
on KVO notifications from non-main threads. Could this be your problem?


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: sending email with attachement from cocoa



On Sep 26, 2008, at 10:03 AM, Alexander Cohen wrote:

Is there a way to use a url request to open mail with all its fields  
completed but most importantly, contain an image attachement?



Not using the frameworks provided by Apple.

Your problem, in particular, is that you can't assume that all users  
are running the same email client.


There are some third party attempts at solving this problem -> Google.

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: [NSCFNumber intValue]: unrecognized selector



On Sep 26, 2008, at 4:36 PM, Steve Rossi wrote:

Yes, that is correct. A separate thread is spawned which updates the  
model - consequently driving UI updates based on KVO notifications.
It is the only thread that is updating the model - the main thread  
does very little except respond to fairly minimal UI events.
It works very reliably it seems ... except on these occassions when  
the OpenPanel is opened from the main thread.



That might appear to be the case on your machine, on this version of  
your application, and on this version of Mac OS X - But as soon as you  
change any of these variables, it might well start to fall apart.



I can think through whether I really need that separate thread. But  
is there a way to make the model updates from the 2nd thread safe?



If you're doing blocking work, having it on a separate thread is  
probably a good thing - But you need to forward your UI updates to the  
main thread. That's typically easy to do using  
"performSelectorOnMainThread:"



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: large documents with doc based app

2008-03-05 Thread j o a r



On Mar 6, 2008, at 12:19 AM, Torsten Curdt wrote:


But according to the docs NSData is limited to 2GB.
What I am wondering is... How can one handle files larger than 2GB?



Override the path / URL based methods from NSDocument instead, and  
read the interesting portions of the files piece-by-piece. You  
typically don't want to load all of it into RAM at once.


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: Deferring a selector until later, but before painting

2008-03-05 Thread j o a r



On Mar 6, 2008, at 2:12 AM, John Stiles wrote:

Right now in my app, there are some controls which appear and then  
their state changes a fraction of a second later, and I'd like to  
avoid the visually jarring "pop" effect of a control which changes  
itself right after first appearing, but I can't find an easy way to  
avoid deferring some operations.



How about delaying adding the control until the value you want to  
display in the control is "ready"?


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: Deferring a selector until later, but before painting

2008-03-06 Thread j o a r



On Mar 6, 2008, at 8:32 AM, Ken Ferry wrote:


Or can you do your final setup in -viewWillDraw?

For some kinds of problems, you could synchronously mark whatever  
state you're interested as invalid, then resolve any invalidated  
state in -viewWillDraw.  This would be an appropriate way to do  
deferred layout, for example.



I think it's unfortunate to have to resolve to subclassing for this  
type of problem - The OP might end up having to subclass several  
different NSControl subclasses to make it work. Perhaps NSView should  
provide some sort of notification or delegation scheme to supplement  
this method?


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: How to set Document Icon when saving

2008-03-06 Thread j o a r

On Mar 6, 2008, at 4:23 PM, Lincoln Green wrote:

How do you set the document icon?

Typically you don't. The Finder will query Launch Services and  
automatically associate your documents with the correct icon based on  
the information found in your applications property list - And also  
based on user preferences, in the case of a shared document type with  
multiple possible applications to choose from.

See for example:

<http://developer.apple.com/documentation/Cocoa/Conceptual/Documents/Concepts/DocTypePList.html#//apple_ref/doc/uid/2024-BHADAGHF 
>

<http://developer.apple.com/documentation/Cocoa/Conceptual/Documents/Tasks/ImplementingDocApp.html 
>

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: NSTableView + delete button?

2008-03-11 Thread j o a r



On Mar 11, 2008, at 3:03 PM, Kevin Dixon wrote:

I'm using an NSTableView, and I want to be able to remove items from  
the
list by pressing the delete key on the keyboard. What is the  
procedure to

receive a message when a key is pressed and the table view has focus?



Subclass NSTableView and override "-keyDown:". There should be several  
implementations of this online that you could take a look at.


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: warning: assignment from distinct Objective-C type

2008-03-11 Thread j o a r



On Mar 11, 2008, at 3:49 PM, Quincey Morris wrote:

Personally I prefer the factory method approach, a la [NSArray  
array] etc:



Note that factory class methods typically also return id for the same  
reason that init methods return id (NSArray, NSString, et.c.).


This in contrast to shared instances that are strongly typed  
(NSFileManager, NSHost, NSNull, et.c.).


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: NSTableView + delete button?

2008-03-11 Thread j o a r



On Mar 11, 2008, at 5:47 PM, Kevin Dixon wrote:






to catch the pressing of delete on the NSTableView. This works, but
reminds me of BASIC...Is there a better way to do this, to make sure  
I'm

getting the delete key, say even on international keyboards?



See "NSDeleteCharacter" and similar in NSText.h (and in the  
documentation).


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: XCode3 errors on startup

2008-03-18 Thread j o a r



On Mar 18, 2008, at 10:29 AM, Steve Cronin wrote:

When I start XCode3 in Leopard I am seeing the following in  
Console.app.

Any ideas on what is going on?



This question belongs, and has been answered, on Xcode-Users:

<http://www.cocoabuilder.com/archive/message/xcode/2007/11/7/16930>

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: Getting notifications when any file in a folder change

2008-03-18 Thread j o a r

On Mar 18, 2008, at 11:07 AM, Mr. Gecko wrote:

Hello I am wondering how to get my program to notice when a file  
changes in a folder.

See:

<http://developer.apple.com/documentation/Darwin/Conceptual/FSEvents_ProgGuide/ 
>
<http://developer.apple.com/documentation/Darwin/Reference/FSEvents_Ref/FSEvents/index.html 
>

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: Intercepting retain/release of object

2008-03-21 Thread j o a r



On Mar 21, 2008, at 11:13 AM, Scott Ribe wrote:
If you really want to understand what's going on, forget the counts,  
set
breakpoints on your overloaded retain & release methods, then look  
at the
stack trace every time. It may take a while, because there may be a  
lot
going on behind the scenes, but it's one way to get an  
understanding. (Also

add an override for autorelease.)



A much, much, better way of doing that would be to use the Object  
Allocations instrument.


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: How do I disable this warning: "local declaration of 'varname' hides instance variable"

2008-03-23 Thread j o a r


Chuck,

* You really shouldn't suppress these warnings

* If you use ObjC 2.0 properties you don't have to write those  
accessors in the first place, and


* If you use ObjC 2.0 properties, you can use this form without  
warnings:


self.foo = foo;

j o a r


On Mar 23, 2008, at 8:59 PM, charlie wrote:


For years, I've been doing this:

- (void)setController:(id)_controller
{
if (!_controller)
{
  return;
}
controller = [_controller retain];
}



It has always irked me having to work around namespace conflicts  
between method args and instance variables.


So, today I decided to try this for my next project...

- (void)setController:(id)controller
{
if (!controller)
{
  return;
}
self->controller = [controller retain];
}



I works fine.  But does not fix the warning itself.




So, the question stands How do I suppress the warning.


- Chuck


___

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 to delay application quit?

2008-03-25 Thread j o a r



On Mar 25, 2008, at 9:26 AM, James Hober wrote:

Do you write the dealloc anyway?  Just wondering what others do.   
Personally I still write a dealloc method in a class for an object  
that I keep around for the life of the app.  Then I preface it with  
a self-amusing comment:


//actually this dealloc never gets called - the app just  
relinquishes all memory upon quitting.

//But just to keep things tidy...

I suppose this is utter superstition on my part.  Yet somehow I feel  
better that there are matching releases, etc. that never get called.


And of course, if the class were ever used not solely for a single  
object that lingers for the life of the app but for objects that  
come and go, then the proper memory management is in place.



I wouldn't recommend doing that. I'd suggest using something like this:

- (void) dealloc
{
NSAssert(FALSE, @"Singleton objects should never be released");
[super dealloc];
}

This communicates better what your intention is, and also catches the  
unlikely case of this instance ever being deallocated when it  
shouldn't, or if the class is being repurposed to a multi-instance  
pattern.


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: How to delay application quit?

2008-03-25 Thread j o a r



On Mar 25, 2008, at 3:19 PM, James Hober wrote:


On the other hand, the documentation for dealloc says:

"Note that when an application terminates, objects may not be sent a  
dealloc message since the process’s memory is automatically cleared  
on exit—it is more efficient simply to allow the operating system to  
clean up resources than to invoke all the memory management methods."


Since it says "may," theoretically it could be considered an  
implementation detail that dealloc is not called during termination  
and Apple could change things in a future release.  Admittedly, this  
is not very likely and admittedly worrying about code that almost  
certainly will never execute is probably not the best use of time.   
And yet it is very common to have a number of singleton objects of  
this kind in Cocoa apps.  So nearly all of us are "solving" this one  
way or another.



That's a valid argument, but I feel pretty confident that Apple  
wouldn't be able to make such a chance for existing binaries without  
creating havoc in the installed application base.


If they do change this, I would expect them to communicate it first,  
and then only actually update the behaviour for apps compiled on a  
newer version of the OS.


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: Main Thread UI and Detached Thread



On Mar 30, 2008, at 11:55 AM, Mike wrote:
In my worker thread I do a tight processing loop and one of the  
things I do in the loop is call two methods in the main thread to  
update the display (a text message and progress bar) - via  
performSelectorOnMainThread:withObject:waitUntilDone:modes.


However, when the loop runs in the spawned thread, the display  
doesn't get updated. If I insert a sleep(1) call into the loop, then  
the display  updates.



How much work do you perform on the main thread? If a lot, it's not  
unexpected that you would se interruptions in display updates. You  
might need to throttle or otherwise limit your callouts to the main  
thread if this proves to be the problem.


You can use Instruments or Shark to get a view of the work being  
performed on the main thread while you run your worker thread.


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: Main Thread UI and Detached Thread



On Mar 31, 2008, at 11:02 AM, Mike wrote:
I'm not doing any work on the main thread while the spawned thread  
runs. In fact, the main thread is just idling doing nothing. And the  
behavior isn't really a responsiveness issue: the rest of the UI  
still responds fine, but my indicators that I update in the UI do  
*nothing* the entire time the spawned thread is running. Nothing. No  
activity. If I take the sleep calls out, then main thread updates  
the UI instantly upon termination of the spawned thread.



You said that you're calling the main thread, so I expect it to do  
*something*...


How do you notify the controls in the UI that they need to update to  
reflect new values?

What is the total time required to run the task by your worker thread?

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: Main Thread UI and Detached Thread



On Mar 31, 2008, at 12:20 PM, Mike wrote:
I have two methods in the main thread that I call from the worker  
using performSelector, etc. The method for updating the progress bar  
for example looks like this:


- (void)setProgressBarValue:(double)value
{
if( progressBar )
{
[ progressBar setDoubleValue:value ];

[ progressBar setNeedsDisplay:YES ];

[ progressBar display ];
}
}



Your calls to "-setNeedsDisplay:" and "-display" are basically  
mutually exclusive. You should typically not call "-display" directly.



This is a pretty simple app and I don't have time to dive into  
performance tools to discover why a single thread in a 10-page app  
isn't doing what it's advertised to do.



I don't think you're saving any time by not learning how to use the  
performance tools.



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: Main Thread UI and Detached Thread