Re: NSCell subclassing nightmares

[Kyle Sluder]

On Sun, Jun 28, 2009 at 8:10 PM, Chase Meadors wrote:
> Well, in the montage of problems that arose from this, I found out more
> about how cells work, but I'm still confused. It took me forever to discover
> that the weird problems with bindings I was experiencing stemmed from the
> fact that there is ONE cell for a table column, that it uses to draw all its
> data.

You might want to view my movie on this:
http://www.cs.loyola.edu/~ksluder/NSCell.mov

--Kyle Sluder
___

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

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

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

This email sent to arch...@mail-archive.com

Re: Objective C Compiler Settings

[Gerriet M. Denkmann]

On 29 Jun 2009, at 07:10, Graham Cox  wrote:




On 29/06/2009, at 9:18 AM, Michael Ash wrote:


On Sun, Jun 28, 2009 at 4:12 PM, Tommy Nordgren
wrote:
Are there any compiler flags you can provide when compiling
Objective C
code,
that causes an exception to be triggered when a category implements
a method
that is already implemented in the target class?


Not an exception, but you can get the runtime to log any replaced
methods by setting the OBJC_PRINT_REPLACED_METHODS environment
variable when running your app. This and other environment variables
can be found by running an ObjC program with the OBJC_HELP enviroment
variable set. This will print out a brief bit of documentation about
all the debugging variables supported by the runtime.



Cool, that's really useful and previously unknown to me - where did
you get to know about this? Can you point to documentation?


>


Kind regards,

Gerriet.

___

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 arch...@mail-archive.com

Re: Tool-tips on NSTabViewItem

[Andrew Farmer]

On 26 Jun 2009, at 08:01, PKameo wrote:
How do you add a tool-tip to a NSTabViewItem? I tried the following,  
but

that didn't work right.
[[tabViewItem view] setToolTip:toolTip];
//Where tabViewItem is of type NSTabViewItem* and toolTip is of type
NSString*


[tabViewItem view] returns the content view of the tab (i.e, what gets  
displayed when the tab is selected), not a view representing the tab  
itself.


Tab view items don't support attributed labels, so I suspect there  
isn't any easy way of accomplishing this task. If you really need it,  
you can probably subclass NSTabView and do something awful with mouse- 
moved events and/or tracking rects. However, given as how there aren't  
any other applications out there where NSTabViews have tooltips, I  
wouldn't sweat it.

___

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 arch...@mail-archive.com

Re: NSCell subclassing nightmares

[Graham Cox]

On 29/06/2009, at 1:10 PM, Chase Meadors wrote:

Well, in the montage of problems that arose from this, I found out  
more about how cells work, but I'm still confused. It took me  
forever to discover that the weird problems with bindings I was  
experiencing stemmed from the fact that there is ONE cell for a  
table column, that it uses to draw all its data.

[]


In short, a value change that should affect one cell affects all of  
them. Some magic is happening in Apple's cell classes that makes  
values affect only the intended cell. Sorry if I'm missing something  
obvious here... but I'm completely stumped.



Well, you discovered that a table column has but one cell. That's the  
key to this problem - a cell used by a table view can't have any  
persistent internal state (like an animation frame count for example)  
because it is continually being re-used.


The "magic" you're referring to is that the table fetches the data for  
the cell on the fly every time - it doesn't store it anywhere, so it  
can re-use the cell.


You can return a specific cell for each row using -dataCellForRow: but  
you have to manage it properly. Just alloc/initing one every time  
isn't good enough (who is going to release these cells?) - you'd have  
to maintain a list of cells in your controller, one for each row, and  
return the appropriate one each time if you need its internal state to  
last across calls to the table view. I doubt that "infinite" cells are  
being created, but it certainly could be a very large number, all of  
which seem to be leaking.


Or just give up and do things in the standard way - sometimes certain  
"cool" effects are simply not worth the trouble. ;-) Custom cells can  
be very hard work, especially in table views.


--Graham


___

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

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

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

This email sent to arch...@mail-archive.com

Re: Dispose pattern (was: Re: GC pros and cons)

[Stephen J. Butler]

On Sun, Jun 28, 2009 at 10:50 AM, Konrad Neitzel wrote:
> But a garbage collector must be able to detect an object which memory can / 
> must be released. And for all this, the system has to do some work.
>
> I still have to read much more about the GC used within Objective-C / Cocoa 
> so I am not sure, if I am not writing some kind of "bullshit" from your view:
>
> Isn't it possible to simply flag an object to be removed? Is there a dispose 
> pattern in Objective-C?
> (e.g. http://www.codeproject.com/KB/cs/idisposable.aspx describes such a 
> pattern in C#)
>
> Something like that would simply more the world together again. That way, the 
> developer has some more control, the GC has less work and all are maybe happy?
>
> So is there such an Dispose Pattern in Objective-C using a GC or is there 
> nothing like that?

That article does not say what you think it says. Dispose() does not
"flag an object to be removed". It is also not normally the place to
start setting all your instance variables to null. In fact, the only
thing it has to say about what you're asserting is this:

"You should also consider setting any large and expensive managed
objects that you own to null before calling Dispose. This is seldom
necessary, but it can help reduce the lifetime of the object by making
it eligible for garbage collection sooner. Of course, the definition
of large and expensive is subjective, and should be based on
performance profiling and measurement.

If you are creating a value type, you should avoid making it
disposable, and it should never contain unmanaged resources directly."

So, according to your own evidence, the effort put forth to null
instance variables should only be done when performance profiling and
measurement warrants it. Otherwise, it's simply doesn't have a
benefit. And in classes that don't wrap unmanaged resources, you
shouldn't write a Dispose() at all!

Everything else in that article about setting instance variables to
null has to do with breaking Dispose() loops when calling Dispose() on
owned objects. NOT because it makes them collectable faster, or easier
to collect.

Again, Dispose() is only for handling UNMANAGED resources, stuff the
GC doesn't know how to collect or can't collect. And if you want a
Dispose() like handling in Objective-C (just like Java), write a
"close" message and document that it should be called when the user is
done with the object. It gives you just as much benefit as Dispose()
does in C#.

I also challenge your assertion that a bunch of disconnected objects
are easier to collect than an entire graph of connected objects.
Without looking at the actual GC code, I could make an argument either
way. It would be entirely up to the implementation over which gives a
benefit, and GC implementations change all the time.

I have no idea why so many people are hell bent on circumventing the
GC. The biggest reason to use it is because then you don't have to
worry about managing your memory anymore. Yet here you all are,
inventing bogus ways to once again manage the memory! If you can't let
go and allow the system to do its thing, then don't use GC.
___

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 arch...@mail-archive.com

Re: NSCell subclassing nightmares

[Quincey Morris]

On Jun 28, 2009, at 20:10, Chase Meadors wrote:

I'm making a custom cell that will 'animate' in a sense. Each of  
these cells holds an NSTimer. The object value sets a bool that  
determines whether the code inside the timer's method is executed or  
not. The code in this method simply increments a value and requests  
the table view to redraw. So the object value effectively starts and  
stops the animation.


Well, in the montage of problems that arose from this, I found out  
more about how cells work, but I'm still confused. It took me  
forever to discover that the weird problems with bindings I was  
experiencing stemmed from the fact that there is ONE cell for a  
table column, that it uses to draw all its data.


Through google, I read about implementing -copyWithZone:, but  
breakpoints in this method never get called...


I tried overriding table column's -dataCellForRow: and returning a  
new cell [[MyCell alloc] init]. This, however, apparently causes  
infinite cells to be allocated, and a crash happens.


No, that's the wrong approach. You want to create *one* cell for each  
animation, the first time it's appropriate in dataCellForRow. After  
creating it, you must associate the cell with the row that it belongs  
to, through some scheme you invent (like a NSMutableDictionary with  
suitable keys) so that the next time you're asked for the cell at  
dataCellForRow you can return the *same* cell. When the animation is  
complete, you need to arrange for the cell to be disposed of.



___

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 arch...@mail-archive.com

Re: NSImageView/NSImage question

[Graham Cox]

On 28/06/2009, at 5:36 PM, Marco S Hyman wrote:


I'd like to get the path of the file containing the data used to
create an NSImage when that images is dragged onto an NSImageView.
I think I stated that correctly.  Is it possible?   If so a pointer
to the appropriate doc would be appreciated.

Looking through the doc it seems that an image will retain its
path with -setDataRetained if initialized using – 
initByReferencingFile:

but even then I see no way to get the path.



That's right - you can't. Once data is in the form of an NSImage its  
original path isn't available, regardless of whether the image retains  
the data or not. It's probably in there somewhere but there's no  
public API (please file a bug requesting one, it would help me also!).


You need to go back a step and intercept the drag at an earlier stage  
when it's still just a filename or file promise (whatever the Finder  
sends, I can't remember).


--Graham


___

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

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

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

This email sent to arch...@mail-archive.com

Re: Intersection of CGPath and CGRect

[Graham Cox]

On 28/06/2009, at 4:43 AM, Martin Hewitson wrote:

Does anyone know a good way to test if a CGPathRef intersects a  
CGRect at any point?



This can be a hard problem.

First, naturally discard the trivial case of the bounding rect of the  
path not intersecting the rect you're testing. The further approach  
you take will probably best be dictated by what you're trying to  
actually do.


If the purpose is to simply test whether a rect has hit a path, for  
hit-testing purposes, I've found one of the fastest general methods is  
to render the path into a 1 x 1 bitmap context with only an alpha  
channel. Using the rect for hit-testing against as a source rect, the  
portion of the path bounding rect that intersects that is scaled down  
using a suitable transform into the bitmap. If the outcome is some non- 
transparent alpha value, you got a hit, otherwise, you didn't.  
Somewhat surprisingly, I found this technique faster than any other I  
tried and very nice for hit-testing, as it takes into account what was  
actually rendered - strokes, fills, alpha and anti-aliasing. (Thanks  
due here to Ken Ferry who first suggested this approach to me).


If on the other hand you actually need to find the points at which the  
rect intersects the path, you'll need a very different approach. In  
this case testing a line segment against the path can be done, so  
you'd need to break the rect down into four line segments then test  
each one. It's hard to quickly find the intersection of a line segment  
with an arbitrary bezier curve, but somewhat easier if the curve is  
first flattened so you're just testing line segments against other  
line segments. It can still be an expensive operation though - it's  
well worth breaking a path down into its elements and first finding  
the bounding rects of each element, and trivially eliminating all  
those that don't intersect, then doing the more brute-force  
intersection test on what remains.


DrawKit ( http://apptree.net/drawkitmain.htm ) contains code for doing  
both kinds of testing - feel free to use what's there.


--Graham


___

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

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

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

This email sent to arch...@mail-archive.com

Re: NSTableView -setDataCell confusion

[Quincey Morris]

On Jun 27, 2009, at 13:18, Chase Meadors wrote:

I'm using AMIndeterminateProgressIndicatorCell (at least the drawing  
code) to imitate a progress indicator in the table view. To get it  
to use the custom cell, I've been calling


[myTableColumn setDataCell:[[MyCustomClass alloc] init]];

However, I've run into a 'slight' problem. Apparently, ALL of the  
cells in this column are that one, same, object. When I tested with  
F-script, I found that they have the exact same description, and  
same memory address. This explains why bindings affecting one cell  
would affect all of them...


So, in short, is there a +setCellClass method or similar for  
NSTableColumn? Any way to make it use different objects?


You can use the table view delegate method:

tableView:dataCellForTableColumn:row:

to implement different cells for different rows.


___

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 arch...@mail-archive.com

Re: Force NSTextField to update (and transform)

[mmalc Crawford]

On Jun 26, 2009, at 5:37 AM, Michał Glenc wrote:

I'm a beginner in Cocoa world and I have some problems with  
bindings, NSValueTransformer etc.


Cocoa bindings is not a beginner technology.  You are encouraged to  
gain some experience with Cocoa before using bindings.


My application performs basic currency transforming. I have two  
NSComboBoxes (where I change currency) and two NSTextFields.  
Everything works fine, the values get transformed. However, when I  
change currency in one of ComboBoxes (after values in TextField have  
been already entered), value in TextField stays unchanged. What I  
want to achieve is to send the TextField (or perhaps the  
NSValueTransformer) a message that it's value has been changed (so  
that it retransforms) when the currency in ComboBox is changed.  
Could you advise me something?


What value is the combo box changing?  If it is simply changing a  
value that the value transformer uses, then this will not effect a  
change in the text fields.  The text fields will only update if the  
model value they represent -- or a value upon which the model value  
depends -- is updated.


(I may be missing something obvious here, but offhand...) If you had a  
controller object that manages the values in the text field and the  
exchange rate, then you could make the converted amount dependent on  
the values of the source amount and the exchange rate -- you probably  
wouldn't need a value transformer, though.


mmalc

___

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 arch...@mail-archive.com

[MEET] July CocoaHeads Mac Developer Meetings

[Stephen Zyszkiewicz]

Greetings,

CocoaHeads is an international Mac programmer's group. Meetings are  
free and open to the public. We specialize in Cocoa, but everything  
Mac programming related is welcome.


Upcoming meetings:
Australia
Brisbane- Wednesday, July 15, 2009 19:00.

Canada
Toronto- Tuesday, July 14, 2009 18:30.

Germany
Berlin- Thursday, July 9, 2009 19:00.

Poland
Warsaw- Friday, July 10, 2009 19:00.

South Africa
Johannesburg- Thursday, July 9, 2009 18:30.

United States
Ann Arbor- Thursday, July 9, 2009 19:00.
Atlanta- Thursday, July 9, 2009 19:00.
Boston- Thursday, July 9, 2009.
Boulder- Tuesday, July 14, 2009 19:00.
Chicago- Tuesday, July 14, 2009 19:00.
Colorado Springs- Thursday, July 9, 2009 19:00.
Dallas- Thursday, July 9, 2009 19:00.
Denver- Tuesday, July 14, 2009 19:00.
Des Monies- Thursday, July 9, 2009 19:00.
Lake Forest- Wednesday, July 8, 2009 19:00.
Nashville- Thursday, July 9, 2009 19:00.
Philadelphia- Thursday, July 9, 2009 19:00.
St. Louis- Saturday, July 25, 2009 14:00.
Upper Connecticut River Valley- Thursday, July 9, 2009 19:00.

United Kingdom
Swindon- Monday, July 6, 2009 20:00.


Some chapters may have yet to post their meeting for next month.  
Meeting times may change. Locations and more information here:

http://cocoaheads.org

Also be sure to check for an NSCoder Night in your area:
http://nscodernight.com/


Steve
Silicon Valley CocoaHeads
___

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 arch...@mail-archive.com

NSCell subclassing nightmares

[Chase Meadors]

I never dreamed such a task could cause such difficulty!

I'm making a custom cell that will 'animate' in a sense. Each of these  
cells holds an NSTimer. The object value sets a bool that determines  
whether the code inside the timer's method is executed or not. The  
code in this method simply increments a value and requests the table  
view to redraw. So the object value effectively starts and stops the  
animation.


Well, in the montage of problems that arose from this, I found out  
more about how cells work, but I'm still confused. It took me forever  
to discover that the weird problems with bindings I was experiencing  
stemmed from the fact that there is ONE cell for a table column, that  
it uses to draw all its data.


Through google, I read about implementing -copyWithZone:, but  
breakpoints in this method never get called...


I tried overriding table column's -dataCellForRow: and returning a new  
cell [[MyCell alloc] init]. This, however, apparently causes infinite  
cells to be allocated, and a crash happens.


In short, a value change that should affect one cell affects all of  
them. Some magic is happening in Apple's cell classes that makes  
values affect only the intended cell. Sorry if I'm missing something  
obvious here... but I'm completely stumped.

___

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 arch...@mail-archive.com

NSRuleEditor

[Loukas Kalenderidis]

There's no sample code for NSRuleEditor, right? Or am I missing  
something?


I saw someone ask this on a list last year and the answer was "no, but  
I've got a sample I can send you" - does anyone have anything they're  
willing to share? I remember seeing in the "companion guides" section  
of the NSRuleEditor class reference a reference to a guide that  
sounded actually relevant but it wasn't actually linked, and has  
disappeared since updating my documentation. Bummer.


Loukas
___

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 arch...@mail-archive.com

Re: Dispose patern (was: Re: GC pros and cons)

[Konrad Neitzel]

Thomas Davie  schrieb am 28.06.2009 18:07:04:
> On 28 Jun 2009, at 17:47, Konrad Neitzel wrote:

> > But a garbage collector must be able to detect an object which  
> > memory can / must be released. And for all this, the system has to  
> > do some work.

> As must your program do if it keeps track of memory manually.  Are you  
> betting you can make that less work than a bunch of compiler engineers  
> can?  Note, this actually isn't a bad bet with GC, but it's not a good  
> one either.

But I simply know the business logic and the logic of my program. And often it 
is simply a series of:
- Create object
- Use it a little
- Dispose object

And C# has even create something just for this:
using (SomeClass someObject = new SomeClass())
{
   // Do something with the object ...
}

(It is simply using creating some kind of try finally with a Dispose Call 
inside the finally if I am right.)

So there is simply no need for any complex logic. Of course a Garbage collector 
can do a lot of nice stuff up to some graphs stuff to detect some Objects that 
simply reference each other but no thread can ever reach them.

And what is also important: The Dispose is not freeing memory. But the Objects 
are simply ready for destruction and the GC can free the memory in a simply run 
with no big effort.

> That sounds exactly like reference counting – and it suffers from all  
> the well known problems (like retain cycles).  The point here is that  
> you don't *want* the developer to have control, the developer (myself  
> included) is really really bad at doing this, and introduces a *lot*  
> of bugs in the process.

> The option for it of course will keep everyone happy, but that doesn't  
> mean it should be encouraged ;)

No, It does not really mean reference counting. Of course it is not good to 
dispose an object when there is still a reference on it. (In c# this reference 
is still valid but simply points to a disposed object so that all internel 
references are "cleared".)

- One big advantage is, that you simply resolve "paths" of object references 
with results in less work for the garbage collector.
- another big advantage can be the quicker memory deallocation. The world is 
not just "managed code". I am quite sure, that the Developer on a Mac also has 
a lot of existing modules he wants to use that allocates memory and so. And if 
you wait till dispose() is called by the GC, you could have waisted memory in 
that time. (Which the GC couldn't see, because the memory involved was not 
managed by the GC)

Maybe it helps a little to clarify:
- Dispose is not deallocating memory! It is just doing the logic required to 
make the object ready for destruction. One important part for that is simply 
setting references to null.
- Finalize is what is done directly before the destruction (So far that part 
was never important for me in all my developing practice)

So the management of the memory is done by the GC, but we simply help the GC 
(and keep care of other resources that are not managed)

Hope I was able to clarify this a little. The link to CodeProject also gives 
such an overview but I know that it is not of any interest for an objective-c 
developer because it only handles managed code / Microsoft .Net Framework. (And 
I am really sorry - maybe I simply should have waited till I am much deeper 
inside all this Objective-C / Cocoa stuff. Reading all the discussion about the 
GC pros and cons simply made me write something, too.)

With kind regards,

Konrad

___

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 arch...@mail-archive.com

Dispose pattern (was: Re: GC pros and cons)

[Konrad Neitzel]

Hi all!

Thomas Davie  schrieb am 27.06.2009 09:56:31:
> On 27 Jun 2009, at 01:27, James Gregurich wrote:

> > GC isn't nirvana.  it does have its perils and issues, and you have  
> > to be aware of them and code around them. You can't just turn it on  
> > and some how everything magically works. There is no perfect  
> > solution to memory management. I prefer a  solution where I manage  
> > the dependencies and objects go away in an orderly fashion based on  
> > the dependency graph for those objects.

> Uhhh, you mean a garbage collector?  That's exactly what it does --  
> frees objects when nothing depends on them any more.
 
But a garbage collector must be able to detect an object which memory can / 
must be released. And for all this, the system has to do some work.

I still have to read much more about the GC used within Objective-C / Cocoa so 
I am not sure, if I am not writing some kind of "bullshit" from your view:

Isn't it possible to simply flag an object to be removed? Is there a dispose 
pattern in Objective-C?
(e.g. http://www.codeproject.com/KB/cs/idisposable.aspx describes such a 
pattern in C#)

Something like that would simply more the world together again. That way, the 
developer has some more control, the GC has less work and all are maybe happy?

So is there such an Dispose Pattern in Objective-C using a GC or is there 
nothing like that?

With kind regards,

Konrad Neitzel

___

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 arch...@mail-archive.com

Re: [bulk]: Re: GC pros and cons

[Konrad Neitzel]

Graham Cox  schrieb am 27.06.2009 05:13:37:

> Using GC may mean you can avoid even that small degree of necessary  
> care, but the ownership rules are straightforward, easily learned and  
> committed to mind, and are hardly arcane or arbitrary - they are  
> simple and logical. I'd really rather deal with that and the odd bug  
> where I forgot something than the performance hit I'm going to take  
> when GC kicks in. I know that this hit is small, but so is the effort  
> required to use retain/release, so it seems to me we are arguing about  
> small stuff here, not big stuff.

> I don't really get why the memory management/ownership rules seem to  
> be so hard for so many people. But I accept that they are, to some. If  
> they are, maybe GC is a godsend to those folk, but for everyone else,  
> I just can't see the big deal.

Hmm. I am new to Objective C and Software development on a mac. I am earning my 
money with software development on windows using Visual Studio / C#.

And in the managed environment. you get much more advantages than just 
something like "If some people cannot learn some basic memory management, then 
maybe something like that is good..." (Sorry, that is, what I mostly read in 
your argument. sorry when I got you wrong)

It simply has nothing to do with care. But there are a few facts:
1) Errors will be done as long as it is possible to do errors. It has nothing 
to do with beeing carefull or not.
2) I want the system to be secure. I don't want to have some kind of trustment 
in people I do not know.  I really like the managed environment, because it 
takes some security related stuff from teh shoulders of the developer.

Of course: All this stuff is not required! The "managed system" is not doing 
anything special. You can make sure, that there are no buffer overflows and no 
access to not initialized objects and all this stuff. But the past simply 
shows, that a lot of developer simply do not care or simply make errors. Just 
have a look at annoced security holes where people use such bugs to stop 
services or even get access to systems.

And the argument, that the GC will take some time when it starts to free memory 
(Which can also be a large hit in the .Net Environment. It simply depends how 
much work the GC has to do to free some memory that could be required): 
What kind of application are we talking about? Is it really a problem to have 
such a short delay?  If such a small delay is not acceptable, maybe the whole 
system is not acceptable and you simply need a RTOS. (And what are you doing to 
make sure, that you do not have such delays? Are you sure, that the calls you 
are using now are completing in the time you are expecting?

Of course I am aware, that this is far away from the main discussion about the 
GC and the behaviour of the GC (Which I do not understand. If an object is no 
longer referenced inside my active code, I do not care when the memory is 
released completly. But I just started to read into objective-C / Cocoa to 
start some development on my iMac, so I think I will catch the discussion some 
time later!) and I am comming with a fully managed environment which is 
something else even if the managed environment has a GC, too. But the point in 
my eyes is, to simplify development and make it more secure.

That is just my small view and I hope it was a little helpfull. Don't be mad at 
me, if I got you or the discussion wrong. And hopefully you will read some more 
from me in the future here. Will take the printed PDFs MemoryMgmt.pdf, 
GarbageCollection.pdf and ObjCRuntimeRef.pdf from the printer now to read them 
in the train next.

With kind regards,

Konrad Neitzel


___

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 arch...@mail-archive.com

NSImageView/NSImage question

[Marco S Hyman]

I'd like to get the path of the file containing the data used to
create an NSImage when that images is dragged onto an NSImageView.
I think I stated that correctly.  Is it possible?   If so a pointer
to the appropriate doc would be appreciated.

Looking through the doc it seems that an image will retain its
path with -setDataRetained if initialized using –initByReferencingFile:
but even then I see no way to get the path.


/\/\arc

___

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 arch...@mail-archive.com

NSTableView -setDataCell confusion

[Chase Meadors]

I'm using AMIndeterminateProgressIndicatorCell (at least the drawing  
code) to imitate a progress indicator in the table view. To get it to  
use the custom cell, I've been calling


[myTableColumn setDataCell:[[MyCustomClass alloc] init]];

However, I've run into a 'slight' problem. Apparently, ALL of the  
cells in this column are that one, same, object. When I tested with F- 
script, I found that they have the exact same description, and same  
memory address. This explains why bindings affecting one cell would  
affect all of them...


So, in short, is there a +setCellClass method or similar for  
NSTableColumn? Any way to make it use different objects?


Thanks for any answers and sorry if I'm missing something obvious here.
___

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 arch...@mail-archive.com

Intersection of CGPath and CGRect

[Martin Hewitson]

Hi,

Does anyone know a good way to test if a CGPathRef intersects a CGRect  
at any point?


Thanks,

Martin


Martin Hewitson
Albert-Einstein-Institut
Max-Planck-Institut fuer
Gravitationsphysik und Universitaet Hannover
Callinstr. 38, 30167 Hannover, Germany
Tel: +49-511-762-17121, Fax: +49-511-762-5861
E-Mail: martin.hewit...@aei.mpg.de
WWW: http://www.aei.mpg.de/~hewitson






___

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 arch...@mail-archive.com

Synchronization across plug-ins loaded by different processes

[Chris Arnaiz]

Hi,

 

I'm new to Mac programming (and software engineering in general), so I
apologize in advance if my terminology is wrong.

 

I'm currently developing a plug-in (a Print Dialog Extension to be
exact) and wanted to make sure only one instance of the plug-in is
allowed to be in "editing mode" for information that will be saved on a
preference file.  Since the plug-in can be loaded by different
applications, I'm assuming using distributed objects makes the most
sense to allow the plug-in instances to be aware of each other (on a
single system).

For my implementation, I was going to vend a helper tool that's
responsible for saving information on the preference file.  Ideally, I
want only one instance of the helper tool to exist and have it shared
across multiple plug-ins.  The helper tool should only be destroyed if
there are no plug-ins loaded on the machine.  I was planning to have the
helper tool also maintain the exclusive "editing mode" among the
instances.

To achieve this structure, I need a way for the helper tool to hang
around until all instances of the plug-in are destroyed.

 

Any suggestions will be greatly appreciated.

 

Thanks,

Christopher

___

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 arch...@mail-archive.com

How to get a fully transparent hit-testable window?

[Pranav Goel]

Hi
I am writing a Cocoa application which has a WebView in a NSWindow. I want to 
be able to put this window onscreen and have it be completely transparent i.e. 
nothing should be drawn on the screen. But I still want the WebView to respond 
to mouse input when a mouse action happens within its window rect. Is there a 
way to do this?

I tried setting Opacity on the window to 0, I don't see anything on the screen 
which is great. But the window (and the WebView) don't respond to input 
anymore, apparently a NSWindow becomes transparent to mouse input for opacity 
values less than 0.05 or so.


Thanks,
Pranav

___

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 arch...@mail-archive.com

Re: Hiding a running application

[Carl Harris]

My app does some processing at quit time that can take a few  
minutes, so I

thought it would be nice to remove the gui from the user¹s attention


I deal with a similar situation by using a helper application,  
configured as a launch agent.  The helper program is configured to be  
launched automatically (by launchd) when the foreground application  
connects to its UNIX domain socket.  The foreground application passes  
enough information to the helper program (over the socket) for the  
helper to do the clean up work.  After the work has been passed off to  
the helper, the foreground app simply exits -- the user doesn't know  
or care that the helper is running.


There are several other options for configuring and auto-launching the  
helper app.  See


http://developer.apple.com/documentation/MacOSX/Conceptual/BPSystemStartup/Articles/LaunchOnDemandDaemons.html

for more details.

--
Carl Harris
cehar...@vt.edu


___

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 arch...@mail-archive.com

Tool-tips on NSTabViewItem

[PKameo]

How do you add a tool-tip to a NSTabViewItem? I tried the following, but
that didn't work right.
[[tabViewItem view] setToolTip:toolTip];
//Where tabViewItem is of type NSTabViewItem* and toolTip is of type
NSString* 

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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Force NSTextField to update (and transform)

[Michał Glenc]

Hi,
I'm a beginner in Cocoa world and I have some problems with bindings,  
NSValueTransformer etc.


My application performs basic currency transforming. I have two  
NSComboBoxes (where I change currency) and two NSTextFields.  
Everything works fine, the values get transformed. However, when I  
change currency in one of ComboBoxes (after values in TextField have  
been already entered), value in TextField stays unchanged. What I want  
to achieve is to send the TextField (or perhaps the  
NSValueTransformer) a message that it's value has been changed (so  
that it retransforms) when the currency in ComboBox is changed. Could  
you advise me something?


Greetings,
Michal
___

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 arch...@mail-archive.com

Re: Positioning document within gray area of a scroller

[Graham Cox]

On 29/06/2009, at 9:56 AM, Graham Cox wrote:

If the view that is inside the scroll view is overridden to return  
YES for -isFlipped, it will pin to the upper left and not the lower  
left.



By the way, I have noticed at times that sometimes after setting this  
up in IB, the scrollview isn't working correctly. This was certainly  
true in IB < 3.0, so it may be fixed in 3 and later. Since you say you  
have tried -isFlipped to no avail, you might have run into this.  
Usually I found that recreating the scroller/custom view fixed up the  
problem - just an occasional glitch it seems.


--Graham


___

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

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

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

This email sent to arch...@mail-archive.com

Re: 10.4 & 10.5 compatibility

[Stephen Blinkhorn]

OK, many thanks for the tips Steve.

On 28 Jun 2009, at 19:07, Steve Christensen wrote:


On Jun 28, 2009, at 5:09 PM, Stephen Blinkhorn wrote:

I have just noticed that some standard Cocoa objects look very  
different on 10.4 compared to 10.5.  In particular NSPopUpMenu and  
NSButton objects are being drawn as much larger controls on 10.4  
(rounded rect style, mini size).  I am creating xib files via IB on  
Leopard.


There is no guarantee that standard views will adhere to a  
particular look or size across OS versions. You can either create  
multiple per-OS nibs that you load programmatically or a single  
version that has appropriate spacing for the OS version you know  
about.


Also, I am using some standard icons like NSUserGroup and such  
which are not being displayed within NSButton at all on 10.4.  I  
can probably find these and add them into my bundle but it seems  
curious.


That string constant for that icon is only defined in the 10.5 SDK  
version of NSImage.h as


APPKIT_EXTERN NSString *const NSImageNameUserGroup  
AVAILABLE_MAC_OS_X_VERSION_10_5_AND_LATER;


Thus I would not expect that the image (at least using that name) is  
available on a system running Tiger.


I am testing on 10.4.6 which is the version of my install DVD so my  
question is whether there is a minimum Tiger version that includes  
Leopard compatibility for this kind of stuff? 10.4.9?


The minimum OS version that includes Leopard compatibility is, by  
definition, 10.5.0. If you're using Leopard-only features —whether  
classes, methods or resources— and you want to run on a Tiger  
system, you'll need to provide an appropriate alternative or  
gracefully downgrade the functionality you provide. For the case of  
an icon, that may mean that you need to embed your own version; for  
the case of code, you need a runtime check that does the right thing  
for each OS version.


steve



___

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

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

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

This email sent to arch...@mail-archive.com

Re: GC pros and cons

[Chris Idou]

From: James Gregurich 

> 3) I don't allow exceptions of any kind to propagate into alien 
> codeparticularly the cocoa runtime.



Given that Objective-C doesn't have declared exceptions (like Java), it seems 
more likely that you "hope" exceptions are not propagated into alien code.

Unless that is you are in the unusual situation that you use no third party 
libraries, or you have full and perfect knowledge of where and when they might 
throw an exception.


  Access Yahoo!7 Mail on your mobile. Anytime. Anywhere.
Show me how: http://au.mobile.yahoo.com/mail
___

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 arch...@mail-archive.com

Re: UITextView symbols

[Andrew Farmer]

On 27 Jun 2009, at 16:26, DKJ wrote:

I'm using this method:

textView:shouldChangeTextInRange:replacementText:

to let users put special symbols into a UITextView.

I detect the Return key by checking whether the input string is  
equal to @"\n". But how would I detect the back-delete key? @"\b"  
doesn't do it. And I can't seem to find any docs that list these  
codes.


I haven't done any iPhone development myself, but I'd imagine that  
your problem is that you're looking for the wrong sort of change.  
Pressing Return inserts a newline, but pressing backspace doesn't  
insert a backspace. It removes a character. At a blind guess, maybe  
it'll show up as a range of length 1 being replaced with @""?

___

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 arch...@mail-archive.com

Re: UITableViewCells

[mmalc Crawford]

On Jun 28, 2009, at 3:00 PM, William Squires wrote:

A few suggestions:


// Configure the cell.
HighScoreSamplerAppDelegate *appDelegate =  
(HighScoreSamplerAppDelegate *)[[UIApplication sharedApplication]  
delegate];




This particular situation may be a debatable case, but to make a point  
for other circumstances: in general you are discouraged from creating  
dependencies between your view controllers and other parts of your  
application.  You are typically encouraged, at the point at which you  
create it, to pass to a view controller any data that it will need.


NSDictionary *row = [[appDelegate highScores]  
objectAtIndex:indexPath.row]; // Problem here

[...]
Looking in the debugger, I can see the argument "indexPath" is not  
nil, but there's no "row" property shown by the debugger when I  
expand it. Why didn't I get an exception for "indexPath does not  
respond to selector 'row'"? And what is the name of the property I  
need here?




This suggests a misunderstanding of "property" -- unfortunately an  
overloaded term -- and possibly of the dot syntax.


It is important to appreciate that a "property" -- in both the  
abstract sense of a feature of an instance, and in the sense of a  
declared @property -- is not required to be "backed" by an actual  
instance variable.

The canonical example is probably the "fullName" property of a Person.
Typically "fullName" is a concatenation of "firstName" and "lastName"  
-- a derived property.  You would usually declare an accessor method  
or an @property for "fullName" and yet there would be no "fullName"  
instance variable.  Similarly for "row" -- there is no instance  
variable for "row" in NSIndexPath, it is a derived property (actually  
simply the second item in the index path -- the first being the  
section)..


Just in case: You may be confusing the dot operator with direct access  
of fields of a structure.  The dot operator is syntactic sugar for an  
accessor method -- see .



NSString *full_name = [row objectForKey:@"full-name"];
NSString *score = [row objectForKey:@"score"];



