Re: animating addSubview with iOS4

[Martin Linklater]

Thanks for your replies guys - that makes a lot of sense now 8)

On 2 Mar 2011, at 12:06, Andreas Grosam wrote:

> 
> On Mar 2, 2011, at 12:42 PM, Andreas Grosam wrote:
> 
>> - (void) viewDidLoad {
>>   [super viewDidLoad];
>> 
>>   // Create the button:
>>   // ...
>> 
>>   [self performSelector:@selector(addButtonWithAnimation) withObject:nil 
>> afterDelay:0.0];
>> }
> 
> or - possibly more efficient:
> 
> - (void)viewDidLoad {
>[super viewDidLoad];
> 
>// Create the button:
>// ...
> 
>dispatch_async(dispatch_get_main_queue(), ^{
>[UIView transitionWithView:self.view 
>  duration:1.0
>   options:UIViewAnimationOptionTransitionCurlUp 
>animations:^{ [self.view addSubview:self.button]; }
>completion:NULL];
>});
> }
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/mslinklater%40gmail.com
> 
> This email sent to mslinkla...@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: Editing a list of NSMutableStrings

[Joanna Carter]

Hi Quincey

> I think I win by a mile. ☺

You certainly do ☺ I have been away from "bare metal" C programming for so long 
that I had forgotten about the way C handles array manipulation.

> However, in any likely scenario, the actual difference in performance is 
> likely to be unmeasurable. To make a noticeable difference, you either have 
> to be mutating the array of strings thousands of times a second, or have tens 
> of thousands of strings in your array.

Yup, that's what I would have expected. But, because I usually end up teaching 
this stuff, it always helps to pass on good information.

I just need to spend even more time getting into the Cocoa way.

Thanks again

Joanna

--
Joanna Carter
Carter Consulting

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: Outlets Not Connected In awakeFromNib

[Uli Kusterer]

On 02.03.2011, at 10:54, Andreas Grosam wrote:
> I have a very basic custom UIViewController with its own associated nib file. 
> This view controller is the "root view controller" of a Navigation Controller 
> which is itself embedded within a Split View Controller which is defined in 
> another nib - say the main.nib.

tl;dr

But do you have any objects that are part of several NIBs? I.e. a view 
controller that is instantiated by one NIB, but the view controller has a NIB 
of its own that it loads in turn? In that case, you'll get -awakeFromNib twice. 
Once when the containing NIB is instantiated, and a second time after you load 
the containED NIB.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.masters-of-the-void.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: Outlets Not Connected In awakeFromNib

[Andreas Grosam]

On Mar 3, 2011, at 12:31 PM, Uli Kusterer wrote:

> On 02.03.2011, at 10:54, Andreas Grosam wrote:
>> I have a very basic custom UIViewController with its own associated nib 
>> file. This view controller is the "root view controller" of a Navigation 
>> Controller which is itself embedded within a Split View Controller which is 
>> defined in another nib - say the main.nib.
> 
> tl;dr
> 
> But do you have any objects that are part of several NIBs? I.e. a view 
> controller that is instantiated by one NIB, but the view controller has a NIB 
> of its own that it loads in turn? In that case, you'll get -awakeFromNib 
> twice. Once when the containing NIB is instantiated, and a second time after 
> you load the containED NIB.

No, there is just two nib files, the main.nib and the RootViewController.nib.

You can easily create this scenario from a template project in Xcode. For iOS 
use a Navigation Based Application.

The "main.nib" is defined as follows:

File's OwnerUIApplication
First Responder
App DelegateNavigationBasededAppDelegate
Window
Navigation Controller   
   Navigation Bar
   Root View Controller RootViewController -> Nib Name = 
"RootViewController.nib"


Note: "Root View Controller" isn't embedded within the main.nib, instead it has 
its own nib "RootViewController.nib". In order to reference the nib file from 
within the main nib, the "nib Name" property of the Root View Controller 
(within the main.nib) is defined and its value is "RootViewController" - which 
shall be the nib for this object.



In order to create this in a sample, you need to define an outlet in the root 
view controller, e.g.:

@interface RootViewController ... {
IBOutlet UIView* testView;
}
@property (nonatomic, retain) IBOutlet UIView* testView;
@end

Then, in IB, add this view and connect the outlet as appropriate.


Then, the "RootViewController.nib" is defined as:

File's Owner   RootViewController
First Responder
Table View
Test View


The RootViewController has an Outlet 'testView' which references "Test View" 
within the same nib (RootViewController.nib).


When -awakeFromNib is sent to the root view controller, the outlet 'testView' 
is not connected. The message is sent during *loading the main nib*. The root 
view controller does not receive another -awakeFromNib message.


Andreas




___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: Outlets Not Connected In awakeFromNib

[Andreas Grosam]

On Mar 2, 2011, at 4:53 PM, glenn andreas wrote:

> 
> On Mar 2, 2011, at 3:54 AM, Andreas Grosam wrote:
> 
> What's going on is that awakeFromNib is called when the nib containing the 
> object is instantiated.  In this case, it is the main nib (which is where the 
> root view controller "lives").
> 
> However, a view controller's nib ("MyRootViewControler.nib") isn't loaded 
> until it is actually needed, at which point the view controller gets 
> "viewLoaded" message, and so, until that time, any connections between the 
> view controller and things loaded from MyRootViewController.nib will be nil.

Yes, this is how it is. However, according the docs:

"When an object receives an awakeFromNib message, it is guaranteed to have all 
its outlet and action connections already established."

The object is the root view controller, which happens to be a file's owner for 
its own nib, which is referenced from this main nib.

At the time awakeFromNib is sent to the root view controller, the root view 
controller's outlets whose target exists in the main nib are connected. 
However, none of the outlets whose target objects exist in its corresponding 
nib "MyRootViewController nib" are connected.

There is nothing in the docs mentioning this case.

> <...>
> 
> The whole purpose of having separate nibs is to avoid recursively loading 
> everything all at once - if that view is never displayed (say, on a tab bar 
> controller tab that the user never selects), its nib will never be loaded.
I understand the reason why this externally defined nib isn't loaded. However, 
awakeFromNib will be sent to the object which is exactly the file's owner of 
this external nib at the time when the main nib is loaded - as if this file's 
owner is considered to be "unarchived, instantiated and initialized".

Well, the net effect of this all is, during awakeFromNib, it is NOT guaranteed 
that ALL the receiver's outlets are connected.   ;)


