gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Changes to NSControl


From: Nicola Pero
Subject: Re: Changes to NSControl
Date: Wed, 8 Jan 2003 01:41:59 +0000 (GMT)

> While working on the fix for the infamous selection error, that is 
> caused by selecting the text of a non editable cell, I noticed a few 
> more things on NSControl that would need changing. My fix for the 
> original error is simply to make the text object editable while setting 
> the text and switching back afterwards again.

Thanks for looking into this - you are right in that the problem seems to
be that calling -setText: on the NSTextView does nothing because the
NSTextView is not editable. :-)

But that is quite wrong, isn't it ?  You should still be able to set the
string of a textview programmatically, even if it's not editable (I'm
quite sure there is somewhere some documentation saying this).  

'editable' vs 'not editable' is something for the user.  But even if 'not
editable' (actually, particularly if not editable, because if not
editable, the only way to use the textview to display something, is to set
its string programmatically!) you should be able to set the string to be
displayed programmatically.

I wrote a small text on Mac OS X, and found that on Mac OS X, -setString:
and -replaceCharactersInRange:withString: work well no matter if the
textview is not editable or not.

I think this is a better behaviour, and that GNUstep is wrong. :-)

If you want to fix that bug, I think this is the way. :-)


> Perhaps the same is also needed while setting up the field editor, as 
> some of this methods also check if the NSTextView is editable?

See above, the behaviour we want is that the NSTextView prevents the user
from editing it if it's not editable, but still allows the basic
-setText:, -setString:, -replaceCharactersInRange:withString: etc methods
to be used programmatically.


> One of the strange things on NSControl I noticed is, that in the method 
> mouseDown: the action mask of the cell is changed before calling the 
> tracking code. Now this is the only place where the action mask is used 
> at all, so resetting it looks pointless to me. I would like to just drop 
> this code, that was probably a workaround for a problem now long gone.

Hmmm.

The action mask of the cell is used whenever the method
trackMouse:inRect:ofView:untilMouseUp: is called, which happens often in
the gui.

The code in NSControl.m currently sends the action periodically, if
continuous, then if the mouse went up in the cell, highlights the cell,
the sends the action again.

I suspect the action mask is changed to get this result (sending the
action after highlighting the cell, not before).

I'm not sure what's best without further investigations. :-/

Maybe the action mask of the cell should be checked, and if
NSLeftMouseUpMask is set, that specific flag in the mask would be
temporarily removed, and manually restored later, and the action would be
manually sent after highlighting the cell.  Other flags in the mask would
not be touched, and used as they are.  The action would not be sent when
mouse up, unless the NSLeftMouseUpMask flag is set in the mask.

Not sure.


> The second oddity is the way NSControl implements the field editor 
> methods. They are basically empty, although the documentation describes 
> them in detail. Instead we have them implemented on the subclasses 
> NSTextField, NSMatrix and NSTableView. I would suggest to move those 
> implementations up to NSControl. The drawback of this is, that we also 
> need the _text_object ivar in NSControl, which will never be used by 
> some of the subclasses, but this is a minor price we have to pay.

Ahm - I suppose you can use [self currentEditor] in NSControl to get the
current editor without knowing where it's stored in the subclass.

I'm happy with you factoring code in the editing methods ... but please be
very careful when touching those damned editing methods.  They are very
delicate and fragile -- just moving a single apparently innocent command
around usually breaks the whole thing. :-)

Probably we will factor out safely and clearly only part (or a few) of the
editing methods.  If done very carefully and prudently, that would be
quite nice!





reply via email to

[Prev in Thread] Current Thread [Next in Thread]