[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSTableView editing problem [Was: Next stable release?]
From: |
Matt Rice |
Subject: |
Re: NSTableView editing problem [Was: Next stable release?] |
Date: |
Sun, 8 Jun 2008 12:08:18 -0700 |
On Sun, Jun 8, 2008 at 10:57 AM, Fred Kiefer <address@hidden> wrote:
> I was completely wrong here. The problem is at a totally different place.
> Look at the code in NSTextFieldsCell that Nicola changed a few months ago:
>
Ahh, yes changing the below fixes it here i was confused because it is
asked to redraw the edited cell frame, but in the case that it is, the
code is doing what it should by not redrawing.
>
> - (void) drawInteriorWithFrame: (NSRect)cellFrame inView:
> (NSView*)controlView
> {
> /* Do nothing if there is already a text editor doing the drawing;
> * otherwise, we draw everything twice. That is bad if there are
> * any transparency involved (eg, even an anti-alias font!) because
> * if the semi-transparent pixels are drawn over themselves they
> * become less transparent (eg, an anti-alias font becomes darker
> * and gives the impression of being bold).
> */
> if (([controlView respondsToSelector: @selector(currentEditor)] == NO)
> || ([(NSTextField *)controlView currentEditor] == nil))
> {
> if (_textfieldcell_draws_background)
> {
> if ([self isEnabled])
> {
> [_background_color set];
> }
> else
> {
> [[NSColor controlBackgroundColor] set];
> }
> NSRectFill([self drawingRectForBounds: cellFrame]);
> }
>
> [super drawInteriorWithFrame: cellFrame inView: controlView];
> }
> }
>
> This basically means that a text field cell will only draw itself, when
> there is no editor for the containing control view. This is nice and fine,
> when the text field cell is the only cell of a text field, but in the matrix
> and table view case this stops all the cells in the controller from drawing
> themselves while there is an editor.
>
> How to get of this trap? We could check if the cell is the selected cell of
> its control view and only then not draw it in the editing case. This may
> work as a table view has no clear notion of a selected cell and so all cells
> will still get drawn, whereas matrix and normal control handle this
> correctly.
>
> Another possibility is to move the "don't draw" check into the control view.
> This looks better to me. A cell should always draw itself when asked to do
> so, the decision should be put somewhere else.
>
that seems alright to me, and appears to be what drawRow:clipRect: in
NSTableView is already doing. i've looked at the bug report that code
was added for but didn't have any luck reproducing it with the fix
disabled...
> Any better ideas out there?
>
no but thanks for looking into this.
- Re: Next stable release?, (continued)
- Re: Next stable release?, Fred Kiefer, 2008/06/06
- Re: Next stable release?, Matt Rice, 2008/06/06
- Re: Next stable release?, Fred Kiefer, 2008/06/06
- Re: Next stable release?, Matt Rice, 2008/06/07
- NSTableView editing problem [Was: Next stable release?], Fred Kiefer, 2008/06/08
- Re: NSTableView editing problem [Was: Next stable release?], Fred Kiefer, 2008/06/08
- Re: NSTableView editing problem [Was: Next stable release?],
Matt Rice <=
- Re: NSTableView editing problem [Was: Next stable release?], Fred Kiefer, 2008/06/09
- Re: Next stable release?, Adam Fedor, 2008/06/07
Re: Next stable release?, Gürkan Sengün, 2008/06/06
RE: Next stable release?, Nicola Pero, 2008/06/05
Re: Next stable release?, Gregory John Casamento, 2008/06/06
Re: Next stable release?, Gregory John Casamento, 2008/06/06