Regards
Andreas___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: Help with simple NSView animation...

[Carlos Eduardo Mello]

Just in case someone was following...

 As I couldn't figure out a simple way to animate my view growing  
while drawing (my drawing needs to be updated for each step of the  
way, depending on the view's size...), as a workaround I hid the view  
out of sight by embeding it in a dumb transparent view and animated it  
comming into sight instead of growing into sight. The result was  
actually pretty good (maybe even  better than the initial idea).



___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: UIView animation (backgroundColor) + drawRect:

[Roland King]

As ever, thanks very much David. I figured there was *something* going on when 
drawRect: was defined but I wouldn't have figured out what without this help. 

In this case a crossfade in every case for that particular view works 
perfectly, I implemented what you suggested and it looks so much better, it's 
amazing the difference that even a .3-.5 second smooth transition can make, 
just takes the edge off something which was quite harsh before, looks much more 
professional. 

Got the point (again) on using simple subviews when possible, a mistake I've 
made before. In this particular case I don't think that was going to work, but 
I'm very happy with what I have now. 

Andreas, thanks for your reply too. You had pretty much exactly the same 
thoughts I did and we both tried the same ideas, with the same 
..AllowAnimatedContent etc and got the same results; hope David's reply was 
useful to you too, it goes in my 'keepers' file. 

On 03-Mar-2011, at 5:10 AM, David Duncan wrote:

> On Mar 2, 2011, at 5:12 AM, Roland King wrote:
> 
>> I was trying to animate the backgroundColor of one of my UIView subclasses 
>> yesterday using 
>> 
>>  [ UIView animateWithDuration:2.0 animations:^{ [ myView 
>> setBackgroundColor:someColor ]; } ];
>> 
>> but no matter what the duration set, the background color was changing 
>> instantly. Whilst looking to see if there were two places I called 
>> setBackgroundColor: (there weren't) I realized that my UIView subclass has 
>> its own drawRect: method (this view is basically a piece of paper with some 
>> lines drawn on it, so it needs a custom drawRect: method). Commenting that 
>> out, the view background animated properly, but of course I had no content. 
>> Even just adding an empty drawRect: method was enough to defeat the 
>> animation. 
> 
> 
> When you implement -drawRect:, the background color of your view is then 
> drawn into the associated CALayer, rather than just being set on the CALayer 
> as a style property. Now Core Animation can animate both transitions, but 
> UIView disables the animation of a layer's contents, which thus prevents you 
> from getting a contents crossfade (as in the vast majority of cases this 
> wouldn't be what you want).
> 
> The crossfade may be exactly what you want in this case. Likely the best way 
> to defeat UIView's override in this case may be to create a subclass of 
> CALayer that overrides -actionForKey:. In that override, you would check for 
> the @"contents" key and return a CABasicAnimation ([CABasicAnimation 
> animation] should do it) and in all other cases return what the default 
> implementation does. This has the downside that you will *always* cross fade 
> and you won't be able to integrate with UIKit's animation APIs (you just get 
> animation for contents on all the time).
> 
> Another solution would be to use a super view that contains just the 
> background color and have your lines composited over it (assuming they are 
> simple lines this could be done with simple subviews that are sized for each 
> line). This would allow you to avoid -drawRect: entirely, which would allow 
> you to animate the background color and may offer some memory usage benefits 
> (if you can use subviews). 
> --
> David Duncan
> 

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: table view and custom cell optimization problem

[jonat...@mugginsoft.com]

On 3 Mar 2011, at 04:06, Nick Rogers wrote:

> Hi,
> I have a table view with the custom cell class assigned to its only column in 
> awakeFromNib method using setDataCell:.
> Then I'm doing some drawing in drawInteriorWithFrame: of the NSCell subclass.
> The problem is that drawing include four lines of text and an image and a few 
> lines using NSBezierPath.
> 
> This is relatively time consuming and hence when I scroll the table view, the 
> scrolling is not that smooth and is a bit jerky.
> 
> Is there a way to do all this custom drawing in a manner that could make the 
> scrolling faster.

I use the following approach in an NSView but you can adapt it.

The idea is to cache your background (that is common to all cells) in an 
NSImage instance.
When the cell needs drawn you copy from the image cache into your focus locked 
view.
Then you can draw the unique cell content - text etc.

Obviously when the cell size changes you have to regenerate your background 
image cache.

- (void)drawRect:(NSRect)rect 
{   

if (!_imageCache) {

// draw to image cache
_cacheRect  = [self bounds];
_imageCache = [[NSImage alloc] initWithSize:_cacheRect.size];
[_imageCache lockFocus];

// draw background with beziers etc

[_imageCache unlockFocus]; 
}

[_imageCache drawInRect:rect fromRect:rect 
operation:NSCompositeSourceOver fraction:1.0f];

// now draw unique foreground
}   




Regards

Jonathan Mitchell

Developer
Mugginsoft LLP
http://www.mugginsoft.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: The 'Open with' option is automatically changed with my app when my app is installed

[Ken Thomases]

On Mar 3, 2011, at 12:12 AM, Deepa wrote:

> I am developing an Desktop application which organizes and plays movie files. 
> So, I have added the mp4, mov, avi, m4v (mp4, mov, avi, m4v extensions) as 
> document type under Properties of my application target.
> The problem is that when the user installs my app in Applications folder of 
> his system, the default option for opening the mp4 movie file changes to 
> Voila from QuickTime Player automatically. The default option is nothing but 
> the 'Open With' option provided in the Info window of a file. This happens 
> for most of the users. Why is this happening? How do I solve this?

Here's what I wrote in another similar thread recently: 
http://markmail.org/message/kf7lxgpu52nn34k2

Cheers,
Ken

___

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

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

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

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

Re: Outlets Not Connected In awakeFromNib

[Kyle Sluder]

On Thu, Mar 3, 2011 at 4:37 AM, Andreas Grosam  wrote:
> At the time awakeFromNib is sent to the root view controller, the root view 
> controller's outlets whose target exists in the main nib are connected. 
> However, none of the outlets whose target objects exist in its corresponding 
> nib "MyRootViewController nib" are connected.
>
> There is nothing in the docs mentioning this case.

-awakeFromNib is sent to every object in the nib after all the
connections defined in the nib have been established. Since cross-nib
connections are not allowed, the documentation has no need to mention
your scenario.

Perhaps the documentation should be rephrased to say "all connections
defined in the nib are guaranteed to have been reestablished" rather
than guaranteeing that all outlets have been connected, which is
inaccurate.

On Thu, Mar 3, 2011 at 4:27 AM, Andreas Grosam  wrote:
> When -awakeFromNib is sent to the root view controller, the outlet 'testView' 
> is not connected. The message is sent during *loading the main nib*. The root 
> view controller does not receive another -awakeFromNib message.

>From the Resource Programming Guide:

"In iOS, this message [-awakeFromNib] is sent only to the interface
objects that were instantiated by the nib-loading code. It is not sent
to File’s Owner, First Responder, or any other proxy objects."

So the answer to your problem is use the UIViewController methods to
find out when your RootViewController has loaded its view.

--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: Help with simple NSView animation...

[Matt Neuburg]

On Thu, 03 Mar 2011 10:54:32 -0300, Carlos Eduardo Mello 
 said:
>Just in case someone was following...
>
>  As I couldn't figure out a simple way to animate my view growing  
>while drawing (my drawing needs to be updated for each step of the  
>way, depending on the view's size...), as a workaround I hid the view  
>out of sight by embeding it in a dumb transparent view and animated it  
>comming into sight instead of growing into sight. The result was  
>actually pretty good (maybe even  better than the initial idea).
>

Your "growing-while-drawing" problem is simply a special case of wanting to 
animate your own custom property. If you define your own animatable property, 
then your drawLayer:inContext: is called at each "frame" of the animation, 
giving you a chance to redraw. So, you could change your frame plus a custom 
animatable property, and they will be animated together (and therefore you'll 
get to redraw the presentation layer on every frame) when the redraw moment 
arrives and the animation is actually performed. m.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 4!
http://www.apeth.net/matt/default.html#iosbook___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: NSAttributedString crashes

[Matt Neuburg]

On Tue, 01 Mar 2011 16:15:09 +0700, "Gerriet M. Denkmann" 
 said:
>
>On 1 Mar 2011, at 15:53, Kyle Sluder wrote:
>
>> On Tue, Mar 1, 2011 at 12:45 AM, Gerriet M. Denkmann
>>  wrote:
>>> So obviously NSAttributedString does NOT return [ [ aFont retain ] 
>>> autorelease ] but just some internal pointer.
>>> 
>>> Is this documented somewhere?
>> 
>> In the Memory Management Programming Guide:
>> http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/MemoryMgmt/Articles/mmAccessorMethods.html%23//apple_ref/doc/uid/TP40003539-SW6
>> 
>> --Kyle Sluder
>
>As far as I can see, this article talks about different ways to implement 
>setters and getters.
>Do you want to imply that, whenever I get some object from AppKit, I have to 
>retain it until I no longer need it?
>
>Would be a safe thing to do. But also tedious. And in all my past experience 
>this was never necessary. 
>So I thought that the "Technique 1" of the linked article (returning 
>[[someObject retain] autorelease]) was the standart practice employed by 
>AppKit.

I've been thinking about this exchange, and I would propose that you consider 
it like this:

Suppose you've got an NSArray and you fetch its element objectAtIndex:0. And 
suppose you now let go of the array (release) and it is destroyed. Do you 
expect the fetched element to persist without your having retained it? You do 
not; you know darned well that a collection doesn't behave like that. The 
collection *owns* its elements and will release them when it is released. All 
you got when you called objectAtIndex:0 was a pointer. If you want a share in 
its ownership, you must *take* ownership.

Here's another example. Suppose you've got a UIView and you ask for its 
subviews. Do you imagine that asking for this property gives you ownership of 
those subviews? You do not. Similarly for *any* property of *any* object. You 
*never* imagine that a fetched property is somehow magically *giving* you 
ownership; it's just showing you a value.

So what I'm trying to show you is that when you've got an object that owns 
stuff, you *never* expect that that object will dispense the stuff it owns 
while handing you a share in ownership. You *always* take ownership if you want 
that stuff to persist beyond the object that dispenses them. Ownership is 
*never* something you are magically given. It is always something that you must 
take if you want it.

So, what I'm saying is, an NSAttributedString is like that. When it hands you 
that font, it's like an NSDictionary handing you some value for a particular 
key.

What you *can* rely on is that a ***factory method*** will hand you an 
autoreleased object. So, [NSArray array] hands you an autoreleased array; it 
won't vanish right this second, but it will vanish when your code comes to an 
end, unless you retain it. You may be confusing this with that. Even in that 
case you don't have ownership; you just have some extra persistence time while 
your code continues to run. And this makes sense, because there is no other 
owning object.

Hope that helps.

m.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 4!
http://www.apeth.net/matt/default.html#iosbook___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: Help with simple NSView animation...

[Carlos Eduardo Mello]

Hi Matt,

thanks for the reply.  I 'll definetly dig into that as soon as I am  
done with core GUI stuff (need to get my app working for a -prototype  
demo)...I was trying to add a quick touch of animation so that my demo  
would look cooler and  just thought that it might be possible to do it  
with NSView calls without using layers, I mean, using the animator.   
I'll go through the Core Animation Guide to get a better handle on  
CALayer, etc.


Thank You again for your time.

On Mar 3, 2011, at 2:57 PM, Matt Neuburg wrote:

On Thu, 03 Mar 2011 10:54:32 -0300, Carlos Eduardo Mello > said:

Just in case someone was following...

As I couldn't figure out a simple way to animate my view growing
while drawing (my drawing needs to be updated for each step of the
way, depending on the view's size...), as a workaround I hid the view
out of sight by embeding it in a dumb transparent view and animated  
it

comming into sight instead of growing into sight. The result was
actually pretty good (maybe even  better than the initial idea).



Your "growing-while-drawing" problem is simply a special case of  
wanting to animate your own custom property. If you define your own  
animatable property, then your drawLayer:inContext: is called at  
each "frame" of the animation, giving you a chance to redraw. So,  
you could change your frame plus a custom animatable property, and  
they will be animated together (and therefore you'll get to redraw  
the presentation layer on every frame) when the redraw moment  
arrives and the animation is actually performed. m.


--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 4!
http://www.apeth.net/matt/default.html#iosbook


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: Help with simple NSView animation...

[Matt Neuburg]

On Mar 3, 2011, at 10:52 AM, Carlos Eduardo Mello wrote:

> thanks for the reply.  I 'll definetly dig into that as soon as I am done 
> with core GUI stuff (need to get my app working for a -prototype demo)...I 
> was trying to add a quick touch of animation so that my demo would look 
> cooler and  just thought that it might be possible to do it with NSView calls 
> without using layers, I mean, using the animator.  I'll go through the Core 
> Animation Guide to get a better handle on CALayer, etc.

I don't know how well animator-based animation melds with layer-based 
animation, especially on Mac OS X where NSView and CALayer spend most of their 
time glowering at each other angrily over the fence. :) Things are different in 
iOS where the whole framework was built up from scratch and UIView and CALayer 
are integrated completely (a UIView is just a CALayer plus touches, as someone 
has said). But in general my view is: don't be afraid of Core Animation. It is 
not difficult and it puts the power directly into your hands.

m.

--
matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/
pantes anthropoi tou eidenai oregontai phusei
Among the 2007 MacTech Top 25, http://tinyurl.com/2rh4pf
Programming iOS 4! http://www.apeth.net/matt/default.html#iosbook
RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
TidBITS, Mac news and reviews since 1990, http://www.tidbits.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: animating addSubview with iOS4

[Matt Neuburg]

On Thu, 03 Mar 2011 10:32:18 +, Martin Linklater  
said:
>Thanks for your replies guys - that makes a lot of sense now

Except that as Robert Vojta told you (and as Luke Hiesterman has clearly stated 
on other occasions) it is wrong to assume that viewDidLoad means that the view 
is now in the *interface*, or even that it is *about* to be put into the 
interface, so it makes no sense to assume that an animation launched from 
viewDidLoad, even with delayed performance, will be seen by the user. It might 
appear to work, but it's still wrong. So this solution is incorrect:

>> On Mar 2, 2011, at 12:42 PM, Andreas Grosam wrote:
>> 
>>> - (void) viewDidLoad {
>>>   [super viewDidLoad];
>>> 
>>>   // Create the button:
>>>   // ...
>>> 
>>>   [self performSelector:@selector(addButtonWithAnimation) withObject:nil 
>>> afterDelay:0.0];
>>> }

The proper way to trigger an animation when the view first appears is in 
viewDidAppear:, using a static variable or instance variable as a flag so that 
this happens only the first time.

See Luke's dictum on the matter in this thread:

http://www.cocoabuilder.com/archive/cocoa/297736-why-can-a-modal-view-controller-present-another-in-viewdidload.html

Note that I suggested delayed performance in viewDidLoad and he slapped me 
around for a while. :) So now I'm warning everyone else! :))

m.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 4!
http://www.apeth.net/matt/default.html#iosbook___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: NSAttributedString crashes

[Quincey Morris]

On Mar 3, 2011, at 10:10, Matt Neuburg wrote:

> What you *can* rely on is that a ***factory method*** will hand you an 
> autoreleased object. So, [NSArray array] hands you an autoreleased array; it 
> won't vanish right this second, but it will vanish when your code comes to an 
> end, unless you retain it. You may be confusing this with that. Even in that 
> case you don't have ownership; you just have some extra persistence time 
> while your code continues to run. And this makes sense, because there is no 
> other owning object.

EXCEPT:

What you say can't be literally true. In the non-factory-method case of a 
returned property value, you *do* have some extra persistence time, because you 
*must* have some extra persistence time, because you need to be able to retain 
the returned value before it disappears:

id someValue = [someObject someProperty];
[someValue retain]; // someValue must persist at least this long

Of course, in the simplest case where multiple threads aren't involved, this 
looks safe enough, because nothing should cause 'someValue' to dealloc before 
the retain.

So, the question arises: how long are you permitted to go before you need to do 
the retain? AFAIK there's no actual answer to that question, but the pragmatic 
answer has always been: until the next drain of an autorelease pool that might 
contain the object (that is, often, until you return to the main event loop), 
and that's a little hard to predict in the general case that might involve 
local autorelease pools.

What I'm trying to say is that deciding whether to be "safe"/"tedious" is, 
theoretically, guesswork. In practice, the usual heuristic is to assume a 
retained-autoreleased object, and to fix the crashes on a case by case basis -- 
which is what Gerriet just had to do.

EXCEPT:

> Suppose you've got an NSArray and you fetch its element objectAtIndex:0. And 
> suppose you now let go of the array (release) and it is destroyed. Do you 
> expect the fetched element to persist without your having retained it? You do 
> not; you know darned well that a collection doesn't behave like that. The 
> collection *owns* its elements and will release them when it is released. All 
> you got when you called objectAtIndex:0 was a pointer. If you want a share in 
> its ownership, you must *take* ownership.

And the one common zero-extra-persistence-time case that you didn't quite 
mention:

id someValue = [someArray objectAtIndex: 0];
[someArray removeObjectAtIndex: 0];
[someValue retain]; // too late!

I think both of these are essentially different from Gerriet's case, because 
there is an obvious change-of-ownership "event" between getting the 
non-retained pointer and retaining it. The only real connection between the two 
scenarios is that you end up with a pointer to a possibly dead object, unless 
you take care.

AND:

Things are both better and worse under garbage collection. Worse, because there 
is no extra persistence time, because the GC thread could run at any moment. 
Better, because the the compile-time scoping of variables *usually* creates the 
effect of extra persistence time, until the run-time equivalent of the "}" of 
the block containing their declaration. Except when optimization shortens the 
effective scope. But that's a different discussion.


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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

NSButton disappears when I turn on "Wants Core Animation Layer" in IB

[Michael Crawford]

I have a view with a few textured NSButton objects placed on top of a 
contentView.  Since a couple of the buttons overlap and one uses transparency 
and requires a shadow, I turned on the wants-layer feature for that button.  
The button still looks a little funky in the corner where it overlaps another 
button, so I turn on wants-layer for the entire view by setting wants-layer for 
the contentView containing the buttons.  When I run the application, the button 
with the shadow is invisible.  It is there, I can click on it with the mouse or 
press the key bound to the button and the app responds appropriately.  If I 
turn off wants-layer for the contentView and run the app again, I can now see 
the button, though it looks wrong because of the missing Core Animation 
features with transparency and shadow.

The other half of the puzzle is that this view used to work fine.  It broke 
when I added a second window to the app, which also uses Core Animation.

Anyone seen anything remotely like this?

http://dl.dropbox.com/u/4920112/Screenshots/Screen%20shot%202011-03-03%20at%203.17.57%20PM.PNG
http://dl.dropbox.com/u/4920112/Screenshots/Screen%20shot%202011-03-03%20at%203.18.26%20PM.PNG
http://dl.dropbox.com/u/4920112/Screenshots/Screen%20shot%202011-03-03%20at%203.19.13%20PM.PNG

-Michael
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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

Setting a delegate on a UITextField

[Jon Sigman]

I'm trying to set up a delegate on a UITextField so I can know when the user 
has 
finished editing. 
My delegate is my main view controller:

@interface MainViewController : UIViewController 
{
. . .
}

and in the implementation file I have:

- (void) textFieldDidEndEditing:(UITextField)textField
{
// do stuff
}

I set the delegate on the textfield like this:

nameTextField.delegate = (id )mainViewController;

It all builds but at runtime my delegate method never gets called.
What am I overlooking?
iOS 4.2


  
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: Setting a delegate on a UITextField

[Phillip Mills]

On 2011-03-03, at 5:01 PM, Jon Sigman wrote:
> 
> What am I overlooking?

First question: Is your 'nameTextField' truly non-nil when you set its delegate?

Second question: What do you define as "finished editing"?



___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: Setting a delegate on a UITextField

[Jon Sigman]

On Thu, March 3, 2011 2:19:30 PM Phillip Mills  wrote:

> First question: Is your 'nameTextField' truly non-nil when you set its 
>delegate?

Good call. It was being set before the -viewDidLoad method got invoked. It all 
works now!

> Second question: What do you define as "finished editing"?


When the user touches the "Return" button on the keypad. Is that a poor 
assumption?
Thanks!
-Jon



  
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: NSAttributedString crashes

[Gerriet M. Denkmann]

On 4 Mar 2011, at 01:10, Matt Neuburg wrote:

> On Tue, 01 Mar 2011 16:15:09 +0700, "Gerriet M. Denkmann" 
>  said:
>> 
>> On 1 Mar 2011, at 15:53, Kyle Sluder wrote:
>> 
>>> On Tue, Mar 1, 2011 at 12:45 AM, Gerriet M. Denkmann
>>>  wrote:
 So obviously NSAttributedString does NOT return [ [ aFont retain ] 
 autorelease ] but just some internal pointer.
 
 Is this documented somewhere?
>>> 
>>> In the Memory Management Programming Guide:
>>> http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/MemoryMgmt/Articles/mmAccessorMethods.html%23//apple_ref/doc/uid/TP40003539-SW6
>>> 
>>> --Kyle Sluder
>> 
>> As far as I can see, this article talks about different ways to implement 
>> setters and getters.
>> Do you want to imply that, whenever I get some object from AppKit, I have to 
>> retain it until I no longer need it?
>> 
>> Would be a safe thing to do. But also tedious. And in all my past experience 
>> this was never necessary. 
>> So I thought that the "Technique 1" of the linked article (returning 
>> [[someObject retain] autorelease]) was the standart practice employed by 
>> AppKit.
> 
> I've been thinking about this exchange, and I would propose that you consider 
> it like this:
> 
> Suppose you've got an NSArray and you fetch its element objectAtIndex:0. And 
> suppose you now let go of the array (release) and it is destroyed. Do you 
> expect the fetched element to persist without your having retained it? You do 
> not; you know darned well that a collection doesn't behave like that. The 
> collection *owns* its elements and will release them when it is released. All 
> you got when you called objectAtIndex:0 was a pointer. If you want a share in 
> its ownership, you must *take* ownership.
> 
> Here's another example. Suppose you've got a UIView and you ask for its 
> subviews. Do you imagine that asking for this property gives you ownership of 
> those subviews? You do not. Similarly for *any* property of *any* object. You 
> *never* imagine that a fetched property is somehow magically *giving* you 
> ownership; it's just showing you a value.
> 
> So what I'm trying to show you is that when you've got an object that owns 
> stuff, you *never* expect that that object will dispense the stuff it owns 
> while handing you a share in ownership. You *always* take ownership if you 
> want that stuff to persist beyond the object that dispenses them. Ownership 
> is *never* something you are magically given. It is always something that you 
> must take if you want it.

Yes, I fully agree.

But, taking my original example:

NSAttributedString * attributedString = ...
NSFont *aFont = [ attributedString attribute: NSFontAttributeName  atIndex: 0  
effectiveRange: NULL ];
NSString *fontName = [aFont fontName];
[ attributedString release ];

Now aFont no longer exists.
So fontName, being a property of the no longer existing aFont, should have 
vanished also, shouldn't it?

But in my case, fontName is still valid.
Maybe the fontName method really returns [[fontName retain]autorelease] (as I 
wrongly assumed all methods did) or some magical entity keeps a handle on all 
font names, or this name is a constant string decared in AppKit, or whatever.

But this did add to my confusion.

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: NSAttributedString crashes

[Kyle Sluder]

On Thu, Mar 3, 2011 at 4:20 PM, Gerriet M. Denkmann
 wrote:
> But, taking my original example:
>
> NSAttributedString * attributedString = ...
> NSFont *aFont = [ attributedString attribute: NSFontAttributeName  atIndex: 0 
>  effectiveRange: NULL ];
> NSString *fontName = [aFont fontName];
> [ attributedString release ];
>
> Now aFont no longer exists.
> So fontName, being a property of the no longer existing aFont, should have 
> vanished also, shouldn't it?

Replace "should" with "could." The point is that there's no guarantee,
and you need to be prepared for the case where it does.

--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: NSAttributedString crashes

[Matt Neuburg]

On Mar 3, 2011, at 4:35 PM, Kyle Sluder wrote:

> On Thu, Mar 3, 2011 at 4:20 PM, Gerriet M. Denkmann
>  wrote:
>> But, taking my original example:
>> 
>> NSAttributedString * attributedString = ...
>> NSFont *aFont = [ attributedString attribute: NSFontAttributeName  atIndex: 
>> 0  effectiveRange: NULL ];
>> NSString *fontName = [aFont fontName];
>> [ attributedString release ];
>> 
>> Now aFont no longer exists.
>> So fontName, being a property of the no longer existing aFont, should have 
>> vanished also, shouldn't it?
> 
> Replace "should" with "could." The point is that there's no guarantee,
> and you need to be prepared for the case where it does.
> 

And anyway the argument, as specifically posed, is specious, because NSString 
is a very, very special case. Memory management for strings is utterly 
different from memory management for a normal object. Most strings are way 
over-retained and *never* vanish. Indeed, it is quite difficult to generate a 
string that *does* vanish if no one retains it. You can do it, but you have to 
hunt around for a while to figure out how. So arguing by analogy with what an 
NSString does cuts no ice whatever.

Having said all of that, the OP should feel free to file a bug. I've recently 
filed about a memory leak in connection with NSMutableAttributedString, and 
have had this acknowledged as a known issue. So the idea that there might be 
something a bit funny with memory management in connection with 
NSAttributedString is not unreasonable. m.

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: Setting a delegate on a UITextField

[Jon Sigman]

Okay, part II:

Is there a way to allow only a certain number of characters in a UITextField? 
Should this be done in the -textFieldDidEndEditing delegate callback, with an 
alert to the user, or just truncating the field, or ...?

-Jon



  
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: Setting a delegate on a UITextField

[Dianne]

there is, you need to use a formatter for that, you can even set the allowed 
characters to be inputted to the textfield.
check NSFormatter if it is of any help, you can also extend the class to adjust 
to your needs.

 


From: Jon Sigman 
To: Cocoa Developers 
Sent: Fri, March 4, 2011 10:29:23 AM
Subject: Re: Setting a delegate on a UITextField

Okay, part II:

Is there a way to allow only a certain number of characters in a UITextField? 
Should this be done in the -textFieldDidEndEditing delegate callback, with an 
alert to the user, or just truncating the field, or ...?

-Jon



  
___

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

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

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

This email sent to pinkpoppy_sandia...@yahoo.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

NSTableView: which delegate after a drag operation?

[Ulf Dunkel]

In a tiny document-based Cocoa app for Snow Leopard, I have a document 
window with two NSTableView objects, which get properly feeded by 
NSTableViewDataSource according to the documentation. Both table views 
show simple arrays of one column each.


I can fill both table views with random content as I like to and even 
drag and drop inside a list, with perfect refresh of the relevant table 
view. But I would like to sync both table views somehow.


Here are my two questions:

1) Which delegate can I use to inform table view B to update and reload 
its data when I have dragged an item inside table view A?


The NSTableViewDelegate methods don't seem to really help me here; I 
tried them all.


I could of course add any "Refresh" button or stuff, but I would like to 
refresh NSTableView B as soon as a row item of NSTableView A has been 
successfully dragged into a new position.


2) How can I prevent drag operations from table view A to table view B 
(and vice versa)? List members shall only be dragged inside their own list.


Can you give me a hint how to do this?

---Ulf Dunkel
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: NSAttributedString crashes

[Graham Cox]

On 04/03/2011, at 11:54 AM, Matt Neuburg wrote:

> because NSString is a very, very special case. Memory management for strings 
> is utterly different from memory management for a normal object


Is it?

Are you basing this on your observations, or on some documentation?

I don't see this though I haven't gone out of my way to look for it. There is 
no reason I've ever found to treat NSString as a special case, and it doesn't 
sound right to me that strings are effectively never deallocated, which seems 
to be what you're implying. That would be a leak of a rather major order, 
wouldn't it?

--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: NSAttributedString crashes

[Matt Neuburg]

On Mar 3, 2011, at 7:32 PM, Graham Cox wrote:

> On 04/03/2011, at 11:54 AM, Matt Neuburg wrote:
> 
>> because NSString is a very, very special case. Memory management for strings 
>> is utterly different from memory management for a normal object
> 
> 
> Is it?
> 
> Are you basing this on your observations, or on some documentation?

Well, I may have put it rather too strongly - string literals are special, is 
what I meant. But many strings start life as a literal. I'm not saying one 
should *treat* them differently - indeed, doing that is a good way to get into 
trouble. I'm just saying that if you peek at the man behind the curtain (the 
retain count) they can be surprising - like the retain count for 
stringWithString:@"hello". At one point I needed to make a string with a 
"normal" retain count (for a teaching example) and had quite a bit of trouble 
working out how to do it. m.___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: NSAttributedString crashes