In general (particularly for iPhone), you are encouraged to use custom  
classes rather than dictionaries.  Dictionaries are much less  
efficient than custom classes.  (You will also, of course, gain  
compiler support for checking method names so you don't accidentally  
ask for objectForKey:@"full_name" instead of "@full-name".  On a  
tangent to which, Cocoa convention is to use camelCase rather than  
using separators.)



cell.text = [NSString stringWithFormat:@"%@ - %@", full_name, score];

Again in general you are strongly encouraged to avoid using  
autoreleased objects.


I appreciate it is longer-winded to write:

NSString *textString = [[NSString alloc] initWithFormat:@"%@ - %@",  
full_name, score];

cell.textLabel.text = textString;
[textString release];

however doing so will ensure that resources are reclaimed as soon as  
possible -- it's a good habit to get into.


Using iPhone 3.0 SDK (I hope this post isn't still under NDA since  
iPhone OS 3.0 is now out in the wilds...)




The 3.0 SDK is now public.

mmalc

___

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 arch...@mail-archive.com

Re: 10.4 & 10.5 compatibility

[Steve Christensen]

On Jun 28, 2009, at 5:09 PM, Stephen Blinkhorn wrote:

I have just noticed that some standard Cocoa objects look very  
different on 10.4 compared to 10.5.  In particular NSPopUpMenu and  
NSButton objects are being drawn as much larger controls on 10.4  
(rounded rect style, mini size).  I am creating xib files via IB on  
Leopard.


There is no guarantee that standard views will adhere to a particular  
look or size across OS versions. You can either create multiple per- 
OS nibs that you load programmatically or a single version that has  
appropriate spacing for the OS version you know about.


Also, I am using some standard icons like NSUserGroup and such  
which are not being displayed within NSButton at all on 10.4.  I  
can probably find these and add them into my bundle but it seems  
curious.


That string constant for that icon is only defined in the 10.5 SDK  
version of NSImage.h as


APPKIT_EXTERN NSString *const NSImageNameUserGroup  
AVAILABLE_MAC_OS_X_VERSION_10_5_AND_LATER;


Thus I would not expect that the image (at least using that name) is  
available on a system running Tiger.


I am testing on 10.4.6 which is the version of my install DVD so my  
question is whether there is a minimum Tiger version that includes  
Leopard compatibility for this kind of stuff? 10.4.9?


The minimum OS version that includes Leopard compatibility is, by  
definition, 10.5.0. If you're using Leopard-only features —whether  
classes, methods or resources— and you want to run on a Tiger system,  
you'll need to provide an appropriate alternative or gracefully  
downgrade the functionality you provide. For the case of an icon,  
that may mean that you need to embed your own version; for the case  
of code, you need a runtime check that does the right thing for each  
OS version.


steve

___

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

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

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

This email sent to arch...@mail-archive.com

Re: GC pros and cons

[mmalc Crawford]

On Jun 28, 2009, at 4:40 PM, Michael Ash wrote:


Doesn't take any experience, just a bit of reading. I'd recommend that
all participants in this thread read the Garbage Collection
Programming Guide top to bottom before continuing any further


This article:


is of particular relevance.

If anything is not clear, please send feedback.

mmalc

___

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 arch...@mail-archive.com

Re: Problem with Service and PasteBoards

[mmalc Crawford]

On Jun 27, 2009, at 10:13 AM, Guillem Palou wrote:

It's not clear what you're trying to achieve.  Are you invoking the  
service from the same application that provides it?




NSReturnTypes

dictionaryPBoardType






In which application is this property defined?


NSPerformService(@"Get Movie Info", pboard);



