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.
Actually that’s false. What happens is that the decoding process is interrupted and the secure text field replaces the text field in the unarchived objects. It doesn’t decide an NSTextField object at any point.
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.
The gorm file that is used in that app (loginpanel) is very very old. I will do a few tests to make sure everything is ok.
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.
As I said above. I’ll research this. No one understands the custom class code as well as I do. I’ll make sure it’s working properly. I think this is a matter of an old gorm file
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?46410>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/