[Andy Lee]

On Mar 3, 2011, at 1:10 PM, Matt Neuburg wrote:
> So what I'm trying to show you is that when you've got an object that owns 
> stuff, you *never* expect that that object will dispense the stuff it owns 
> while handing you a share in ownership. 

I would argue it's irrelevant whether the dispensing object owns what it 
dispenses. True, you'll have a pretty good idea whether it does or not, but not 
always. Suppose I have

NSString *fn = [aPerson fullName];

I don't necessarily know whether aPerson owns the object referenced by fn, and 
I don't care. "fullName" does not contain "new", "alloc", or "copy", so the 
memory management rules say I must retain fn if I want it to stick around.

As for what "stick around" means...

> You *always* take ownership if you want that stuff to persist beyond the 
> object that dispenses them.

...I don't think I've ever heard the phrasing, "beyond the object that 
dispenses them".  We've been conditioned to think we have "extra persistence 
time" at least up to the next run loop iteration. I think this stronger 
assertion is better and addresses the issue at hand.

--Andy

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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

Adding subviews to UITableViewCell's contentView and autoresizing behavior

[Ray]

Hi! First post to the list, please be gentle ;)

Small question: when I add a subview to the contentView of a UITableViewCell, 
the rendered width of the subview's frame will be different, depending on 
whether I set the autoresizingMask in combination with an accessoryView. So, 
when I set up a clean test project using the usual UITableViewController, make 
its TableView visible etc. and then use this example code:

- (UITableViewCell *)tableView:(UITableView *)tableView 
cellForRowAtIndexPath:(NSIndexPath *)indexPath {

  static NSString *CellIdentifier = @"Cell";
  UIView *testView;
  UITableViewCell *cell = [tableView 
dequeueReusableCellWithIdentifier:CellIdentifier];
  if (cell == nil) {
  cell = [[[UITableViewCell alloc] 
initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] 
autorelease];

testView = [[[UIView alloc] initWithFrame:CGRectMake(10.0, 
10.0, 226.0, 12.0)] autorelease];
// testView.autoresizingMask = UIViewAutoresizingFlexibleWidth;
testView.backgroundColor = [UIColor redColor];
[cell.contentView addSubview:testView];

UIView *testHolder = [[[UIView alloc] 
initWithFrame:CGRectIntegral(CGRectMake(0.0, 0.0, 64.0, 32.0))] autorelease];
testHolder.backgroundColor = [UIColor greenColor];
cell.accessoryView = testHolder;
  }

  return cell;
}

the actual rendered width of the testView will be smaller (in this case 70 
points I think it was) when I uncomment the UIViewAutoresizingFlexibleWidth 
bit. There will be no difference when I don't use a cell.accessoryView...

Is this expected behavior? Does it have to do with how the cell layouts its 
subviews depending on the use of an accessoryView? I couldn't find this in the 
documentation nor the list archive, so if anyone could enlighten me, much 
appreciated! I would also be interested in workarounds...

Thanks!
- Ray.


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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

NSXMLElement children doesn't return whitespace text nodes

[Heath Borders]

I have the following xml:

A foo. A bar.

Is there a way to access the whitespace-only NSXMLTextKind NSXMLNode?

I've also tried changing my document thusly:

A foo. A bar.

I specify

NSXMLNodePreserveWhitespace

as my option to NSXMLDocument's

initWithXMLString:options:error:

selector.

Thanks!

-Heath Borders
heath.bord...@gmail.com
Twitter: heathborders
http://heath-tech.blogspot.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: NSXMLElement children doesn't return whitespace text nodes

[Gideon King]

I recall that I had problems with that too, and IIRC, the 
NSXMLNodePreserveWhitespace didn't seem to work, but right now I have 
xml:space="preserve" in the XML and parse it with just the NSXMLDocumentTidyXML 
option, and that works. I believe I just went through all the combinations and 
permutations until I found that magic combination, and have just stuck with it. 

HTH

Regards

Gideon
On 04/03/2011, at 3:02 AM, Heath Borders wrote:

> I have the following xml:
> 
> A foo. A bar.
> 
> Is there a way to access the whitespace-only NSXMLTextKind NSXMLNode?
> 
> I've also tried changing my document thusly:
> 
> A foo. A bar.
> 
> I specify
> 
> NSXMLNodePreserveWhitespace
> 
> as my option to NSXMLDocument's
> 
> initWithXMLString:options:error:
> 
> selector.
> 
> Thanks!
> 