What happens if you try to invoke the service from a running  
application (if you're able to?)?


See also  and follow-ups.


mmalc

___

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 arch...@mail-archive.com

Re: GC pros and cons

[Clark Cox]

On Sun, Jun 28, 2009 at 4:32 PM, Quincey
Morris wrote:
> On Jun 28, 2009, at 16:12, Michael Ash wrote:
>
>> Your way sounds sensible, but according to the docs that's not how it is.
>
> We'll have to wait for b.bum to adjudicate, since the docs contradict what
> he said earlier:
>
> On Sat, Jun 27, 2009 at 9:47 PM, Bill Bumgarner wrote:
>>
>> When a CF object is created, it is CFRetain()ed and, thus, the collector
>> will ignore it.  If it is then managed entirely through a balanced set of
>> CFRelease() and CFRetain() calls, it'll work just like it does under
>> non-GC.
>>
>> If you call CFMakeCollectable(), that'll effectively balance the
>> CFRetain()
>> at creation while making the collector aware of the object.
>
> His "just like it does" strongly implies that the memory is disposed of
> immediately, unless he meant "just like it does under non-GC, except for the
> timing of disposal".
>
> His "making the collector aware of the object" contradicts the docs, since
> that would be a third thing CFMakeCollectable does.
>
> Of course, it might work the way the docs say in Leopard, and possibly Bill
> was talking about possible future behavior in some possible future Mac OS X.

The collector is always "aware" of CF objects in the same way as it is
aware of Objective-C objects. The difference is that the retain count
that CFRetain/CFRelease manage is still honored under GC. An object
with a non-zero CF retain count is not eligible for collection,
regardless of whether or not there are any other strong references to
it. This allows CF-using code to work  under GC, in much the same way
as it does under retain/release.

Under garbage collection, CFMakeCollectable (and NSMakeCollectable) is
simply an alias for CFRelease, but with an better, more
intention-revealing name. Under retain/release on the other hand,
CF/NSMakeCollectable is a no-op.

This fact can also be used in the other direction. If you have an
Objective-C object that you want to stick around, even if there are no
strong references to it (e.g. if you want to store it in a void*,
perhaps to pass as a callback parameter, or if you want to store it in
an STL container), you can CFRetain it, and the collector will know
that it is a live object, effectively rooting it, until a
corresponding CFRelease (or CFMakeCollectable) decreases its CF-retain
count to zero.

>From the collector's point of view, there is no difference between an
Objective-C object, and a CFType object with a zero retain count.


-- 
Clark S. Cox III
clarkc...@gmail.com
___

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

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

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

This email sent to arch...@mail-archive.com

Re: UITextView symbols

[WT]

On 28/06/2009, at 9:26 AM, DKJ wrote:



I detect the Return key by checking whether the input string is  
equal to @"\n". But how would I detect the back-delete key? @"\b"  
doesn't do it. And I can't seem to find any docs that list these  
codes.


Have you tried to use the NSString method -initWithCString:encoding:  
to create a string containing the ASCII character corresponding to the  
backspace key (I believe it's \x08) ? You'd use NSASCIIStringEncoding  
as the encoding and then you could use the resulting string to compare  
against the user input.


I don't know if this will work. I haven't tried it, but I thought I'd  
mention it anyway.


Wagner
___

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 arch...@mail-archive.com

Re: UITableViewCells

[mmalc Crawford]

On Jun 28, 2009, at 3:41 PM, WT wrote:

-section and -row are defined in an extension to NSIndexPath. See  
here:


This is not correct -- they're defined in a *category* of NSIndexPath  
-- see
/$Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk/ 
System/Library/Frameworks/UIKit.framework/Headers/UITableView.h


Class extensions and categories are different, see "Categories and  
Extensions"
	


mmalc

___

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 arch...@mail-archive.com

Re: UITableViewCells

[mmalc Crawford]

On Jun 28, 2009, at 3:41 PM, WT wrote:

-section and -row are defined in an extension to NSIndexPath. See  
here:


This is not correct -- they're defined in a *category* of NSIndexPath  
-- see
/$Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk/ 
System/Library/Frameworks/UIKit.framework/Headers/UITableView.h


Class extensions and categories are different, see "Categories and  
Extensions"
	


mmalc

___

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 arch...@mail-archive.com

10.4 & 10.5 compatibility

[Stephen Blinkhorn]

Hello all,

I have just noticed that some standard Cocoa objects look very  
different on 10.4 compared to 10.5.  In particular NSPopUpMenu and  
NSButton objects are being drawn as much larger controls on 10.4  
(rounded rect style, mini size).  I am creating xib files via IB on  
Leopard.


Also, I am using some standard icons like NSUserGroup and such which  
are not being displayed within NSButton at all on 10.4.  I can  
probably find these and add them into my bundle but it seems curious.


I am testing on 10.4.6 which is the version of my install DVD so my  
question is whether there is a minimum Tiger version that includes  
Leopard compatibility for this kind of stuff?


10.4.9?

Thanks,
Stephen.
___

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 arch...@mail-archive.com

Re: Objective C Compiler Settings

[Graham Cox]

On 29/06/2009, at 9:18 AM, Michael Ash wrote:

On Sun, Jun 28, 2009 at 4:12 PM, Tommy Nordgren> wrote:
Are there any compiler flags you can provide when compiling  
Objective C

code,
that causes an exception to be triggered when a category implements  
a method

that is already implemented in the target class?


Not an exception, but you can get the runtime to log any replaced
methods by setting the OBJC_PRINT_REPLACED_METHODS environment
variable when running your app. This and other environment variables
can be found by running an ObjC program with the OBJC_HELP enviroment
variable set. This will print out a brief bit of documentation about
all the debugging variables supported by the runtime.



Cool, that's really useful and previously unknown to me - where did  
you get to know about this? Can you point to documentation? Seems I'm  
missing a whole bunch of stuff that others know about.


--Graham


___

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

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

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

This email sent to arch...@mail-archive.com

Re: Positioning document within gray area of a scroller

[Graham Cox]

On 29/06/2009, at 7:28 AM, Development wrote:

We are working on a document based application which displays the  
document view within a scroller area.  Like most similar programs,  
the user can zoom in and out off the document (ie. we change the  
view size of the document view).  If he zooms out enough, our  
document view becomes smaller then the area that the scroller  
encloses. No problems so far. The scroll view draws a grey region  
outside the area of our document region, and everything works fine.  
We do not have to code any of this. However, our now small document  
view is pinned to the lower left of area being shown by the scroller  
view, instead of the upper left.


OK, you have described the default behaviour.


Has anyone been able to program this?


What is the question?


We asked this question at WWDC, and stumped several of the engineers.


What question?

We have tried all sorts of variations of configuration under  
Interface Builder. We have set the isFlipped: method to different to  
change where the origin is, and nothing seems to work.  I know  
people have asked this question here before, but there has never  
been a good answer.


Our client is insisting that the document view should pin to the  
upper left hand corner. This is the way Mac applications did it  
under OS 9.


If the view that is inside the scroll view is overridden to return YES  
for -isFlipped, it will pin to the upper left and not the lower left.  
Of course that means your co-ordinate system in that view is also  
flipped, but in many cases that's easier to handle anyway (or at least  
more traditional). If you need unflipped co-ordinates but still pin to  
the upper left, you'll have to handle the positioning yourself, which  
requires a subclass of NSClipView. There is sample code on the web but  
in doing this the other week I found that almost all the links point  
to the same place, and the link is now dead.


More typically people want to centre the view when it becomes smaller  
than the scroller (which is what I did). I did find the sample code  
snippets at CocoaDev insufficient to fully handle this - for example  
show/hide rulers didn't function correctly and nor did live resizing.  
If you are interested in that code ask me off-list.


--Graham



___

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

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

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

This email sent to arch...@mail-archive.com

Re: GC pros and cons

[Bill Bumgarner]

On Jun 28, 2009, at 6:32 PM, Quincey Morris wrote:

On Jun 28, 2009, at 16:12, Michael Ash wrote:
Your way sounds sensible, but according to the docs that's not how  
it is.
We'll have to wait for b.bum to adjudicate, since the docs  
contradict what he said earlier:


bbum is currently on vacation and only answering questions from memory  
because bbum's hard drive done gone and exploded.  I'm sans dev tools  
or source!  (Yes, I find answering questions on cocoa-dev and reading  
source to be vacating.  Go figure).  Thankfully, I lost nothing save  
for a few bad pictures.  All the good ones were fine.


In any case, it entirely depends on the zone of allocation.

MOST of the time, a CF based object will be allocated from the GC zone  
and, thus, the collector will treat it just like any other random CF*  
or NS* based object.


The one key difference between CF* and NS* objects is that CF* objects  
are created CFRetain'ed.  That is, they won't be collected until they  
are explicitly CFRelease'd.


CFMakeCollectible() simply CFRelease()s the object and leaves it up to  
the collector get around to collecting it.


However, CF can have other kinds of allocators than the default one.   
Thus, it is possible to create CF objects that don't follow these  
rules.   But don't do that.


And, as Michael said:


Doesn't take any experience, just a bit of reading. I'd recommend that
all participants in this thread read the Garbage Collection
Programming Guide top to bottom before continuing any further


Absolutely right.   Go do that.

b.bum

___

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 arch...@mail-archive.com

Re: GC pros and cons

[Michael Ash]

On Sun, Jun 28, 2009 at 7:33 PM, Peter Duniho wrote:
> Maybe I'm misreading one, or the other, or both of your messages, but it
> seems to me that what Quincy wrote is in agreement with what you quoted.
>
> In particular, my (admittedly inexperienced) understanding is that an object
> winds up "in the garbage collected zone" when code calls CFMakeCollectable.
>  Conversely, "GC-unaware code" would not, I would think, call
> CFMakeCollectable (that seems like a very "GC-aware" thing to do, right?).

"NULL, kCFAllocatorDefault, and kCFAllocatorSystemDefault specify
allocation from the garbage collection zone.

"By default, all Core Foundation objects are allocated in the garbage
collection zone."

And while we're at it, CFMakeCollectable doesn't do *anything*
magical, all it does is call CFRelease under GC, and assert that the
object is in the right zone. If you know that you're running under GC
and that the object will be in the garbage collected zone, it is
*identical* to CFRelease:

"Better still, though, you can use CFMakeCollectable instead of
CFRelease. CFMakeCollectable calls CFRelease, but has two
supplementary features: first, it halts the program if the object
wasn't allocated in the scanned zone; second, it’s a no-op in a
reference counted environment."

Doesn't take any experience, just a bit of reading. I'd recommend that
all participants in this thread read the Garbage Collection
Programming Guide top to bottom before continuing any further

Mike
___

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

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

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

This email sent to arch...@mail-archive.com

Re: GC pros and cons

[Peter Duniho]

On Jun 28, 2009, at 4:12 PM, Michael Ash wrote:


On Sun, Jun 28, 2009 at 1:17 PM, Quincey
Morris wrote:

I think the answer is in Bill's "entirely", above.

Without CFMakeCollectable, the final CFRetain will trigger the  
calling of (a
hypothetical) CFDispose with the traditional timing (i.e.  
immediately, we

assume, somewhat at our peril).

[...] Thus GC-unaware code gets the behavior at CFRelease time that  
it expects

(somewhat at its peril), whether or not it is running in a GC-enabled
environment.


"If the object is in the garbage collected zone, the last CFRelease()
does not immediately free the object, it simply makes it eligible to
be reclaimed by the collector when it is discovered to be
unreachable—that is, once all strong references to it are gone. Thus
as long as the object is still referenced from an object-type instance
variable (that hasn't been marked as__weak), a register, the stack, or
a global variable, it will not be collected."


From the Garbage Collection Programming guide.


Your way sounds sensible, but according to the docs that's not how  
it is.


Maybe I'm misreading one, or the other, or both of your messages, but  
it seems to me that what Quincy wrote is in agreement with what you  
quoted.


In particular, my (admittedly inexperienced) understanding is that an  
object winds up "in the garbage collected zone" when code calls  
CFMakeCollectable.  Conversely, "GC-unaware code" would not, I would  
think, call CFMakeCollectable (that seems like a very "GC-aware" thing  
to do, right?).


I suppose in a scenario where some code is using an object allocated  
by some other code, where that other code has called  
CFMakeCollectable, but the first code is "GC-unaware", that would be  
an exception to the statements made.  But it doesn't seem like an  
important exception to me, because that first code shouldn't be  
assuming ownership or control over the object anyway (i.e. obviously  
it got the object from somewhere else, and it has no reason to believe  
that it holds the last retain on the object, even if that first code  
doesn't know anything about garbage-collection).


If I've somehow misconstrued what either of you wrote, I apologize.   
But as things stand now, I'm not convinced you're in contradiction  
with each other.


Pete___

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 arch...@mail-archive.com

Re: GC pros and cons

[Quincey Morris]

On Jun 28, 2009, at 16:12, Michael Ash wrote:

Your way sounds sensible, but according to the docs that's not how  
it is.


We'll have to wait for b.bum to adjudicate, since the docs contradict  
what he said earlier:


On Sat, Jun 27, 2009 at 9:47 PM, Bill Bumgarner wrote:


When a CF object is created, it is CFRetain()ed and, thus, the  
collector
will ignore it.  If it is then managed entirely through a balanced  
set of
CFRelease() and CFRetain() calls, it'll work just like it does under  
non-GC.


If you call CFMakeCollectable(), that'll effectively balance the  
CFRetain()

at creation while making the collector aware of the object.


His "just like it does" strongly implies that the memory is disposed  
of immediately, unless he meant "just like it does under non-GC,  
except for the timing of disposal".


His "making the collector aware of the object" contradicts the docs,  
since that would be a third thing CFMakeCollectable does.


Of course, it might work the way the docs say in Leopard, and possibly  
Bill was talking about possible future behavior in some possible  
future Mac OS X.



___

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 arch...@mail-archive.com

Re: Docs warning unclear

[WT]

On Jun 29, 2009, at 1:06 AM, DKJ wrote:


Well, it's unclear to me anyway.

<< Warning: If the view belonging to a view controller is added to a  
view hierarchy directly, the view controller will not receive this  
message. If you insert or add a view to the view hierarchy, and it  
has a view controller, you should send the associated view  
controller this message directly. Failing to send the view  
controller this message will prevent any associated animation from  
being displayed. >>

(In the description of UIViewController viewDidAppear: method)

How is a view controller added to a hierarchy "directly"? How would  
one be added "indirectly"?


dkj


You're not reading the warning carefully enough. Note that it's  
referring to adding a *view*, not a *view controller*, to a *view*  
hierarchy. You add a view to a view hierarchy "directly" by using the  
UIView's -addSubview: method. You should take some time to read the  
"Window and Views" section of


http://developer.apple.com/iphone/library/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/iPhoneAppProgrammingGuide.pdf

to understand how to manipulate the view hierarchy.

Wagner
___

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 arch...@mail-archive.com

Re: Objective C Compiler Settings

[Michael Ash]

On Sun, Jun 28, 2009 at 4:12 PM, Tommy Nordgren wrote:
> Are there any compiler flags you can provide when compiling Objective C
> code,
> that causes an exception to be triggered when a category implements a method
> that is already implemented in the target class?

Not an exception, but you can get the runtime to log any replaced
methods by setting the OBJC_PRINT_REPLACED_METHODS environment
variable when running your app. This and other environment variables
can be found by running an ObjC program with the OBJC_HELP enviroment
variable set. This will print out a brief bit of documentation about
all the debugging variables supported by the runtime.

Mike
___

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

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

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

This email sent to arch...@mail-archive.com

Re: GC pros and cons

[Michael Ash]

On Sun, Jun 28, 2009 at 1:17 PM, Quincey
Morris wrote:
> I think the answer is in Bill's "entirely", above.
>
> Without CFMakeCollectable, the final CFRetain will trigger the calling of (a
> hypothetical) CFDispose with the traditional timing (i.e. immediately, we
> assume, somewhat at our peril).
>
> After CFMakeCollectable in a GC-enabled environment, the final CFRetain (if
> there is one, if the retain count was greater than 1 at the time
> CFMakeCollectable was called) will just discard *the* strong reference that
> the retain count was maintaining. This will trigger the calling of (a
> hypothetical) CFFinalize with the usual timing (i.e. when the collector
> runs, after there are no other strong references remaining).
>
> Thus GC-unaware code gets the behavior at CFRelease time that it expects
> (somewhat at its peril), whether or not it is running in a GC-enabled
> environment.

"If the object is in the garbage collected zone, the last CFRelease()
does not immediately free the object, it simply makes it eligible to
be reclaimed by the collector when it is discovered to be
unreachable—that is, once all strong references to it are gone. Thus
as long as the object is still referenced from an object-type instance
variable (that hasn't been marked as__weak), a register, the stack, or
a global variable, it will not be collected."

>From the Garbage Collection Programming guide.

Your way sounds sensible, but according to the docs that's not how it is.

Mike
___

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

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

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

This email sent to arch...@mail-archive.com

Docs warning unclear

[DKJ]

Well, it's unclear to me anyway.

<< Warning: If the view belonging to a view controller is added to a  
view hierarchy directly, the view controller will not receive this  
message. If you insert or add a view to the view hierarchy, and it has  
a view controller, you should send the associated view controller this  
message directly. Failing to send the view controller this message  
will prevent any associated animation from being displayed. >>

(In the description of UIViewController viewDidAppear: method)

How is a view controller added to a hierarchy "directly"? How would  
one be added "indirectly"?


dkj
___

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

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

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

This email sent to arch...@mail-archive.com

Exit fullscreen with fade

[Mirko Viviani]

Hi,

I use an empty window for fullscreen mode using SetSystemUIMode to  
hide all system widgets and screen fade.
This code used for entering fullscreen mode causes no problems at all,  
but using to exit fullscreen

produce a strange behaviour.

When I close the window and set the system UI mode to normal, the  
window disappear, the dock and the menu bar
fade in progressively, but the desktop is completely black until the  
application reach the event loop.


Is there a way to fix this?

Thank you.

- (void) fadeAll: (id) sender;
{
CGDisplayFadeReservationToken token;
CGDisplayErr err = kCGErrorSuccess;

err =  
CGAcquireDisplayFadeReservation(kCGMaxDisplayReservationInterval,  
&token);


if (err != kCGErrorSuccess)
return;

err = CGDisplayFade(token, 1, kCGDisplayBlendNormal,
kCGDisplayBlendSolidColor, 0, 0, 0, true);


[fullscreenWindow orderOut: self];
[fullscreenWindow close];
SetSystemUIMode(kUIModeNormal, 0);


err = CGDisplayFade(token, 1, kCGDisplayBlendSolidColor,
kCGDisplayBlendNormal, 0, 0, 0, true);

err = CGReleaseDisplayFadeReservation(token);
}

--
Ciao,
Mirko
___

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 arch...@mail-archive.com

Re: UITableViewCells

[WT]

On Jun 29, 2009, at 12:00 AM, William Squires wrote:


Question 1:

Looking in the debugger, I can see the argument "indexPath" is not  
nil, but there's no "row" property shown by the debugger when I  
expand it. Why didn't I get an exception for "indexPath does not  
respond to selector 'row'"? And what is the name of the property I  
need here?


-section and -row are defined in an extension to NSIndexPath. See here:

http://developer.apple.com/iphone/library/documentation/UIKit/Reference/NSIndexPath_UIKitAdditions/NSIndexPath_UIKitAdditions.pdf


Question 2:

I get a warning for "setText:" is deprecated for UITableViewCell.  
What is the Apple-approved way of setting this now?


You must access the cell's text label, and then set the label's text:

cell.textLabel.text = [NSString stringWithFormat:@"%@ - %@",  
full_name, score];


See the UITableViewCell documentation for details.

Wagner
___

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 arch...@mail-archive.com

Re: Positioning document within gray area of a scroller

[Quincey Morris]

On Jun 28, 2009, at 14:28, Development wrote:

We are working on a document based application which displays the  
document view within a scroller area.  Like most similar programs,  
the user can zoom in and out off the document (ie. we change the  
view size of the document view).  If he zooms out enough, our  
document view becomes smaller then the area that the scroller  
encloses. No problems so far. The scroll view draws a grey region  
outside the area of our document region, and everything works fine.  
We do not have to code any of this. However, our now small document  
view is pinned to the lower left of area being shown by the scroller  
view, instead of the upper left.


Has anyone been able to program this?

We asked this question at WWDC, and stumped several of the  
engineers.  We have tried all sorts of variations of configuration  
under Interface Builder. We have set the isFlipped: method to  
different to change where the origin is, and nothing seems to work.   
I know people have asked this question here before, but there has  
never been a good answer.


Our client is insisting that the document view should pin to the  
upper left hand corner. This is the way Mac applications did it  
under OS 9.


As always, if we find the answer, we will post it here, but for such  
a simple issue, this one has been driving us crazy.


Yes, it's doable several different ways. Here's one way:

-- Have your document view observe frame-size-changed notifications  
for the scroll view's clip view. When you're notified of a change:


-- Recompute your document view's frame size to be *at least* as large  
as the clip view.


-- Set your document view's bounds origin to center the drawn document  
within the visible rect. You'll also set its size to according to the  
current zoom level.


Obviously, this means changing your code to be aware that your view  
includes the gray area. That sometimes has advantages, since sometimes  
you want to draw in the gray area anyway (e.g. for a shadow, or for  
guide extension lines that run to the clip view edges).


That's the most NSRuler-friendly approach I know of. If you don't care  
about rulers, plan B might be to make the scroll view's documentView  
be just a NSView, and make your real document view a subview of that.  
You can then position your document view wherever you want within the  
documentView. Again, you would observe clip view size changes so that  
you can resize the documentView and reposition the document view as  
necessary.



___

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 arch...@mail-archive.com

Re: Positioning document within gray area of a scroller

[Kyle Sluder]

On Sun, Jun 28, 2009 at 2:28 PM,
Development wrote:
> Has anyone been able to program this?

Try subclassing the NSScrollView's NSClipView.  I imagine the strategy
is quite similar to the one used when centering the document view
within the scroll view:
http://www.cocoadev.com/index.pl?CenteringInsideNSScrollView

--Kyle Sluder
___

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

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

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

This email sent to arch...@mail-archive.com

Re: SOLUTION Placement of window using interface builder on different size displays

[Development]

On Jun 28, 2009, at 5:01 PM, Development wrote:

Surely this is a simple way of doing this?  (Yes, and don't call me  
Shirley).


We are creating a document based application that has various  
inspector panels that need to come up in exact position when the  
user first starts the application.  Most importantly, there are  
several windows that hug the top and side edges of the screen.  I  
created the windows using Interface Builder (IB), set their initial  
location, and it worked fine for my screen.  Then we gave it to some  
testers who are running on something other then an iMac (with  
different screen dimensions), and the inspector windows appeared all  
over the place.


Apparently, the position of the window, that is set using Interface  
Builder is based on having the origin a the bottom left corner (ie.  
Quartz style).  What we want to do is set the initial position of  
the window based on a top left (is. flipped) coordinate systems!  
This puzzled me since there does not seem to be any way to tell the  
Window manager to do this. There is no setting in the IB Inspector,  
nor is there any methods to override.


I am betting this is something very simple, but I have never had to  
require where a window come up before. Either the window is a  
document window, and is tiled, or it is a dialog window, and needs  
to be centered on the screen or document, or it does not matter.


Yes, I know I could at write code to programatically move the window  
is the current position at initial startup, however this would  
require hard coding each window to do this.


Help?!?

Steve Sheets



Thanks to Benajmin Dobson, I have the answer. Ben wrote to me:

"In the Size Inspector for the window, under Initial Position, click  
on the little grey triangles on the top and the left. I think that  
does it.


http://www.quicksnapper.com/sabrelight/image/initial-position";


He was exactly right. I had no idea that those grey triangle tabs were  
clickable.


Solution Found!

Thanks,

Steve Sheets

___

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 arch...@mail-archive.com

Re: Interface Builder Questions...

[Kyle Sluder]

On Sun, Jun 28, 2009 at 2:54 PM, Quincey
Morris wrote:
> The (philosophical) question is: what are you doing that makes it important
> to know the window size as you're dragging the window? Why do you care what
> the numerical window size is, when the correct answer is "whatever makes the
> window fit its contents"?

I don't think it's wrong, per se.  Though the far more important
number for me is the size of the content view.  For example, if you're
working on a word processing application, it's kind of nice to lay out
the window at a size with the same ratio as 8.5x11 (or A4, if you
prefer).

But Quincey is correct in emphasizing the relationship between
controls over the size of the window.  After all, the user can resize
the word processing document window to whatever size he likes.

--Kyle Sluder
___

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

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

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

This email sent to arch...@mail-archive.com

UITableViewCells

[William Squires]

Two questions here.

I have the following code in the tableView:cellForRowAtIndexPath:  
method:


- (UITableViewCell *)tableView:(UITableView *)tableView  
callForRowAtIndexPath:(NSIndexPath *)indexPath

{
static NSString *CellIdentifier = @"Cell";
UITableVIewCell *cell = [tableView  
dequeueReusableCellWithIdentifier:CellIdentifier];

if (cell == nil)
  {
  cell = [[[UITableViewCell alloc]  
initWithStyle:UITableViewCellStyleDefault  
reuseIdentifier:CellIdentifier] autorelease];

  }

// Configure the cell.
HighScoreSamplerAppDelegate *appDelegate =  
(HighScoreSamplerAppDelegate *)[[UIApplication sharedApplication]  
delegate];
NSDictionary *row = [[appDelegate highScores]  
objectAtIndex:indexPath.row]; // Problem here

NSString *full_name = [row objectForKey:@"full-name"];
NSString *score = [row objectForKey:@"score"];
cell.text = [NSString stringWithFormat:@"%@ - %@", full_name, score];
  // Warning on this line:
  // "Warning: setText: is deprecated (declared at /Developer/ 
Platforms/iPhoneSimulator/... blah, blah

return cell;
}

Everything is fine up until the line

NSDictionary *row = [[appDelegate highScores]  
objectAtIndex:indexPath.row];


"highScores" is defined in RootViewController.h as an NSMutableArray,  
btw.


Question 1:

Looking in the debugger, I can see the argument "indexPath" is not  
nil, but there's no "row" property shown by the debugger when I  
expand it. Why didn't I get an exception for "indexPath does not  
respond to selector 'row'"? And what is the name of the property I  
need here?


Question 2:

I get a warning for "setText:" is deprecated for UITableViewCell.  
What is the Apple-approved way of setting this now?


Using iPhone 3.0 SDK (I hope this post isn't still under NDA since  
iPhone OS 3.0 is now out in the wilds...)


___

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 arch...@mail-archive.com

Re: Interface Builder Questions...

[Quincey Morris]

On Jun 28, 2009, at 13:32, Phil Hystad wrote:

So, are you telling me that everyone else can see dynamic changes to  
these height and width pixel values but I can't?


No, other than the layout numbers that show up when you hold down the  
Option key while dragging, as Kyle pointed out, no one's seeing  
dynamic changes to those values.


I would submit that it is a little early to submit a bug report --  
certainly there must be something I am not doing right.  Yes, I know  
that I can enter them in manually but I am more interested in trying  
to figure out if anything is broken with my IB or not.  Maybe I am  
seeing normal behavior.  But, if this is normal, it sure seems to be  
very awkward which does not seem like IB or Xcode.


You're not doing anything wrong. It's a matter of expectations.

The point is that the numerical sizes of things are far less important  
than you might think at first. IB's strength is laying out elements  
according to the inter-element spacing recommendations (i.e. rules) of  
the Apple Human Interface Guidelines. That means you almost always  
want you windows sized based on the content, and IB is really good at  
snapping the window edges to the right places when you drag the window  
resize corner.


This works within the window, too. The size and position of many  
controls snaps to the recommended values. The best way to use IB is to  
lay things out using these snapped sizes and positions. Once that's  
done, you may want to fine-tune things by changing the numeric values  
directly.


The (philosophical) question is: what are you doing that makes it  
important to know the window size as you're dragging the window? Why  
do you care what the numerical window size is, when the correct answer  
is "whatever makes the window fit its contents"?



___

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 arch...@mail-archive.com

Positioning document within gray area of a scroller

[Development]

We are working on a document based application which displays the  
document view within a scroller area.  Like most similar programs, the  
user can zoom in and out off the document (ie. we change the view size  
of the document view).  If he zooms out enough, our document view  
becomes smaller then the area that the scroller encloses. No problems  
so far. The scroll view draws a grey region outside the area of our  
document region, and everything works fine. We do not have to code any  
of this. However, our now small document view is pinned to the lower  
left of area being shown by the scroller view, instead of the upper  
left.


Has anyone been able to program this?

We asked this question at WWDC, and stumped several of the engineers.   
We have tried all sorts of variations of configuration under Interface  
Builder. We have set the isFlipped: method to different to change  
where the origin is, and nothing seems to work.  I know people have  
asked this question here before, but there has never been a good answer.


Our client is insisting that the document view should pin to the upper  
left hand corner. This is the way Mac applications did it under OS 9.


As always, if we find the answer, we will post it here, but for such a  
simple issue, this one has been driving us crazy.


Thank you,

Steve Sheets
___

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 arch...@mail-archive.com

Placement of window using interface builder on different size displays

[Development]

Surely this is a simple way of doing this?  (Yes, and don't call me  
Shirley).


We are creating a document based application that has various  
inspector panels that need to come up in exact position when the user  
first starts the application.  Most importantly, there are several  
windows that hug the top and side edges of the screen.  I created the  
windows using Interface Builder (IB), set their initial location, and  
it worked fine for my screen.  Then we gave it to some testers who are  
running on something other then an iMac (with different screen  
dimensions), and the inspector windows appeared all over the place.


Apparently, the position of the window, that is set using Interface  
Builder is based on having the origin a the bottom left corner (ie.  
Quartz style).  What we want to do is set the initial position of the  
window based on a top left (is. flipped) coordinate systems! This  
puzzled me since there does not seem to be any way to tell the Window  
manager to do this. There is no setting in the IB Inspector, nor is  
there any methods to override.


I am betting this is something very simple, but I have never had to  
require where a window come up before. Either the window is a document  
window, and is tiled, or it is a dialog window, and needs to be  
centered on the screen or document, or it does not matter.


Yes, I know I could at write code to programatically move the window  
is the current position at initial startup, however this would require  
hard coding each window to do this.


Help?!?

Steve Sheets
___

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 arch...@mail-archive.com

Re: Interface Builder Questions...

[Kyle Sluder]

On Sun, Jun 28, 2009 at 1:21 PM, Joar Wingfors wrote:
> You should be able to set the class of view used in the identity inspector,
> or replace the content view of the window at runtime, just like for all
> other views.

Seems icky to me, particularly when dealing with normal/textured/HUD
windows.  Also, I haven't tried out what happens when the content view
is an NSScrollView (and should therefore cause the window to draw its
resize triangle in a white box rather than just on top of the window's
contents).

--Kyle Sluder
___

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

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

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

This email sent to arch...@mail-archive.com

Re: Interface Builder Questions...

[Kyle Sluder]

On Sun, Jun 28, 2009 at 1:32 PM, Phil Hystad wrote:
> So, are you telling me that everyone else can see dynamic changes to these
> height and width pixel values but I can't?  I would submit that it is a
> little early to submit a bug report -- certainly there must be something I
> am not doing right.  Yes, I know that I can enter them in manually but I am
> more interested in trying to figure out if anything is broken with my IB or
> not.  Maybe I am seeing normal behavior.  But, if this is normal, it sure
> seems to be very awkward which does not seem like IB or Xcode.

Important question: what version of Xcode/IB are you using?  IB was
essentially rewritten for Leopard.

With that out of the way, if you have a view on your window, try
holding down the Option key while resizing the window frame.  You'll
see guides pop up showing you the relationship between the view and
the window frame.  You might need to have a view selected first.

--Kyle Sluder
___

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

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

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

This email sent to arch...@mail-archive.com

Re: Interface Builder Questions...

[Dave Carrigan]

On Jun 28, 2009, at 1:32 PM, Phil Hystad wrote:

So, are you telling me that everyone else can see dynamic changes to  
these height and width pixel values but I can't?



Enhancement requests and bug reports are both submitted to the same  
place. This would be an enhancement request.


--
Dave Carrigan
d...@rudedog.org
Seattle, WA, USA



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

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

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

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

This email sent to arch...@mail-archive.com

Re: Interface Builder Questions...

[Phil Hystad]

(3)  Again, on the window sizing inspector, if I resize the window  
using the
resize thingy in the lower right hand corner, I can see the  
updated pixel
size in the inspector, but only after I stop resizing.  If I want  
to resize
to a particular dimension, say 300 x 225 (or, whatever), it is a  
try this,
check, try that check, and so on.  Is there a way to enable the  
size values
of height and width to resize dynamically as I change the window  
size?  I
have looked all over the documentation and tried a lot of things  
but nothing

seems to make the behavior different.


Don't think so.  File a radar: http://bugreport.apple.com  You can
also enter the values directly in the text fields.



Good suggestion. Note though, that if you already know the dimension  
you want to use, it's probably easier to set it using the numeric  
input fields in the inspector directly. Also note that if you hold  
down the Command key while resizing in IB it will resize smoothly,  
and not snap to guides. This often makes pixel resizing / alignment  
a lot easier.





So, are you telling me that everyone else can see dynamic changes to  
these height and width pixel values but I can't?  I would submit that  
it is a little early to submit a bug report -- certainly there must be  
something I am not doing right.  Yes, I know that I can enter them in  
manually but I am more interested in trying to figure out if anything  
is broken with my IB or not.  Maybe I am seeing normal behavior.  But,  
if this is normal, it sure seems to be very awkward which does not  
seem like IB or Xcode.


phil

___

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 arch...@mail-archive.com

Re: Interface Builder Questions...

[Joar Wingfors]

On 28 jun 2009, at 13.05, Kyle Sluder wrote:


On Sun, Jun 28, 2009 at 12:59 PM, Phil Hystad wrote:

(1)  The default Cocoa Application created by Xcode creates a simple
application with a single window and a default menu (among other  
things I
presume).  This window has a content view which I am assuming is an  
instance
of NSView but I actually can't find out if that is true.   
Therefore, are
there any inspectors that tell me the actual class used for a  
particular

view.  The class identity part of the Inspector for the content view
suggests has a drop down that allows me to choose various classes  
but there

must be a specific class that is used already.  How do I find this?


Don't worry about it.  You shouldn't muck with the content view of a
window; the window treats it specially.  It's only exposed as an
NSView, regardless of what subclass it is actually an instance of.
Just add your views as children of it.



That's not correct. It's perfectly valid to replace the content view  
with any other view of your choosing. You're probably right in  
pointing out that it's not commonly done though. For a very simple  
window with some sort of custom view that provides all drawing, that  
would be a fine thing to do though.


You should be able to set the class of view used in the identity  
inspector, or replace the content view of the window at runtime, just  
like for all other views.



(2)  I am trying to understand how the window sizing features of  
the view
inspector relate to the window itself.  As best as I can tell, none  
of the
actual window sizing features for the content view are usable as  
they do not
really seem to do anything.  Is this true?  Is it possibly the case  
that the
content view, being bound to the window frame, is sized  
automatically based

on the window size?



Yes that's correct. The content view is always resized to fit the  
content area of the window.



(3)  Again, on the window sizing inspector, if I resize the window  
using the
resize thingy in the lower right hand corner, I can see the updated  
pixel
size in the inspector, but only after I stop resizing.  If I want  
to resize
to a particular dimension, say 300 x 225 (or, whatever), it is a  
try this,
check, try that check, and so on.  Is there a way to enable the  
size values
of height and width to resize dynamically as I change the window  
size?  I
have looked all over the documentation and tried a lot of things  
but nothing

seems to make the behavior different.


Don't think so.  File a radar: http://bugreport.apple.com  You can
also enter the values directly in the text fields.



Good suggestion. Note though, that if you already know the dimension  
you want to use, it's probably easier to set it using the numeric  
input fields in the inspector directly. Also note that if you hold  
down the Command key while resizing in IB it will resize smoothly, and  
not snap to guides. This often makes pixel resizing / alignment a lot  
easier.




(4)  And, finally, on the window sizing inspector, in the part called
"autosizing" when I click on the content view (remember, it is  
empty, just
as created by Xcode), there is an animated image that expands and  
contracts
 in size and I have absolutely no idea why it is animated or what  
it means.

 Any help?



Read up about autosizing of subviews here:





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 arch...@mail-archive.com

Re: Dispose patern (was: Re: GC pros and cons)

[Joar Wingfors]

On 28 jun 2009, at 10.34, Thomas Davie wrote:


Again, IDisposable in C# has nothing to do with early
destruction/deallocation of the object. It's purpose to is perform
explicit cleanup of external resources, resources not managed by the
GC system. For example: file handles, sockets, OS system handles,  
etc.

Calling Dispose() on a C# system does not mark the object for early
collection (AFAIK).


Oh, personally I would just let GC deal with that -- tie a handle  
under GC to them, add a finalizer on the handle, and destroy the  
reference when the handle is destroyed by the GC system.



That is not always a valid approach though. If you work with a lot of  
scarce resources in a short period of time, you might run out of them  
by outpacing the GC, taking down your app, and possibly the whole  
system.
In general, but in cases such as these in particular, I think it's  
best to separate memory management from the management of other scarce  
resources. Some sort of invalidation pattern seems to be the best  
solution that we know of right now for achieving this.
It's great that the GC allows us to not have to deal with the  
intricate details of managing memory, but I don't think that means  
that we're off the hook when it comes to thinking about object  
ownership, and the management of our object graphs.


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 arch...@mail-archive.com

Objective C Compiler Settings

[Tommy Nordgren]

Are there any compiler flags you can provide when compiling Objective  
C code,
that causes an exception to be triggered when a category implements a  
method

that is already implemented in the target class?
---
See the amazing new SF reel: Invasion of the man eating cucumbers from  
outer space.
On congratulations for a fantastic parody, the producer replies :  
"What parody?"


Tommy Nordgren
tommy.nordg...@comhem.se



___

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 arch...@mail-archive.com

Re: Interface Builder Questions...

[Kyle Sluder]

On Sun, Jun 28, 2009 at 12:59 PM, Phil Hystad wrote:
> (1)  The default Cocoa Application created by Xcode creates a simple
> application with a single window and a default menu (among other things I
> presume).  This window has a content view which I am assuming is an instance
> of NSView but I actually can't find out if that is true.  Therefore, are
> there any inspectors that tell me the actual class used for a particular
> view.  The class identity part of the Inspector for the content view
> suggests has a drop down that allows me to choose various classes but there
> must be a specific class that is used already.  How do I find this?

Don't worry about it.  You shouldn't muck with the content view of a
window; the window treats it specially.  It's only exposed as an
NSView, regardless of what subclass it is actually an instance of.
Just add your views as children of it.

> (2)  I am trying to understand how the window sizing features of the view
> inspector relate to the window itself.  As best as I can tell, none of the
> actual window sizing features for the content view are usable as they do not
> really seem to do anything.  Is this true?  Is it possibly the case that the
> content view, being bound to the window frame, is sized automatically based
> on the window size?

See above.  If you want to make a full-window view, for example, you
just add it as a child of the content view, size it to the full size
of the window (technically the full size of the content view's bounds)
and set the autoresize mask appropriately.

> (3)  Again, on the window sizing inspector, if I resize the window using the
> resize thingy in the lower right hand corner, I can see the updated pixel
> size in the inspector, but only after I stop resizing.  If I want to resize
> to a particular dimension, say 300 x 225 (or, whatever), it is a try this,
> check, try that check, and so on.  Is there a way to enable the size values
> of height and width to resize dynamically as I change the window size?  I
> have looked all over the documentation and tried a lot of things but nothing
> seems to make the behavior different.

Don't think so.  File a radar: http://bugreport.apple.com  You can
also enter the values directly in the text fields.

> (4)  And, finally, on the window sizing inspector, in the part called
> "autosizing" when I click on the content view (remember, it is empty, just
> as created by Xcode), there is an animated image that expands and contracts
>  in size and I have absolutely no idea why it is animated or what it means.
>  Any help?

It's showing you how that view will behave when the window is resized.
 As I said, don't play around with the content view, but add another
view and play around with it.  You can hit Cmd-R to run the simulator
and see how the autoresize mask behaves.

--Kyle Sluder
___

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

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

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

This email sent to arch...@mail-archive.com

Interface Builder Questions...

[Phil Hystad]

I am new to Interface Builder and I am still trying to figure out some  
subtle details of how things work.  And, my frustration level is  
growing because although I have access to a very rich set of  
documentation, a number of questions I have pondered are not  
answered.  Some of these may be rather silly but remember I am very  
new to Cocoa and Interface Builder.


(1)  The default Cocoa Application created by Xcode creates a simple  
application with a single window and a default menu (among other  
things I presume).  This window has a content view which I am assuming  
is an instance of NSView but I actually can't find out if that is  
true.  Therefore, are there any inspectors that tell me the actual  
class used for a particular view.  The class identity part of the  
Inspector for the content view suggests has a drop down that allows me  
to choose various classes but there must be a specific class that is  
used already.  How do I find this?


(2)  I am trying to understand how the window sizing features of the  
view inspector relate to the window itself.  As best as I can tell,  
none of the actual window sizing features for the content view are  
usable as they do not really seem to do anything.  Is this true?  Is  
it possibly the case that the content view, being bound to the window  
frame, is sized automatically based on the window size?



(3)  Again, on the window sizing inspector, if I resize the window  
using the resize thingy in the lower right hand corner, I can see the  
updated pixel size in the inspector, but only after I stop resizing.   
If I want to resize to a particular dimension, say 300 x 225 (or,  
whatever), it is a try this, check, try that check, and so on.  Is  
there a way to enable the size values of height and width to resize  
dynamically as I change the window size?  I have looked all over the  
documentation and tried a lot of things but nothing seems to make the  
behavior different.


(4)  And, finally, on the window sizing inspector, in the part called  
"autosizing" when I click on the content view (remember, it is empty,  
just as created by Xcode), there is an animated image that expands and  
contracts  in size and I have absolutely no idea why it is animated or  
what it means.  Any help?


Thanks,
InterfaceBuilder newbie phil

___

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 arch...@mail-archive.com

Re: UITextView symbols

[DKJ]

On 28-Jun-09, at 5:13 , Graham Cox wrote:

Surely it would make more sense to trap these keys on the input side  
- in other words override the event handlers that get called to  
handle these keys before they process the text data.



I don't know how to do this. As far as I can tell, UIEvent doesn't  
have any info about keypresses.


I hope I'm missing something.

dkj
___

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

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

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

This email sent to arch...@mail-archive.com

Re: Dispose patern (was: Re: GC pros and cons)

[Thomas Davie]

On 28 Jun 2009, at 19:27, Stephen J. Butler wrote:

On Sun, Jun 28, 2009 at 11:06 AM, Thomas Davie  
wrote:

On 28 Jun 2009, at 17:47, Konrad Neitzel wrote:
I still have to read much more about the GC used within Objective- 
C /
Cocoa so I am not sure, if I am not writing some kind of  
"bullshit" from

your view:

Isn't it possible to simply flag an object to be removed? Is there a
dispose pattern in Objective-C?
(e.g. http://www.codeproject.com/KB/cs/idisposable.aspx describes  
such a

pattern in C#)

Something like that would simply more the world together again.  
That way,
the developer has some more control, the GC has less work and all  
are maybe

happy?

So is there such an Dispose Pattern in Objective-C using a GC or  
is there

nothing like that?


That sounds exactly like reference counting – and it suffers from  
all the
well known problems (like retain cycles).  The point here is that  
you don't
*want* the developer to have control, the developer (myself  
included) is
really really bad at doing this, and introduces a *lot* of bugs in  
the

process.

The option for it of course will keep everyone happy, but that  
doesn't mean

it should be encouraged ;)


Again, IDisposable in C# has nothing to do with early
destruction/deallocation of the object. It's purpose to is perform
explicit cleanup of external resources, resources not managed by the
GC system. For example: file handles, sockets, OS system handles, etc.
Calling Dispose() on a C# system does not mark the object for early
collection (AFAIK).


Oh, personally I would just let GC deal with that -- tie a handle  
under GC to them, add a finalizer on the handle, and destroy the  
reference when the handle is destroyed by the GC system.


Bob

___

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 arch...@mail-archive.com

Re: Dispose patern (was: Re: GC pros and cons)

[Stephen J. Butler]

On Sun, Jun 28, 2009 at 11:06 AM, Thomas Davie wrote:
> On 28 Jun 2009, at 17:47, Konrad Neitzel wrote:
>> I still have to read much more about the GC used within Objective-C /
>> Cocoa so I am not sure, if I am not writing some kind of "bullshit" from
>> your view:
>>
>> Isn't it possible to simply flag an object to be removed? Is there a
>> dispose pattern in Objective-C?
>> (e.g. http://www.codeproject.com/KB/cs/idisposable.aspx describes such a
>> pattern in C#)
>>
>> Something like that would simply more the world together again. That way,
>> the developer has some more control, the GC has less work and all are maybe
>> happy?
>>
>> So is there such an Dispose Pattern in Objective-C using a GC or is there
>> nothing like that?
>
> That sounds exactly like reference counting – and it suffers from all the
> well known problems (like retain cycles).  The point here is that you don't
> *want* the developer to have control, the developer (myself included) is
> really really bad at doing this, and introduces a *lot* of bugs in the
> process.
>
> The option for it of course will keep everyone happy, but that doesn't mean
> it should be encouraged ;)

Again, IDisposable in C# has nothing to do with early
destruction/deallocation of the object. It's purpose to is perform
explicit cleanup of external resources, resources not managed by the
GC system. For example: file handles, sockets, OS system handles, etc.
Calling Dispose() on a C# system does not mark the object for early
collection (AFAIK). It still has to pass through the GC like any other
object. In fact, disposed objects may still be useful long after they
are disposed (perhaps they contain connection statistics, fetched
data, or something else).

Objective-C already has an informal IDisposable. Any class with a
"close" message is essentially doing the same thing.
___

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 arch...@mail-archive.com

Re: GC pros and cons

[Quincey Morris]

On Jun 28, 2009, at 04:39, Michael Ash wrote:


On Sat, Jun 27, 2009 at 9:47 PM, Bill Bumgarner wrote:


When a CF object is created, it is CFRetain()ed and, thus, the  
collector
will ignore it.  If it is then managed entirely through a balanced  
set of
CFRelease() and CFRetain() calls, it'll work just like it does  
under non-GC.


If you call CFMakeCollectable(), that'll effectively balance the  
CFRetain()

at creation while making the collector aware of the object.

Thus, no real edge case here (as designed).


Right, but once you do the final CFRelease and the retain count hits
zero, objects in the default zone aren't destroyed, but merely become
eligible for collection. This modifies their lifetimes and may cause
their destruction code to run at a different time and in a different
context. This could conceivably cause trouble for CF containers with
custom callbacks that were built with the assumption that they would
run synchronously with the final CFRelease.


I think the answer is in Bill's "entirely", above.

Without CFMakeCollectable, the final CFRetain will trigger the calling  
of (a hypothetical) CFDispose with the traditional timing (i.e.  
immediately, we assume, somewhat at our peril).


After CFMakeCollectable in a GC-enabled environment, the final  
CFRetain (if there is one, if the retain count was greater than 1 at  
the time CFMakeCollectable was called) will just discard *the* strong  
reference that the retain count was maintaining. This will trigger the  
calling of (a hypothetical) CFFinalize with the usual timing (i.e.  
when the collector runs, after there are no other strong references  
remaining).


Thus GC-unaware code gets the behavior at CFRelease time that it  
expects (somewhat at its peril), whether or not it is running in a GC- 
enabled environment.



___

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 arch...@mail-archive.com

Re: Dispose patern (was: Re: GC pros and cons)

[Thomas Davie]

On 28 Jun 2009, at 17:47, Konrad Neitzel wrote:


Thomas Davie  schrieb am 27.06.2009 09:56:31:


On 27 Jun 2009, at 01:27, James Gregurich wrote:



GC isn't nirvana.  it does have its perils and issues, and you have
to be aware of them and code around them. You can't just turn it on
and some how everything magically works. There is no perfect
solution to memory management. I prefer a  solution where I manage
the dependencies and objects go away in an orderly fashion based on
the dependency graph for those objects.



Uhhh, you mean a garbage collector?  That's exactly what it does --
frees objects when nothing depends on them any more.


But a garbage collector must be able to detect an object which  
memory can / must be released. And for all this, the system has to  
do some work.


As must your program do if it keeps track of memory manually.  Are you  
betting you can make that less work than a bunch of compiler engineers  
can?  Note, this actually isn't a bad bet with GC, but it's not a good  
one either.


I still have to read much more about the GC used within Objective- 
C / Cocoa so I am not sure, if I am not writing some kind of  
"bullshit" from your view:


Isn't it possible to simply flag an object to be removed? Is there a  
dispose pattern in Objective-C?
(e.g. http://www.codeproject.com/KB/cs/idisposable.aspx describes  
such a pattern in C#)


Something like that would simply more the world together again. That  
way, the developer has some more control, the GC has less work and  
all are maybe happy?


So is there such an Dispose Pattern in Objective-C using a GC or is  
there nothing like that?


That sounds exactly like reference counting – and it suffers from all  
the well known problems (like retain cycles).  The point here is that  
you don't *want* the developer to have control, the developer (myself  
included) is really really bad at doing this, and introduces a *lot*  
of bugs in the process.


The option for it of course will keep everyone happy, but that doesn't  
mean it should be encouraged ;)


Bob___

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 arch...@mail-archive.com

Re: Base SDK and deployment target Q

[Steve Christensen]

Building against the 10.4 SDK should root out any 10.5-only method  
calls or classes at -compile- time, giving you an opportunity to  
check that you're doing the appropriate runtime check before using  
them. It will not particularly help you at runtime. And as I recall,  
those method calls show up as warnings ("class Foo may not respond to  
bar:").


steve


On Jun 27, 2009, at 6:50 PM, Lorenzo Thurman wrote:

Thanks for your reply. I wasn't sure that switching the SDK would  
be good enough to test. My 10.4 box died a couple of weeks ago, so  
I have to have someone else run the app under 10.4. It's kind of a  
pain, but if I can just switch the SDK and run it under Leopard,  
that's fine.

Thanks again.

On Sat, Jun 27, 2009 at 8:42 PM, Steve Christensen  
 wrote:


I don't believe such a switch exists since it's not really a  
compiler issue: using a 10.5+ method is completely legal for your  
configuration. A quick way to check what 10.5 methods you're using  
would be to set the SDK to 10.4 temporarily and see what errors  
you get. You can then make sure you're doing the appropriate  
runtime checks.


steve

On Jun 27, 2009, at 6:34 PM, Lorenzo Thurman wrote:

I have a program which needs to run under 10.4, but I used a  
method that
is only defined for 10.5. No biggie, it was easy enough to  
replace it
with something that works for 10.4. The problem is that I didn't  
find
this out until I ran the app under 10.4. My apps deployment  
target is

set to 10.4, and the base SDK is set for 10.5. My question is:
If I inadvertently use a 10.5 only method, is there a way for me  
to be

warned at compile time? I know I can use define's to use what's
appropriate for a given target, but what if I overlook the fact  
that a
method is only for 10.5? is there a compiler switch or something  
that I

can enable to tell me this?

___

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 arch...@mail-archive.com

[ANN] CocoaREST - Cocoa library for RESTful services

[Steven Degutis]

Hey all,
I recently released the source code to CocoaREST under a BSD-style license.
Basically it's a Cocoa library that lets developers interact with RESTful
services quite easily. (Emphasis is on ease of use!) Right now Twitter is
the main supported service, but support for many more services are underway
and it's quite easily expandable if you'd like to add support for new
services or extend support for current ones (ie, extending the Twitter
support to use their Search API).

You can check out the source code, sample app, readme file, and
documentation over at http://github.com/sdegutis/CocoaREST/tree/master

If you get some use out of this library, let me know! And feel free to
message me with any changes or additions you've made; if they work, I'll add
them to the library and give credit where it's due.

-Steven
___

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 arch...@mail-archive.com

Re: UITextView symbols

[Graham Cox]

On 28/06/2009, at 9:26 AM, DKJ wrote:

I detect the Return key by checking whether the input string is  
equal to @"\n". But how would I detect the back-delete key? @"\b"  
doesn't do it. And I can't seem to find any docs that list these  
codes.


Surely it would make more sense to trap these keys on the input side -  
in other words override the event handlers that get called to handle  
these keys before they process the text data.


--Graham


___

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

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

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

This email sent to arch...@mail-archive.com

Re: GC pros and cons

[Michael Ash]

On Sat, Jun 27, 2009 at 9:47 PM, Bill Bumgarner wrote:
> On Jun 27, 2009, at 8:38 PM, Michael Ash wrote:
>>
>> (And I only say "almost" because I can only assume there's a corner
>> case out there somewhere with CoreFoundation-using code, since CF
>> objects are also garbage collected, but I am not actually aware of
>> any.)
>
> When a CF object is created, it is CFRetain()ed and, thus, the collector
> will ignore it.  If it is then managed entirely through a balanced set of
> CFRelease() and CFRetain() calls, it'll work just like it does under non-GC.
>
> If you call CFMakeCollectable(), that'll effectively balance the CFRetain()
> at creation while making the collector aware of the object.
>
> Thus, no real edge case here (as designed).

Right, but once you do the final CFRelease and the retain count hits
zero, objects in the default zone aren't destroyed, but merely become
eligible for collection. This modifies their lifetimes and may cause
their destruction code to run at a different time and in a different
context. This could conceivably cause trouble for CF containers with
custom callbacks that were built with the assumption that they would
run synchronously with the final CFRelease.

(Of course they should not *have* such assumptions, but that doesn't
mean they won't.)

Or did I misunderstand something?

Mike
___

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

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

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

This email sent to arch...@mail-archive.com