Re: [iPhone] Why can't a UITextField be its own delegate?

[WT]

On Jul 27, 2009, at 10:32 PM, Fritz Anderson wrote:


On 27 Jul 2009, at 9:58 AM, Jonathan Hendry wrote:


Seems like a good job for an NSFormatter attached to the field.


Can you attach an NSFormatter to a UITextField? The only mention in  
the docs of attaching formatters to cells says right up front that  
the subject does not apply to iPhone OS.


— F


That's the reason I had to code it (limiting the number of characters)  
myself. My understanding, like yours, was that you can't attach a  
formatter to a text field on the iPhone SDK.


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: [iPhone] Why can't a UITextField be its own delegate?

[WT]

On Jul 26, 2009, at 4:16 AM, Greg Guerin wrote:


WT wrote:

It seems I'll have to opt for having a regular UITextField and a  
custom class whose sole purpose is to provide a delegate that does  
the common work. As Kyle suggested, I may need to make that a  
superclass and derive additional delegates to perform extra work  
after the common task.


As previously noted, you could also give the common-task delegate  
its own delegate.  Then you get the advantages of delegation, it's  
just one level away from the UITextField's direct delegate.


More generally, you could implement the Chain Of Responsibility  
pattern in the UITextField's direct delegate (the principal  
delegate), so any number of other secondary delegates could  
contribute to the overall task, in chain-priority order, and  
according to which selectors a secondary delegate implements.  Since  
any secondary delegate could also be the principal of its own chain,  
you have the potential for a tree of delegates.


Yes, after careful consideration, the Chain of Responsibility is the  
approach I went with, and it's working great. Thanks for the suggestion.


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: [iPhone] Why can't a UITextField be its own delegate?

[Fritz Anderson]

On 27 Jul 2009, at 9:58 AM, Jonathan Hendry wrote:


Seems like a good job for an NSFormatter attached to the field.


Can you attach an NSFormatter to a UITextField? The only mention in  
the docs of attaching formatters to cells says right up front that the  
subject does not apply to iPhone OS.


— F

--
Fritz Anderson -- Xcode 3 Unleashed: Now in its second printing -- 


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: [iPhone] Why can't a UITextField be its own delegate?

[Jonathan Hendry]

On Jul 25, 2009, at 16:14 PM, WT wrote:


Convoluted? I don't see it that way.

This particular text field needs to limit its number of characters  
to a given interval.


Seems like a good job for an NSFormatter attached to the field.
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: [iPhone] Why can't a UITextField be its own delegate?

[Peter Blazejewicz]

Hi WT,
have you tried - to avoid everything discussed in thread - to use
implementation like below one? For what you want it could be more
proper avoiding discussed issues and at the same time it hides
everything into your subclass (wrapped delegate class details are
hidden into module):

#import 

@class CustomTextFieldDelegate;

@interface CustomTextField : UITextField

{

    @private

    CustomTextFieldDelegate * _customDelegate;

}

@end

#import "CustomTextField.h"

@interface CustomTextFieldDelegate:NSObject

@end

@implementation CustomTextFieldDelegate

-(BOOL)textField:(UITextField*)text_field
shouldChangeCharactersInRange: (NSRange) range replacementString:
(NSString*) string

{

    NSLog(@"-textField: shouldChangeCharactersInRange: replacementString:");

    return YES;

}

-(BOOL)textFieldShouldBeginEditing:(UITextField*)text_field

{

    NSLog(@"-textFieldShouldBeginEditing:");

    return YES;

}

- (void)textFieldDidBeginEditing:(UITextField*)text_field

{

    NSLog(@"-textFieldDidBeginEditing:");

}

- (BOOL) textFieldShouldEndEditing: (UITextField*) text_field

{

    NSLog(@"-textFieldShouldEndEditing:");

    return YES;

}

- (void) textFieldDidEndEditing: (UITextField*) text_field

{

    NSLog(@"-textFieldDidEndEditing:");

}

- (BOOL) textFieldShouldClear: (UITextField*) text_field

{

    NSLog(@"-textFieldShouldClear:");

    return YES;

}

- (BOOL) textFieldShouldReturn: (UITextField*) text_field

{

    NSLog(@"-textFieldShouldReturn:");

    [text_field resignFirstResponder];

    return YES;

}



@end

@implementation CustomTextField

-(void)awakeFromNib

{

    _customDelegate = [[CustomTextFieldDelegate alloc] init];

    self.delegate = _customDelegate;

    self.text = @"Hello World";

    [super awakeFromNib];

}

-(void)dealloc

{

    [_customDelegate release]; _customDelegate = nil;

    [super dealloc];

}

@end

On Sat, Jul 25, 2009 at 9:06 PM, WT  wrote:
>
> Hello all,
>
> I need to create a subclass of UITextField for a text field that performs 
> some control over its own editing. The obvious idea is to make the subclass 
> instance set itself up as its own delegate, but that freezes the app as soon 
> as the delegate method -textFieldDidBeginEditing returns.
>
> Looking at Activity Monitor, the CPU usage of the app goes up to nearly 100%. 
> I've since created the most trivial app with a UITextField subclass that 
> conforms to the UITextFieldDelegate protocol and which sets itself up as its 
> own delegate and, sure enough, the app freezes.
>
> Here's the subclass. Set up a project then add a text field to a view and 
> make its class be CustomTextField. Compile and run, and watch it freeze when 
> you attempt to edit the text in the field.
>
> So... why can't the field be its own delegate?
>
> Thanks in advance.
> Wagner
>
>
> // CustomTextField.h:
>
> #import 
>
> @interface CustomTextField: UITextField 
> {
> }
>
> @end
>
> // CustomTextField.m:
>
> #import "CustomTextField.h"
>
> @implementation CustomTextField
>
> - (void) awakeFromNib
> {
>    super.delegate = self;
>    super.text = @"Hello world";
>
>    NSLog(@"awakeFromNib called - delegate set to self");
> }
>
> // = 
> //
>
> - (BOOL) textField: (UITextField*) text_field
>         shouldChangeCharactersInRange: (NSRange) range
>         replacementString: (NSString*) string
> {
>    NSLog(@"-textField: shouldChangeCharactersInRange: replacementString:");
>    return YES;
> }
>
> // = 
> //
>
> - (BOOL) textFieldShouldBeginEditing: (UITextField*) text_field
> {
>    NSLog(@"-textFieldShouldBeginEditing:");
>    return YES;
> }
>
> // = 
> //
>
> - (void) textFieldDidBeginEditing: (UITextField*) text_field
> {
>    NSLog(@"-textFieldDidBeginEditing:");
> }
>
> // = 
> //
>
> - (BOOL) textFieldShouldEndEditing: (UITextField*) text_field
> {
>    NSLog(@"-textFieldShouldEndEditing:");
>    return YES;
> }
>
> // = 
> //
>
> - (void) textFieldDidEndEditing: (UITextField*) text_field
> {
>    NSLog(@"-textFieldDidEndEditing:");
> }
>
> // = 
> //
>
> - (BOOL) textFieldShouldClear: (UITextField*) text_field
> {
>    NSLog(@"-textFieldShouldClear:");
>    return YES;
> }
>
> // = 
> //
>
> - (BOOL) textFieldShouldReturn: (UITextField*) text_field
> {
>    NSLog(@"-textFieldShouldReturn:");
>    [self resignFirstResponder];
>    return YES;
> }
>
> // = 
> //
>
> @end
>
> ___
>
> Cocoa-dev maili

Re: [iPhone] Why can't a UITextField be its own delegate?

[Greg Guerin]

WT wrote:

It seems I'll have to opt for having a regular UITextField and a  
custom class whose sole purpose is to provide a delegate that does  
the common work. As Kyle suggested, I may need to make that a  
superclass and derive additional delegates to perform extra work  
after the common task.


As previously noted, you could also give the common-task delegate its  
own delegate.  Then you get the advantages of delegation, it's just  
one level away from the UITextField's direct delegate.


More generally, you could implement the Chain Of Responsibility  
pattern in the UITextField's direct delegate (the principal  
delegate), so any number of other secondary delegates could  
contribute to the overall task, in chain-priority order, and  
according to which selectors a secondary delegate implements.  Since  
any secondary delegate could also be the principal of its own chain,  
you have the potential for a tree of delegates.


  -- GG

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: [iPhone] Why can't a UITextField be its own delegate?

[Kyle Sluder]

On Sat, Jul 25, 2009 at 5:35 PM, Luke the Hiesterman wrote:
> I read the code too quickly. I just thought it was the standard if
> ([delegate respondsToSelector:]) [delegate doSomething]; paradigm. I
> retract my statement. That is definitely not a standard of the delegation
> pattern.

Nothing like being right for the wrong reasons.  :P

--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: [iPhone] Why can't a UITextField be its own delegate?

[WT]

On Jul 26, 2009, at 2:42 AM, Adam R. Maxwell wrote:


On Jul 25, 2009, at 5:35 PM, WT wrote:

First, since I don't know how to get the name of a method (as a  
string) from its selector,


Did you miss NSStringFromSelector() and sel_getName()?


I did, even though I looked at both the NSString and NSObject  
documentation. 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: [iPhone] Why can't a UITextField be its own delegate?

[WT]

On Jul 26, 2009, at 2:42 AM, Luke the Hiesterman wrote:

I've told you twice now that the problem is UITextField implements  
selectors that it also uses as delegate calls.


By my count, you only did that once, and I only read it after I sent  
my last message. In any case, forgive me for being slow and trying to  
understand things in detail in my own ways. This is still a learning  
experience for me.


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: [iPhone] Why can't a UITextField be its own delegate?

[Adam R. Maxwell]

On Jul 25, 2009, at 5:35 PM, WT wrote:

First, since I don't know how to get the name of a method (as a  
string) from its selector,


Did you miss NSStringFromSelector() and sel_getName()?



smime.p7s
Description: S/MIME cryptographic signature
___

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

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

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

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

Re: [iPhone] Why can't a UITextField be its own delegate?

[Luke the Hiesterman]

I've told you twice now that the problem is UITextField implements  
selectors that it also uses as delegate calls. The answer to the  
question "can I make delegate == self on UITextField" is a definite NO.


Luke

On Jul 25, 2009, at 5:35 PM, WT wrote:


On Jul 26, 2009, at 1:18 AM, WT wrote:


On Jul 26, 2009, at 1:04 AM, WT wrote:

Now, I agree that UITextField will run into an infinite loop (in  
the sample app) when calling -respondsToSelector on its delegate  
because it is its own delegate. However, why is it then that - 
textFieldShouldBeginEditing returns successfully and - 
textFieldDidBeginEditing executes but doesn't return? Both of them  
successfully print their method names:


- (BOOL) textFieldShouldBeginEditing: (UITextField*) text_field
{
 NSLog(@"-textFieldShouldBeginEditing:");
 return YES;
}

- (void) textFieldDidBeginEditing: (UITextField*) text_field
{
 NSLog(@"-textFieldDidBeginEditing:");
}

It would seem that -respondsToSelector: is not being called at all.


Actually, it is and I do get an infinite loop, thanks to

- (BOOL) respondsToSelector: (SEL) selector
{
  NSLog(@"-respondsToSelector:");
  return [super respondsToSelector: selector];
}

How do I get a string for the name of the method represented by the  
selector?


I'm beginning to understand the intricacies of this problem...  
First, since I don't know how to get the name of a method (as a  
string) from its selector, I'm simply outputting the selector  
itself, which is an address. Now, consider this as the subclass  
implementation:


#import "CustomTextField.h"

@implementation CustomTextField

- (void) awakeFromNib
{
   super.delegate = self;
   super.text = @"Hello world";

   NSLog(@"awakeFromNib called - delegate set to self");
}

//  
= 
= 
= 
= 
= 
= 
=== //


- (BOOL) textField: (UITextField*) text_field
shouldChangeCharactersInRange: (NSRange) range
replacementString: (NSString*) string
{
   NSLog(@"-textField: shouldChangeCharactersInRange:  
replacementString: %p",
 @selector(textField: shouldChangeCharactersInRange:  
replacementString:));

   return YES;
}

//  
= 
= 
= 
= 
= 
= 
=== //


- (BOOL) textFieldShouldBeginEditing: (UITextField*) text_field
{
   NSLog(@"-textFieldShouldBeginEditing: %p",
 @selector(textFieldShouldBeginEditing:));
   return YES;
}

//  
= 
= 
= 
= 
= 
= 
=== //


- (void) textFieldDidBeginEditing: (UITextField*) text_field
{
   NSLog(@"-textFieldDidBeginEditing: %p",
 @selector(textFieldDidBeginEditing:));
}

//  
= 
= 
= 
= 
= 
= 
=== //


- (BOOL) textFieldShouldEndEditing: (UITextField*) text_field
{
   NSLog(@"-textFieldShouldEndEditing: %p",
 @selector(textFieldShouldEndEditing:));
   return YES;
}

//  
= 
= 
= 
= 
= 
= 
=== //


- (void) textFieldDidEndEditing: (UITextField*) text_field
{
   NSLog(@"-textFieldDidEndEditing: %p",
 @selector(textFieldDidEndEditing:));
}

//  
= 
= 
= 
= 
= 
= 
=== //


- (BOOL) textFieldShouldClear: (UITextField*) text_field
{
   NSLog(@"-textFieldShouldClear: %p",
 @selector(textFieldShouldClear:));
   return YES;
}

//  
= 
= 
= 
= 
= 
= 
=== //


- (BOOL) textFieldShouldReturn: (UITextField*) text_field
{
   NSLog(@"-textFieldShouldReturn: %p",
 @selector(textFieldShouldReturn:));
   [self resignFirstResponder];
   return YES;
}

//  
= 
= 
= 
= 
= 
= 
=== //


- (BOOL) respondsToSelector: (SEL) selector
{
   NSLog(@"-respondsToSelector: %p", selector);

   if (selector ==
   @selector 
(textField:shouldChangeCharactersInRange:replacementString:) ||

   selector == @selector(textFieldShouldBeginEditing:) ||
   selector == @selector(textFieldDidBeginEditing:) ||
   selector == @selector(textFieldShouldEndEditing:) ||
   selector == @selector(textFieldDidEndEditing:) ||
   selector == @selector(textFieldShouldClear:) ||
   selector == @selector(textFieldShouldReturn:))
   { return YES; }
   else
   {
   return [UITextField instancesRespondToSelector: selector];
   }
}

//  
= 
= 
= 
= 
= 
= 
=== //


@end

This still causes an infinite loop, with the result being something  
like this:


-respondsToSelector: 0x93147998
-respondsToSelector: 0x9316a1b4
-respondsToSelector: 0x931bf364
-respondsToSelector: 0x931389bc
-respondsToSelector: 0x93142b98
-respondsToSelector: 0x931d30c4
-respondsToSelector: 0x93167564
-respondsToSelector: 0x319b8c98
-respondsToSelector: 0x319cc41a
-

Re: [iPhone] Why can't a UITextField be its own delegate?

[WT]

On Jul 26, 2009, at 1:18 AM, WT wrote:


On Jul 26, 2009, at 1:04 AM, WT wrote:

Now, I agree that UITextField will run into an infinite loop (in  
the sample app) when calling -respondsToSelector on its delegate  
because it is its own delegate. However, why is it then that - 
textFieldShouldBeginEditing returns successfully and - 
textFieldDidBeginEditing executes but doesn't return? Both of them  
successfully print their method names:


- (BOOL) textFieldShouldBeginEditing: (UITextField*) text_field
{
  NSLog(@"-textFieldShouldBeginEditing:");
  return YES;
}

- (void) textFieldDidBeginEditing: (UITextField*) text_field
{
  NSLog(@"-textFieldDidBeginEditing:");
}

It would seem that -respondsToSelector: is not being called at all.


Actually, it is and I do get an infinite loop, thanks to

- (BOOL) respondsToSelector: (SEL) selector
{
   NSLog(@"-respondsToSelector:");
   return [super respondsToSelector: selector];
}

How do I get a string for the name of the method represented by the  
selector?


I'm beginning to understand the intricacies of this problem... First,  
since I don't know how to get the name of a method (as a string) from  
its selector, I'm simply outputting the selector itself, which is an  
address. Now, consider this as the subclass implementation:


#import "CustomTextField.h"

@implementation CustomTextField

- (void) awakeFromNib
{
super.delegate = self;
super.text = @"Hello world";

NSLog(@"awakeFromNib called - delegate set to self");
}

//  
= 
= 
= 
= 
= //


- (BOOL) textField: (UITextField*) text_field
 shouldChangeCharactersInRange: (NSRange) range
 replacementString: (NSString*) string
{
NSLog(@"-textField: shouldChangeCharactersInRange:  
replacementString: %p",
  @selector(textField: shouldChangeCharactersInRange:  
replacementString:));

return YES;
}

//  
= 
= 
= 
= 
= //


- (BOOL) textFieldShouldBeginEditing: (UITextField*) text_field
{
NSLog(@"-textFieldShouldBeginEditing: %p",
  @selector(textFieldShouldBeginEditing:));
return YES;
}

//  
= 
= 
= 
= 
= //


- (void) textFieldDidBeginEditing: (UITextField*) text_field
{
NSLog(@"-textFieldDidBeginEditing: %p",
  @selector(textFieldDidBeginEditing:));
}

//  
= 
= 
= 
= 
= //


- (BOOL) textFieldShouldEndEditing: (UITextField*) text_field
{
NSLog(@"-textFieldShouldEndEditing: %p",
  @selector(textFieldShouldEndEditing:));
return YES;
}

//  
= 
= 
= 
= 
= //


- (void) textFieldDidEndEditing: (UITextField*) text_field
{
NSLog(@"-textFieldDidEndEditing: %p",
  @selector(textFieldDidEndEditing:));
}

//  
= 
= 
= 
= 
= //


- (BOOL) textFieldShouldClear: (UITextField*) text_field
{
NSLog(@"-textFieldShouldClear: %p",
  @selector(textFieldShouldClear:));
return YES;
}

//  
= 
= 
= 
= 
= //


- (BOOL) textFieldShouldReturn: (UITextField*) text_field
{
NSLog(@"-textFieldShouldReturn: %p",
  @selector(textFieldShouldReturn:));
[self resignFirstResponder];
return YES;
}

//  
= 
= 
= 
= 
= //


- (BOOL) respondsToSelector: (SEL) selector
{
NSLog(@"-respondsToSelector: %p", selector);

if (selector ==
 
@selector(textField:shouldChangeCharactersInRange:replacementString:) ||

selector == @selector(textFieldShouldBeginEditing:) ||
selector == @selector(textFieldDidBeginEditing:) ||
selector == @selector(textFieldShouldEndEditing:) ||
selector == @selector(textFieldDidEndEditing:) ||
selector == @selector(textFieldShouldClear:) ||
selector == @selector(textFieldShouldReturn:))
{ return YES; }
else
{
return [UITextField instancesRespondToSelector: selector];
}
}