___

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

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

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

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

Re: Adding subviews to UITableViewCell's contentView and autoresizing behavior

[Luke Hiesterman]

Flexible width means "change my width if my superview's width changes" and 
accessory views cause the contentView to shrink from its original state as the 
full width of the cell (since the contentView must make space for the 
accessoryView). Therefore, your subview auto shrinks with it since you set the 
mask. Make sense?

Luke

On Mar 2, 2011, at 10:39 PM, Ray  wrote:

> Hi! First post to the list, please be gentle ;)
> 
> Small question: when I add a subview to the contentView of a UITableViewCell, 
> the rendered width of the subview's frame will be different, depending on 
> whether I set the autoresizingMask in combination with an accessoryView. So, 
> when I set up a clean test project using the usual UITableViewController, 
> make its TableView visible etc. and then use this example code:
> 
> - (UITableViewCell *)tableView:(UITableView *)tableView 
> cellForRowAtIndexPath:(NSIndexPath *)indexPath {
> 
>  static NSString *CellIdentifier = @"Cell";
>  UIView *testView;
>  UITableViewCell *cell = [tableView 
> dequeueReusableCellWithIdentifier:CellIdentifier];
>  if (cell == nil) {
>  cell = [[[UITableViewCell alloc] 
> initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] 
> autorelease];
> 
>testView = [[[UIView alloc] initWithFrame:CGRectMake(10.0, 10.0, 
> 226.0, 12.0)] autorelease];
>// testView.autoresizingMask = UIViewAutoresizingFlexibleWidth;
>testView.backgroundColor = [UIColor redColor];
>[cell.contentView addSubview:testView];
> 
>UIView *testHolder = [[[UIView alloc] 
> initWithFrame:CGRectIntegral(CGRectMake(0.0, 0.0, 64.0, 32.0))] autorelease];
>testHolder.backgroundColor = [UIColor greenColor];
>cell.accessoryView = testHolder;
>  }
> 
>  return cell;
> }
> 
> the actual rendered width of the testView will be smaller (in this case 70 
> points I think it was) when I uncomment the UIViewAutoresizingFlexibleWidth 
> bit. There will be no difference when I don't use a cell.accessoryView...
> 
> Is this expected behavior? Does it have to do with how the cell layouts its 
> subviews depending on the use of an accessoryView? I couldn't find this in 
> the documentation nor the list archive, so if anyone could enlighten me, much 
> appreciated! I would also be interested in workarounds...
> 
> Thanks!
> - Ray.
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/luketheh%40apple.com
> 
> This email sent to luket...@apple.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: NSTableView: which delegate after a drag operation?

