Follow-up Comment #1, bug #46410 (project gnustep):
I understand _what_ is happening here, but not _why_. What is happening:
A secure text field in a nib is stored as NSTextField with custom class set to
NSSecureTextField. So when the nib is loaded, you start off with a text field
and a text field cell.
There is code specifically designed to handle this case, in -gui:
GSNibLoading.m has -[NSClassSwapper unarchiver:didDecodeObject:] which is
explicitly documented to handle the NSSecureTextFieldCell case. It tests for
whether the new class responds to +cellName and replaces the cell object if
so.
What I see in that method is that _originalClassName is NSSecureTextField, but
newClass is NSTextField so +[newClass cell] returns NSTextFieldCell, and that
is what gets set on the nib.
I understand that reversing the sense of that test fixes the problem, but do
not understand that code well enough to know why that should be so or what
other effects would result.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?46410>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep
