Re: AppKit Tool Problem

[Alexander Malmberg]

Andreas Hoeschler wrote:
> In the meanwhile I have found out which line in my tool causes the 
> problem.
> 
> NAME:NSInternalInconsistencyException REASON:GSFontInfo.m:70 Assertion 
> failed in GSFontEnumerator(class), method sharedEnumerator. Called with 
> fontEnumeratorClass unset. The shared NSApplication instance must be 
> created before methods that need the backend may be called.
> 
> It's the line
> 
>     _textField = [[NSTextField alloc] init];
> 
> This text filed is not even used at this step. Just allocating an 
> NSTextField seems to fire the backend.

An NSTextField has a font, so when initializing, it needs to create a
suitable NSFont instance, and the backend is required to do that.

> In earlier versions of GNUstep 
> this was no problem.

Earlier versions didn't check for this in many cases, but this caused
problems in real apps: either you get an automatic call to
-sharedApplication, possibly of the wrong class, or the NSTextField
fails later (at least when it's actually used to display text :) because
the font is nil.

> The reason why I do this in a tool is that a need 
> to convert NSCalendarDate --> NSString and vice versa. I simply used
> 
>            _textField = [[NSTextField alloc] init];
>            [[_textField cell] setFormatter:formatter];
>            return  [_textField objectValue];
> 
> This is a bit hackish, but it worked until now. Any idea how to avoid 
> the NSTextField approach

Something like:

id returnValue;
NSString *error;
if (![formatter getObjectValue: &returnValue
        forString: theString
        errorDescription: &error])
{
        /* String wasn't a valid date. */
}
return [returnValue autorelease];

As before, an alternative would be to write a dummy backend that would
keep -gui happy without needing a real display.

- Alexander Malmberg