[Scott Anguish]

On Mar 3, 2011, at 10:24 PM, Ulf Dunkel wrote:

> In a tiny document-based Cocoa app for Snow Leopard, I have a document window 
> with two NSTableView objects, which get properly feeded by 
> NSTableViewDataSource according to the documentation. Both table views show 
> simple arrays of one column each.
> 
> I can fill both table views with random content as I like to and even drag 
> and drop inside a list, with perfect refresh of the relevant table view. But 
> I would like to sync both table views somehow.
> 
> Here are my two questions:
> 
> 1) Which delegate can I use to inform table view B to update and reload its 
> data when I have dragged an item inside table view A?
> 
> The NSTableViewDelegate methods don't seem to really help me here; I tried 
> them all.
> 
> I could of course add any "Refresh" button or stuff, but I would like to 
> refresh NSTableView B as soon as a row item of NSTableView A has been 
> successfully dragged into a new position.

If you’re adding it to the object array, you can easily do the update 
notification then.

> 
> 2) How can I prevent drag operations from table view A to table view B (and 
> vice versa)? List members shall only be dragged inside their own list.

You can pass NSDragOperationNone if the target is the originating table.


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: Adding subviews to UITableViewCell's contentView and autoresizing behavior

[Ray]

> Flexible width means "change my width if my superview's width changes" and 
> accessory views cause the contentView to shrink from its original state as 
> the full width of the cell (since the contentView must make space for the 
> accessoryView). Therefore, your subview auto shrinks with it since you set 
> the mask. Make sense?
> 
> Luke

Thanks for your fast reply, Luke!

