0

I have a subclass of NSTextField and I setting the LineBreakMode.

It works fine under my mac with Yosemite and Crashes for one of my users on Mavericks

Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[XTextField setLineBreakMode:]: unrecognized selector sent to instance 0x7fc784548ad0'

How could I work this round ?

Header File of the subclass

#import <Cocoa/Cocoa.h>

@interface XTextField : NSTextField

- (void)setText:(NSString *)text

@end

Implementation

#import "XTextField.h"
@implementation XTextField

- (void)setText:(NSString *)text
{
    if (text)
    {
        [self setStringValue:text];
    }
    else
    {
        [self setStringValue:@""];
    }
 }


 - (instancetype)initWithFrame:(NSrect)frame
 {
     if(self = [super initWithFrame:frame])
     {
         [self setEditable:NO];
         [self setSelectable:NO];
         [self setDrawsBackGround:NO];
         [self setBezeled:NO];
     }
     return self;
 }
 @end

Calling code:

XTextField* myLabel = [[XTextField alloc]initWithFrame:myFrame];
[myLabel settext:@"text text text"];
[myLabel setLineBreakMode:NSLineBreakByTruncatingTail];
Coldsteel48
  • 3,482
  • 4
  • 26
  • 43
  • did you check your outlet for textfield...and post some code – Bhavin Bhadani Oct 01 '15 at 08:25
  • @EICaptain I don't have outlets it is programmatically made NSTextFieldSubClass – Coldsteel48 Oct 01 '15 at 08:26
  • @EICaptain I posted the code line where crashes what else code to post ? `NSTextFieldSubClass` is a simple subclass that only renames a method `setStringValue` to `setText` – Coldsteel48 Oct 01 '15 at 08:34
  • could you edit your question to show how you declare your "`NSTextFieldSubClass`" (e.g. the contents of the .h file and/or what the "`@interface`" looks like). Also, subclasses should ***NEVER*** start with "`NS`", as that might confuse other people looking at your code into thinking it's an Apple-supplied class from the iOS SDK. – Michael Dautermann Oct 01 '15 at 11:28
  • @MichaelDautermann Sure, just a sec. (P.S. it doesn't start with "`NS`" I renamed it here for the readable reasons to show that it is a Subclass Of `NSTextField` – Coldsteel48 Oct 01 '15 at 12:13

1 Answers1

2

There are lots of questions that need to be answered here. The problem, as indicated by the error message, is that the setLineBreakMode: selector was sent to an object that doesn't recognize that selector. What could be happening that would cause that? Figuring things like this out requires critical thinking and detective work. Here are some ideas.

  1. -setLineBreakMode: does not seem to actually be implemented by NSTextField; it is a method of NSCell, and of NSMutableParagraphStyle, as far as I can tell. If you have an NSTextField (or a subclass of it) you'd normally call [[myTextField cell] setLineBreakMode:...], but your code snippet doesn't indicate that you are doing that. So unless you implemented this method in your subclass – which you don't state that you did – this is probably the reason for the crash. Perhaps you don't see the crash on your Mac because this code path doesn't get hit, for whatever reason? Or perhaps Apple privately implemented this method in Yosemite but not in Mavericks? Who knows. Do you get a warning from the compiler on that line, saying that the object does not respond to that selector? Do not ignore compiler warnings.

  2. The code you posted looks like you are calling setLineBreakMode: on the class object, not on an instance of the class; normally classes start with a capital letter, whereas instances start with a lowercase letter. Obeying coding conventions like this makes things much less confusing for everybody. And if your subclass is really named NSTextFieldSubClass, then I agree with @MichaelDautermann that you should never, ever name classes with an NS prefix; that is both confusing and asking for trouble, since for all you know Apple has a private subclass with exactly that name. Class names beginning with NS are reserved by Apple.

  3. It could be that the object you think is in the variable that you have apparently named NSTextFieldSubClass is not an instance of your subclass at all, or has been freed (and perhaps replaced by a new object at the same address), or some such problem, and that that is why it doesn't respond to the selector. You could investigate this by turning on NSZombieEnabled, examining it in the debugger, adding an NSLog of it (perhaps with an added -description method in your subclass), or many other techniques.

That's all pretty vague, but then the question is vague. You need to post the code for your subclass, the code where you instantiate the subclass, and the code surrounding the line that crashes, at a minimum, to get more specific help. We can't read your mind, and the root of the bug may well be in one of those places.

bhaller
  • 1,803
  • 15
  • 24
  • I updated my question with actual code. Seems like you are right about the `cell` I will try that. – Coldsteel48 Oct 01 '15 at 12:30
  • I didn't implement the `setLineBreakingMode` method but I think I will just implement it in my subclass (which is not starting with NS) this method and I guess it's implementation should be just `[self.cell setLineBreakMode:mode];` – Coldsteel48 Oct 01 '15 at 12:33
  • Thank you for your answer sir! – Coldsteel48 Oct 01 '15 at 12:34
  • 1
    The confusion was because: when I was typing `[myLabel setLine..]` Xcode autocompleted it so I thought it is legit method of the `NSTextField` but I reviewed documentation of the `NSTextField` and there is no such method -- Also no warnings were shown – Coldsteel48 Oct 01 '15 at 12:36
  • I'm surprised you didn't get a warning, and that Xcode autocompleted it for you. If a variable is of type `id` then anything goes – any selector is considered acceptable, broadly speaking. But if a variable has a specific type, as yours apparently does, then normally selectors get type-checked by both Xcode's completion and by the compiler. There might be a warning setting for this that you need to turn on to get the warning, but I thought this particular warning was automatic. Hmm. Is the calling code in a file that has a `#import "XTextField.h"`? – bhaller Oct 01 '15 at 12:45
  • Yes the file has an `#import "XTextField.h"` Also the Xcode settings are default I never messed with them not to mention I just acquired a fresh copy of Xcode 7.01, which broke in update so i had to completely remove the old Xcode 7 and download 7.01 as a fresh copy of Xcode - Never touched the flags compiler warnings and non of those build settings – Coldsteel48 Oct 01 '15 at 12:58
  • Also yes as you may see - in `init` method i returning as `instancetype` which i believe is `XTextField*` :-/ – Coldsteel48 Oct 01 '15 at 13:04
  • 1
    Well, odd. The question of why you're not getting proper warnings for calling undeclared selectors, and proper type-based selector completion, might be a new stackoverflow question (if that question doesn't already exist). Getting proper warnings/completion is important, as this question illustrates. Anyhow, good luck, glad the present issue is resolved. – bhaller Oct 01 '15 at 14:09
  • Yes you are right, there might be even more issues like that... And I will not know... Btw compiler does warn me on missing selectors... It was only 2 like this now: 1) I mistakenly setViewController to NSWindow (Because that what I normally do in iOS) and compiler didn't warn + autocompleted this and now the NSTexrField... – Coldsteel48 Oct 01 '15 at 14:30
  • Well when I added the method to my subclass Xcode kindly autocompleted it... :) – Coldsteel48 Oct 01 '15 at 17:50