//  
= 
= 
= 
= 
= //


@end

This still causes an infinite loop, with the result being something  
like this:


-respondsToSelector: 0x93147998
-respondsToSelector: 0x9316a1b4
-respondsToSelector: 0x931bf364
-respondsToSelector: 0x931389bc
-respondsToSelector: 0x93142b98
-respondsToSelector: 0x931d30c4
-respondsToSelector: 0x93167564
-respondsToSelector: 0x319b8c98
-respondsToSelector: 0x319cc41a
-respondsToSelector: 0x319f4af4
awakeFromNib called - delegate set to self
-respondsToSelector: 0x319b5a68
-textFieldShouldBeginEditing: 0x319b5a68
-respondsToSelector: 0x319aa222
-respondsToSelector: 0x319aa124
-respondsToSelector: 0x319aa100
-respon

Re: [iPhone] Why can't a UITextField be its own delegate?

[Luke the Hiesterman]

On Jul 25, 2009, at 5:32 PM, Adam R. Maxwell wrote:



On Jul 25, 2009, at 5:02 PM, Luke the Hiesterman wrote:



On Jul 25, 2009, at 3:41 PM, Adam R. Maxwell wrote:


On Jul 25, 2009, at 3:23 PM, Kyle Sluder wrote:


Internally, UITextField is going to use self.delegate to get its
delegate, following the correct accessor behavior.  You've gone and
replaced -delegate to return self.  But the delegate pattern says  
that
messages which this object does not understand should be  
forwarded to

the delegate.  This means that a class with a delegate needs to
implement -respondsToSelector: this way:

- (BOOL)respondsToSelector:(SEL)aSelector {
return [super respondsToSelector:aSelector]
|| [self.delegate respondsToSelector:aSelector];
}


Where is this guaranteed by the delegate pattern?  I've created a  
fair number of classes with delegates and never done this; it  
would be interesting to know that I've been doing it wrong for  
years ;).


It's not guaranteed - it's just the right way to implement an  
optional delegate method.


Who says it's the right way, though?  I've never seen a delegate  
implemented that way, in documentation or sample code, and wouldn't  
you also have to implement forwarding code to keep this from  
breaking?  Maybe I'm dense, but I don't see the point of doing this.




I read the code too quickly. I just thought it was the standard if  
([delegate respondsToSelector:]) [delegate doSomething]; paradigm.  
I retract my statement. That is definitely not a standard of the  
delegation pattern.


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: [iPhone] Why can't a UITextField be its own delegate?

[Adam R. Maxwell]

On Jul 25, 2009, at 5:02 PM, Luke the Hiesterman wrote:



On Jul 25, 2009, at 3:41 PM, Adam R. Maxwell wrote:


On Jul 25, 2009, at 3:23 PM, Kyle Sluder wrote:


Internally, UITextField is going to use self.delegate to get its
delegate, following the correct accessor behavior.  You've gone and
replaced -delegate to return self.  But the delegate pattern says  
that
messages which this object does not understand should be forwarded  
to

the delegate.  This means that a class with a delegate needs to
implement -respondsToSelector: this way:

- (BOOL)respondsToSelector:(SEL)aSelector {
return [super respondsToSelector:aSelector]
 || [self.delegate respondsToSelector:aSelector];
}


Where is this guaranteed by the delegate pattern?  I've created a  
fair number of classes with delegates and never done this; it would  
be interesting to know that I've been doing it wrong for years ;).


It's not guaranteed - it's just the right way to implement an  
optional delegate method.


Who says it's the right way, though?  I've never seen a delegate  
implemented that way, in documentation or sample code, and wouldn't  
you also have to implement forwarding code to keep this from  
breaking?  Maybe I'm dense, but I don't see the point of doing this.




smime.p7s
Description: S/MIME cryptographic signature
___

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

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

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

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

Re: [iPhone] Why can't a UITextField be its own delegate?

[Luke the Hiesterman]

On Jul 25, 2009, at 4:04 PM, WT wrote:



On Jul 26, 2009, at 12:42 AM, Kyle Sluder wrote:


On Jul 25, 2009, at 3:36 PM, WT  wrote:

No. -delegate returns the "outside" delegate, not self. As I said,  
from the outside world, everything is business as usual. If you  
call -setDelegate: to set yourself up as the delegate, then you  
are what's returned by a call to -delegate.


If that were the case then your delegate insertion technique would  
be useless, since whenever UITextField wanted to ask it's delegate  
for something it would always get the external object.


Hmm... I think you're right. Still, that has nothing to do with the  
freeze since the sample app has no outside delegates.


The reason for the freeze is UITextField implements a couple of the  
methods that it defines as delegate methods. The methods then end up  
calling themselves repeatedly when the delegate is self. This kind of  
thing was never intended to be supported.


Also, as far as the overloading of self.delegate, I think you're  
failing to understand some things about objective-c. There's only one  
ivar in your class that holds the delegate. There's really no way to  
have 2 different objects there. Calling [self delegate] always goes to  
the same method no matter where it's called from.


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: [iPhone] Why can't a UITextField be its own delegate?

[Luke the Hiesterman]

On Jul 25, 2009, at 3:41 PM, Adam R. Maxwell wrote:


On Jul 25, 2009, at 3:23 PM, Kyle Sluder wrote:


Internally, UITextField is going to use self.delegate to get its
delegate, following the correct accessor behavior.  You've gone and
replaced -delegate to return self.  But the delegate pattern says  
that

messages which this object does not understand should be forwarded to
the delegate.  This means that a class with a delegate needs to
implement -respondsToSelector: this way:

- (BOOL)respondsToSelector:(SEL)aSelector {
return [super respondsToSelector:aSelector]
  || [self.delegate respondsToSelector:aSelector];
}


Where is this guaranteed by the delegate pattern?  I've created a  
fair number of classes with delegates and never done this; it would  
be interesting to know that I've been doing it wrong for years ;).


It's not guaranteed - it's just the right way to implement an optional  
delegate method.


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: [iPhone] Why can't a UITextField be its own delegate?

[WT]

On Jul 26, 2009, at 1:04 AM, WT wrote:

Now, I agree that UITextField will run into an infinite loop (in the  
sample app) when calling -respondsToSelector on its delegate because  
it is its own delegate. However, why is it then that - 
textFieldShouldBeginEditing returns successfully and - 
textFieldDidBeginEditing executes but doesn't return? Both of them  
successfully print their method names:


- (BOOL) textFieldShouldBeginEditing: (UITextField*) text_field
{
   NSLog(@"-textFieldShouldBeginEditing:");
   return YES;
}

- (void) textFieldDidBeginEditing: (UITextField*) text_field
{
   NSLog(@"-textFieldDidBeginEditing:");
}

It would seem that -respondsToSelector: is not being called at all.


Actually, it is and I do get an infinite loop, thanks to

- (BOOL) respondsToSelector: (SEL) selector
{
NSLog(@"-respondsToSelector:");
return [super respondsToSelector: selector];
}

How do I get a string for the name of the method represented by the  
selector?


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: [iPhone] Why can't a UITextField be its own delegate?

[WT]

On Jul 26, 2009, at 12:42 AM, Kyle Sluder wrote:


On Jul 25, 2009, at 3:36 PM, WT  wrote:

No. -delegate returns the "outside" delegate, not self. As I said,  
from the outside world, everything is business as usual. If you  
call -setDelegate: to set yourself up as the delegate, then you are  
what's returned by a call to -delegate.


If that were the case then your delegate insertion technique would  
be useless, since whenever UITextField wanted to ask it's delegate  
for something it would always get the external object.


Hmm... I think you're right. Still, that has nothing to do with the  
freeze since the sample app has no outside delegates.


Now, I agree that UITextField will run into an infinite loop (in the  
sample app) when calling -respondsToSelector on its delegate because  
it is its own delegate. However, why is it then that - 
textFieldShouldBeginEditing returns successfully and - 
textFieldDidBeginEditing executes but doesn't return? Both of them  
successfully print their method names:


- (BOOL) textFieldShouldBeginEditing: (UITextField*) text_field
{
NSLog(@"-textFieldShouldBeginEditing:");
return YES;
}

- (void) textFieldDidBeginEditing: (UITextField*) text_field
{
NSLog(@"-textFieldDidBeginEditing:");
}

It would seem that -respondsToSelector: is not being called at all.

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: [iPhone] Why can't a UITextField be its own delegate?

[Kyle Sluder]

On Jul 25, 2009, at 3:41 PM, "Adam R. Maxwell"  wrote:

Where is this guaranteed by the delegate pattern?  I've created a  
fair number of classes with delegates and never done this; it would  
be interesting to know that I've been doing it wrong for years ;).


You seem to be right; I can't find this in the documentation. Must be  
confusing it with another pattern.


But the critical point is that if the object ever invokes - 
respondsToSelector: on self.delegate it will infinitely recurse. This  
is a very common pattern. One could override -respondsToSelector: to  
fix this issue, but then it would have to do some trickery to ensure  
it skips super's implementation. And that's just for this one known  
case.


--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: [iPhone] Why can't a UITextField be its own delegate?

[WT]

On Jul 26, 2009, at 12:41 AM, Adam R. Maxwell wrote:


On Jul 25, 2009, at 3:23 PM, Kyle Sluder wrote:


Internally, UITextField is going to use self.delegate to get its
delegate, following the correct accessor behavior.  You've gone and
replaced -delegate to return self.  But the delegate pattern says  
that

messages which this object does not understand should be forwarded to
the delegate.  This means that a class with a delegate needs to
implement -respondsToSelector: this way:

- (BOOL)respondsToSelector:(SEL)aSelector {
return [super respondsToSelector:aSelector]
  || [self.delegate respondsToSelector:aSelector];
}


Where is this guaranteed by the delegate pattern?  I've created a  
fair number of classes with delegates and never done this; it would  
be interesting to know that I've been doing it wrong for years ;).


Good point!

Since -delegate is going to return self, -respondsToSelector: is  
going

to result in infinite recursion.

So It's Never Safe To Make An Object Its Own Delegate.


Even if it's safe, it's a bizarre way to do something, especially if  
you're already subclassing it...especially since delegates are  
mainly used to avoid subclassing.


As I pointed out earlier, the common work that needs to be done  
consumes the delegate outlet. Thus, any extra work that would  
otherwise be done by a delegate requires an outlet for that outside  
delegate. I simply wire things up internally so that the work is  
chained while, to the outside world, it still looks as though there is  
only one delegate.


For the specific case of limiting text field input, why not just use  
an NSFormatter subclass, though?  That's what I'd do in Cocoa (and  
this is the cocoa-dev list, after all).


Ok, that's an idea I hadn't thought of and worth exploring. Thanks for  
the suggestion.


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: [iPhone] Why can't a UITextField be its own delegate?

[WT]

On Jul 26, 2009, at 12:23 AM, Kyle Sluder wrote:


There is no reason for any outside entity to want to refer to
super.delegate. In fact, unless I'm wrong, I don't think it's even  
possible

to retrieve super.delegate from the custom instance.


Ooh, I think we've found your bug.


I don't think so.


Internally, UITextField is going to use self.delegate to get its
delegate, following the correct accessor behavior.  You've gone and
replaced -delegate to return self.


As I said earlier, -delegate returns the outside delegate, not self.  
But, in the sample application, there is no outside delegate so, yes, - 
delegate returns self. But this shouldn't be a problem because the  
custom text field implements ALL methods of the UITextFieldDelegate  
protocol.



 But the delegate pattern says that
messages which this object does not understand should be forwarded to
the delegate.


Not a problem. See above.


 This means that a class with a delegate needs to
implement -respondsToSelector: this way:

- (BOOL)respondsToSelector:(SEL)aSelector {
 return [super respondsToSelector:aSelector]
   || [self.delegate respondsToSelector:aSelector];
}


[super respondsToSelector:aSelector] is, according to the docs,  
identical to [self respondsToSelector:aSelector]. And since  
self.delegate, in the sample app, returns self, this is indeed an  
infinite loop. But, does UITextField implement -respondsToSelector: as  
above?



Since -delegate is going to return self, -respondsToSelector: is going
to result in infinite recursion.


True. So, the question is, again: does UITextField implement - 
respondsToSelector: as above?


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: [iPhone] Why can't a UITextField be its own delegate?

[Kyle Sluder]

On Jul 25, 2009, at 3:36 PM, WT  wrote:

No. -delegate returns the "outside" delegate, not self. As I said,  
from the outside world, everything is business as usual. If you call  
-setDelegate: to set yourself up as the delegate, then you are  
what's returned by a call to -delegate.


If that were the case then your delegate insertion technique would be  
useless, since whenever UITextField wanted to ask it's delegate for  
something it would always get the external object.


--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: [iPhone] Why can't a UITextField be its own delegate?

[Adam R. Maxwell]

On Jul 25, 2009, at 3:23 PM, Kyle Sluder wrote:


Internally, UITextField is going to use self.delegate to get its
delegate, following the correct accessor behavior.  You've gone and
replaced -delegate to return self.  But the delegate pattern says that
messages which this object does not understand should be forwarded to
the delegate.  This means that a class with a delegate needs to
implement -respondsToSelector: this way:

- (BOOL)respondsToSelector:(SEL)aSelector {
 return [super respondsToSelector:aSelector]
   || [self.delegate respondsToSelector:aSelector];
}


Where is this guaranteed by the delegate pattern?  I've created a fair  
number of classes with delegates and never done this; it would be  
interesting to know that I've been doing it wrong for years ;).




Since -delegate is going to return self, -respondsToSelector: is going
to result in infinite recursion.

So It's Never Safe To Make An Object Its Own Delegate.


Even if it's safe, it's a bizarre way to do something, especially if  
you're already subclassing it...especially since delegates are mainly  
used to avoid subclassing.  For the specific case of limiting text  
field input, why not just use an NSFormatter subclass, though?  That's  
what I'd do in Cocoa (and this is the cocoa-dev list, after all).





smime.p7s
Description: S/MIME cryptographic signature
___

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

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

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

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

Re: [iPhone] Why can't a UITextField be its own delegate?

[WT]

On Jul 26, 2009, at 12:23 AM, Kyle Sluder wrote:


On Sat, Jul 25, 2009 at 3:00 PM, WT wrote:
What if the delegates are already subclassed? Since multiple  
inheritance is
not an option, the code that limits the number of characters would  
have to

be repeated in several places.


You always have categories, but that's not necessarily a good idea.


True, but you can't add instance variables to categories and the code  
for limiting the number of characters (or a more general problem)  
needs some ivars.



If you find yourself in this situation (class C needs behavior from
both class B and class A), you can always collapse the class hierarchy
and turn A and B into class AB, with options to configure its
behavior.  That's how we wind up with things like NSController on the
desktop side, which can exist as an object controller or an entity
controller.


Now I'm the one who's going to say "that's convoluted". :)


This custom text field is still a text field in every way.


Then it should remain a UITextField.


There is no reason for any outside entity to want to refer to
super.delegate. In fact, unless I'm wrong, I don't think it's even  
possible

to retrieve super.delegate from the custom instance.


Ooh, I think we've found your bug.

Internally, UITextField is going to use self.delegate to get its
delegate, following the correct accessor behavior.  You've gone and
replaced -delegate to return self.


No. -delegate returns the "outside" delegate, not self. As I said,  
from the outside world, everything is business as usual. If you call - 
setDelegate: to set yourself up as the delegate, then you are what's  
returned by a call to -delegate.


I might be mistaken but I think even internally UITextField would see  
the outside delegate when it calls self.delegate. "self" tells the  
runtime system to start the search at the bottom, which is  
CustomTextField, not UITextField.



 But the delegate pattern says that
messages which this object does not understand should be forwarded to
the delegate.  This means that a class with a delegate needs to
implement -respondsToSelector: this way:

- (BOOL)respondsToSelector:(SEL)aSelector {
 return [super respondsToSelector:aSelector]
   || [self.delegate respondsToSelector:aSelector];
}

Since -delegate is going to return self, -respondsToSelector: is going
to result in infinite recursion.

So It's Never Safe To Make An Object Its Own Delegate.


You might be on to something here... I have to think about the above.

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: [iPhone] Why can't a UITextField be its own delegate?

[Kyle Sluder]

On Sat, Jul 25, 2009 at 3:00 PM, WT wrote:
> What if the delegates are already subclassed? Since multiple inheritance is
> not an option, the code that limits the number of characters would have to
> be repeated in several places.

You always have categories, but that's not necessarily a good idea.
If you find yourself in this situation (class C needs behavior from
both class B and class A), you can always collapse the class hierarchy
and turn A and B into class AB, with options to configure its
behavior.  That's how we wind up with things like NSController on the
desktop side, which can exist as an object controller or an entity
controller.

> This custom text field is still a text field in every way.

Then it should remain a UITextField.

> There is no reason for any outside entity to want to refer to
> super.delegate. In fact, unless I'm wrong, I don't think it's even possible
> to retrieve super.delegate from the custom instance.

Ooh, I think we've found your bug.

Internally, UITextField is going to use self.delegate to get its
delegate, following the correct accessor behavior.  You've gone and
replaced -delegate to return self.  But the delegate pattern says that
messages which this object does not understand should be forwarded to
the delegate.  This means that a class with a delegate needs to
implement -respondsToSelector: this way:

- (BOOL)respondsToSelector:(SEL)aSelector {
  return [super respondsToSelector:aSelector]
|| [self.delegate respondsToSelector:aSelector];
}

Since -delegate is going to return self, -respondsToSelector: is going
to result in infinite recursion.

So It's Never Safe To Make An Object Its Own Delegate.

--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: [iPhone] Why can't a UITextField be its own delegate?

[WT]

Not if the delegates are already subclassed from classes not sharing a  
common ancestor. Even if they have a common ancestor, I might not have  
access to the source code for the ancestor so I might not be able to  
refactor the common code to that level. The end result is having to  
repeat code in several classes.


On Jul 25, 2009, at 11:46 PM, Luke the Hiesterman wrote:


That approach makes much more sense.

Luke

On Jul 25, 2009, at 2:44 PM, Kyle Sluder wrote:


On Sat, Jul 25, 2009 at 1:14 PM, WT wrote:
This particular text field needs to limit its number of characters  
to a
given interval. Why should any other object have to deal with that  
problem
when the field itself can take care of it? Still, it might be the  
case,

though it also might not be the case, that another object wants to
participate in the editing session. The flow of events here is as  
follows:
the field takes care of its own business first (limiting the  
number of
characters) and then allows the delegate, if any, to have its shot  
at the

editing process.


In the Cocoa world, it makes more sense to hook up a delegate to do
this work, especially if this is a one-off control.  It comes down to
thinking of it as "a text field which limits number of characters"
rather than "a number-of-characters-limited text field".  If you need
this behavior in multiple places in your application, you can factor
out the delegate behavior into a superclass and have your delegates
derive from it, calling this method when necessary.