It does makes sense. I wanted to use the autoresizing mask because it supports 
rotation (of the device) in a nice way for my subview (initially I used an 
animation to adjust the width of the subview, but I wanted to make things 
simpler). Because my fixed-width accessoryView will always be there (in my 
cell's implementation in the real app that is), would you consider it good 
practice to take into account the offset in defining my subview's width, if you 
know what I mean?

Thanks,
- Ray.

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: Setting a delegate on a UITextField

[Ray]

> Message: 8
> Date: Thu, 03 Mar 2011 18:29:23 -0800 (PST)
> From: Jon Sigman 
> Subject: Re: Setting a delegate on a UITextField
> To: Cocoa Developers 
> Message-ID: <977310.3842...@web31911.mail.mud.yahoo.com>
> Content-Type: text/plain; charset=us-ascii
> 
> Okay, part II:
> 
> Is there a way to allow only a certain number of characters in a UITextField? 
> Should this be done in the -textFieldDidEndEditing delegate callback, with an 
> alert to the user, or just truncating the field, or ...?
> 
> -Jon
> 
> 
> 
> 
> 
> --
> 
> Message: 9
> Date: Thu, 03 Mar 2011 18:51:39 -0800 (PST)
> From: Dianne 
> Subject: Re: Setting a delegate on a UITextField
> To: Jon Sigman , Cocoa Developers
>   
> Message-ID: <713875.69795...@web120609.mail.ne1.yahoo.com>
> Content-Type: text/plain; charset=us-ascii
> 
> there is, you need to use a formatter for that, you can even set the allowed 
> characters to be inputted to the textfield.
> check NSFormatter if it is of any help, you can also extend the class to 
> adjust 
> to your needs.

Hmm, interesting, I didn't think of that. I remember in some earlier code I did 
something like so, using a notification... just as an example in some iOS app:

- (void)textFieldTextDidChange:(NSNotification*)aNotification {

NSInteger remaining = [[aNotification.object text] length];

if (remaining < self.minLength) {
self.tableView.tableFooterView.hidden = NO;
[self.headerLabel setText:[NSString 
stringWithFormat:NSLocalizedString(@"Remaining characters required: %d", nil),
   
(self.minLength - remaining)]];
self.navigationItem.rightBarButtonItem.enabled = NO;

} else {
self.tableView.tableFooterView.hidden = YES;
self.navigationItem.rightBarButtonItem.enabled = YES;

}
}

Overkill?___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: Adding subviews to UITableViewCell's contentView and autoresizing behavior

[Luke Hiesterman]

The strategy I recommend for anyone adding views to UITableViewCell is to 
subclass and implement layoutSubviews. You will then be able to easily set your 
subview frames as you desire for any orientation because layoutSubviews will be 
called on rotation. 

Luke

On Mar 3, 2011, at 8:50 PM, Ray  wrote:

>> Flexible width means "change my width if my superview's width changes" and 
>> accessory views cause the contentView to shrink from its original state as 
>> the full width of the cell (since the contentView must make space for the 
>> accessoryView). Therefore, your subview auto shrinks with it since you set 
>> the mask. Make sense?
>> 
>> Luke
> 
> Thanks for your fast reply, Luke!
> 
> It does makes sense. I wanted to use the autoresizing mask because it 
> supports rotation (of the device) in a nice way for my subview (initially I 
> used an animation to adjust the width of the subview, but I wanted to make 
> things simpler). Because my fixed-width accessoryView will always be there 
> (in my cell's implementation in the real app that is), would you consider it 
> good practice to take into account the offset in defining my subview's width, 
> if you know what I mean?
> 
> Thanks,
> - Ray.
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/luketheh%40apple.com
> 
> This email sent to luket...@apple.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: Adding subviews to UITableViewCell's contentView and autoresizing behavior

[Ray]

Right, I kind of anticipated you were going to say that ;) I will probably do a 
little subclassing then...

Thanks again, Luke!

On Mar 4, 2011, at 2:29 PM, Luke Hiesterman wrote:

> The strategy I recommend for anyone adding views to UITableViewCell is to 
> subclass and implement layoutSubviews. You will then be able to easily set 
> your subview frames as you desire for any orientation because layoutSubviews 
> will be called on rotation. 
> 
> Luke

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: table view and custom cell optimization problem

[Nick Rogers]

Hi,
Thanks for the reply.

But the problem is that I don't have anything common in the rows.
The image (128x128) are different, the four lines of text are different and the 
lines I draw are different in each cell.

Any Ideas?

Regards,
Nick

On 03-Mar-2011, at 9:48 PM, jonat...@mugginsoft.com wrote:

> 
> On 3 Mar 2011, at 04:06, Nick Rogers wrote:
> 
>> Hi,
>> I have a table view with the custom cell class assigned to its only column 
>> in awakeFromNib method using setDataCell:.
>> Then I'm doing some drawing in drawInteriorWithFrame: of the NSCell subclass.
>> The problem is that drawing include four lines of text and an image and a 
>> few lines using NSBezierPath.
>> 
>> This is relatively time consuming and hence when I scroll the table view, 
>> the scrolling is not that smooth and is a bit jerky.
>> 
>> Is there a way to do all this custom drawing in a manner that could make the 
>> scrolling faster.
> 
> I use the following approach in an NSView but you can adapt it.
> 
> The idea is to cache your background (that is common to all cells) in an 
> NSImage instance.
> When the cell needs drawn you copy from the image cache into your focus 
> locked view.
> Then you can draw the unique cell content - text etc.
> 
> Obviously when the cell size changes you have to regenerate your background 
> image cache.
> 
> - (void)drawRect:(NSRect)rect 
> { 
> 
>   if (!_imageCache) {
>   
>   // draw to image cache
>   _cacheRect  = [self bounds];
>   _imageCache = [[NSImage alloc] initWithSize:_cacheRect.size];
>   [_imageCache lockFocus];
>   
>   // draw background with beziers etc
>   
>   [_imageCache unlockFocus]; 
>   }
> 
>   [_imageCache drawInRect:rect fromRect:rect 
> operation:NSCompositeSourceOver fraction:1.0f];
> 
>   // now draw unique foreground
> } 
> 
> 
> 
> 
> Regards
> 
> Jonathan Mitchell
> 
> Developer
> Mugginsoft LLP
> http://www.mugginsoft.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/roger_s1%40mac.com
> 
> This email sent to roger...@mac.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