--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: [iPhone] Why can't a UITextField be its own delegate?

[WT]

On Jul 25, 2009, at 11:44 PM, Kyle Sluder wrote:


On Sat, Jul 25, 2009 at 1:14 PM, WT wrote:
This particular text field needs to limit its number of characters  
to a
given interval. Why should any other object have to deal with that  
problem
when the field itself can take care of it? Still, it might be the  
case,

though it also might not be the case, that another object wants to
participate in the editing session. The flow of events here is as  
follows:
the field takes care of its own business first (limiting the number  
of
characters) and then allows the delegate, if any, to have its shot  
at the

editing process.


In the Cocoa world, it makes more sense to hook up a delegate to do
this work, especially if this is a one-off control.  It comes down to
thinking of it as "a text field which limits number of characters"
rather than "a number-of-characters-limited text field".  If you need
this behavior in multiple places in your application, you can factor
out the delegate behavior into a superclass and have your delegates
derive from it, calling this method when necessary.


What if the delegates are already subclassed? Since multiple  
inheritance is not an option, the code that limits the number of  
characters would have to be repeated in several places.


On Jul 25, 2009, at 11:20 PM, Luke the Hiesterman wrote:

If you simply called your new delegate something other than  
"delegate" - like "myCustomClassDelegate" or whatever then it  
wouldn't be convoluted. But overloading self.delegate is not a good  
idea at all.



This custom text field is still a text field in every way. It simply  
performs some work between the editing done by super and the editing  
done by the delegate.


There is no reason for any outside entity to want to refer to  
super.delegate. In fact, unless I'm wrong, I don't think it's even  
possible to retrieve super.delegate from the custom instance.


My understanding is that super is not an object but merely a  
"directive" to the compiler instructing it where to start the search  
for a method implementation.  Moreover, all delegate methods are  
implemented by the custom class and they all query the outside  
delegate as needed.


Thus, as far as any clients of the custom class are concerned, a  
delegate of the custom instance is as true a delegate as the delegate  
of any non-subclassed UITextField. There is no way, as far as I can  
see, that an outside entity could ascertain that the delegate reported  
by calling -delegate is not the true delegate.


Also, I think it would be confusing for a client of the custom class  
to have to set itself as a custom delegate when it's trying to do what  
it would normally do as a regular delegate. Moreover, what would  
prevent it from setting itself up as the true delegate? Given the  
choice of calling -setDelegate and -setCustomDelegate, what would one  
do?


The way I'm doing this, everything is as transparent as possible. You  
call -setDelegate to set yourself up as the delegate just as you would  
if this text field was a regular UITextField, and when you call - 
delegate you get the correct object as well.


The custom class is then a perfect replacement for a regular  
UITextField. Other than replacing [[UITextField alloc] init] with  
[[CustomTextField alloc] init], there are NO changes to client code  
anywhere.


Can you give me an example of a situation where this might be a bad  
idea? I really can't see any.


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: [iPhone] Why can't a UITextField be its own delegate?

[Luke the Hiesterman]

That approach makes much more sense.

Luke

On Jul 25, 2009, at 2:44 PM, Kyle Sluder wrote:


On Sat, Jul 25, 2009 at 1:14 PM, WT wrote:
This particular text field needs to limit its number of characters  
to a
given interval. Why should any other object have to deal with that  
problem
when the field itself can take care of it? Still, it might be the  
case,

though it also might not be the case, that another object wants to
participate in the editing session. The flow of events here is as  
follows:
the field takes care of its own business first (limiting the number  
of
characters) and then allows the delegate, if any, to have its shot  
at the

editing process.


In the Cocoa world, it makes more sense to hook up a delegate to do
this work, especially if this is a one-off control.  It comes down to
thinking of it as "a text field which limits number of characters"
rather than "a number-of-characters-limited text field".  If you need
this behavior in multiple places in your application, you can factor
out the delegate behavior into a superclass and have your delegates
derive from it, calling this method when necessary.

--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: [iPhone] Why can't a UITextField be its own delegate?

[Kyle Sluder]

On Sat, Jul 25, 2009 at 1:14 PM, WT wrote:
> This particular text field needs to limit its number of characters to a
> given interval. Why should any other object have to deal with that problem
> when the field itself can take care of it? Still, it might be the case,
> though it also might not be the case, that another object wants to
> participate in the editing session. The flow of events here is as follows:
> the field takes care of its own business first (limiting the number of
> characters) and then allows the delegate, if any, to have its shot at the
> editing process.

In the Cocoa world, it makes more sense to hook up a delegate to do
this work, especially if this is a one-off control.  It comes down to
thinking of it as "a text field which limits number of characters"
rather than "a number-of-characters-limited text field".  If you need
this behavior in multiple places in your application, you can factor
out the delegate behavior into a superclass and have your delegates
derive from it, calling this method when necessary.

--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: [iPhone] Why can't a UITextField be its own delegate?

[WT]

Convoluted? I don't see it that way.

This particular text field needs to limit its number of characters to  
a given interval. Why should any other object have to deal with that  
problem when the field itself can take care of it? Still, it might be  
the case, though it also might not be the case, that another object  
wants to participate in the editing session. The flow of events here  
is as follows: the field takes care of its own business first  
(limiting the number of characters) and then allows the delegate, if  
any, to have its shot at the editing process.


And since limiting the number of characters is always going to happen  
but having extra work might not, it does not make sense to me to  
burden an extra object with both tasks. Let the field take care of its  
own business since it can do so cleanly. All other objects shouldn't  
care.


In any case, none of this has anything to do with the problem I  
mentioned. The sample application has no extra delegates and, in fact,  
does nothing whatsoever other than having the field be its own delegate.


Incidentally, I tried the same thing with a Mac application and it  
works fine. It's only under the iPhone SDK that setting a text field  
to be its own delegate causes a problem. The documentation for  
UITextField says nothing about any restrictions about which objects  
can and cannot be the field delegate and I can't see a reason why the  
field can't be its own delegate, so I'm inclined to think that this is  
a real bug in the iPhone SDK. As usual, though, I'd like to hear other  
people's input on the matter, because I might be missing something.


Wagner

On Jul 25, 2009, at 9:47 PM, Luke the Hiesterman wrote:

Wow, this all sounds very convoluted. If you must have two levels of  
delegation (which sounds like flawed design, to me) then I would  
suggest doing it in a more straightforward manner. That is, make a  
delegate for UITextField, and then have another delegate protocol  
for that object so it can have its own delegate. Even better, just  
wrap everything you need into the object you set as delegate to  
UITextField and don't try to shove weird things into a subclass.


Luke

On Jul 25, 2009, at 12:39 PM, WT wrote:


The reason is simple, though probably not obvious.

I still might need the text field to have an "outside" delegate,  
which I maintain by having an additional outlet reserved for that  
delegate. Then, I override -delegate to return that outlet and - 
setDelegate: to set it.


That way, the field can be its own true delegate and do its job,  
while also allowing an outside object to serve as a delegate and  
participate in the editing session. As far as the outside world is  
concerned, it's business as usual.


But once I have an overridden -setDelegate:, I can't use  
self.delegate = self to set the field as its own true delegate,  
because that will execute the overridden method.


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: [iPhone] Why can't a UITextField be its own delegate?

[Luke the Hiesterman]

Wow, this all sounds very convoluted. If you must have two levels of  
delegation (which sounds like flawed design, to me) then I would  
suggest doing it in a more straightforward manner. That is, make a  
delegate for UITextField, and then have another delegate protocol for  
that object so it can have its own delegate. Even better, just wrap  
everything you need into the object you set as delegate to UITextField  
and don't try to shove weird things into a subclass.


Luke

On Jul 25, 2009, at 12:39 PM, WT wrote:


The reason is simple, though probably not obvious.

I still might need the text field to have an "outside" delegate,  
which I maintain by having an additional outlet reserved for that  
delegate. Then, I override -delegate to return that outlet and - 
setDelegate: to set it.


That way, the field can be its own true delegate and do its job,  
while also allowing an outside object to serve as a delegate and  
participate in the editing session. As far as the outside world is  
concerned, it's business as usual.


But once I have an overridden -setDelegate:, I can't use  
self.delegate = self to set the field as its own true delegate,  
because that will execute the overridden method.


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: [iPhone] Why can't a UITextField be its own delegate?

[WT]

On Jul 25, 2009, at 9:17 PM, Brian Slick wrote:


I won't pretend to know the answer, but this struck me as odd:

On Jul 25, 2009, at 3:06 PM, WT wrote:


- (void) awakeFromNib
{
  super.delegate = self;
  super.text = @"Hello world";

  NSLog(@"awakeFromNib called - delegate set to self");
}



Shouldn't it be [self setDelegate: self]?  I wouldn't think you'd  
have an actual 'super' object available to perform the delegate  
methods.


But I probably don't understand.

Brian


The reason is simple, though probably not obvious.

I still might need the text field to have an "outside" delegate, which  
I maintain by having an additional outlet reserved for that delegate.  
Then, I override -delegate to return that outlet and -setDelegate: to  
set it.


That way, the field can be its own true delegate and do its job, while  
also allowing an outside object to serve as a delegate and participate  
in the editing session. As far as the outside world is concerned, it's  
business as usual.


But once I have an overridden -setDelegate:, I can't use self.delegate  
= self to set the field as its own true delegate, because that will  
execute the overridden method.


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: [iPhone] Why can't a UITextField be its own delegate?

[Brian Slick]

I won't pretend to know the answer, but this struck me as odd:

On Jul 25, 2009, at 3:06 PM, WT wrote:


- (void) awakeFromNib
{
   super.delegate = self;
   super.text = @"Hello world";

   NSLog(@"awakeFromNib called - delegate set to self");
}



Shouldn't it be [self setDelegate: self]?  I wouldn't think you'd have  
an actual 'super' object available to perform the delegate methods.


But I probably don't understand.

Brian

___

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

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

[iPhone] Why can't a UITextField be its own delegate?

[WT]

Hello all,

I need to create a subclass of UITextField for a text field that  
performs some control over its own editing. The obvious idea is to  
make the subclass instance set itself up as its own delegate, but that  
freezes the app as soon as the delegate method - 
textFieldDidBeginEditing returns.


Looking at Activity Monitor, the CPU usage of the app goes up to  
nearly 100%. I've since created the most trivial app with a  
UITextField subclass that conforms to the UITextFieldDelegate protocol  
and which sets itself up as its own delegate and, sure enough, the app  
freezes.


Here's the subclass. Set up a project then add a text field to a view  
and make its class be CustomTextField. Compile and run, and watch it  
freeze when you attempt to edit the text in the field.


So... why can't the field be its own delegate?

Thanks in advance.
Wagner


// CustomTextField.h:

#import 

@interface CustomTextField: UITextField 
{
}

@end

// CustomTextField.m:

#import "CustomTextField.h"

@implementation CustomTextField

- (void) awakeFromNib
{
super.delegate = self;
super.text = @"Hello world";

NSLog(@"awakeFromNib called - delegate set to self");
}

//  
= 
= 
= 
= 
= //


- (BOOL) textField: (UITextField*) text_field
 shouldChangeCharactersInRange: (NSRange) range
 replacementString: (NSString*) string
{
NSLog(@"-textField: shouldChangeCharactersInRange:  
replacementString:");

return YES;
}

//  
= 
= 
= 
= 
= //


- (BOOL) textFieldShouldBeginEditing: (UITextField*) text_field
{
NSLog(@"-textFieldShouldBeginEditing:");
return YES;
}

//  
= 
= 
= 
= 
= //


- (void) textFieldDidBeginEditing: (UITextField*) text_field
{
NSLog(@"-textFieldDidBeginEditing:");
}

//  
= 
= 
= 
= 
= //


- (BOOL) textFieldShouldEndEditing: (UITextField*) text_field
{
NSLog(@"-textFieldShouldEndEditing:");
return YES;
}

//  
= 
= 
= 
= 
= //


- (void) textFieldDidEndEditing: (UITextField*) text_field
{
NSLog(@"-textFieldDidEndEditing:");
}

//  
= 
= 
= 
= 
= //


- (BOOL) textFieldShouldClear: (UITextField*) text_field
{
NSLog(@"-textFieldShouldClear:");
return YES;
}

//  
= 
= 
= 
= 
= //


- (BOOL) textFieldShouldReturn: (UITextField*) text_field
{
NSLog(@"-textFieldShouldReturn:");
[self resignFirstResponder];
return YES;
}

//  
= 
= 
= 
= 
= //


@end

___

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

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