[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gui fixes
From: |
Fred Kiefer |
Subject: |
Re: gui fixes |
Date: |
Tue, 04 Sep 2007 21:27:32 +0200 |
User-agent: |
Thunderbird 1.5.0.12 (X11/20060911) |
Andreas Höschler wrote:
>> I used the following two methods on NSActionCell in my patch. Couls you
>> please check, whether they also result in a loop?
>>
>> - (id)objectValue
>> {
>> if (_control_view)
>> if ([_control_view isKindOfClass: controlClass])
>> [(NSControl *)_control_view validateEditing];
>> return [super objectValue];
>> }
>>
>> /**
>> * Retrieve the value of the receiver as an NSAttributedString.
>> */
>> - (NSAttributedString*)attributedStringValue
>> {
>> if (_control_view)
>> if ([_control_view isKindOfClass: controlClass])
>> [(NSControl *)_control_view validateEditing];
>> return [super attributedStringValue];
>> }
>>
>> Even for your code, I don't see how this could result in a loop.
>
> But it does loop! I edeitz a cell (with a formatter) in a tableview and
> tab to the next cell. While this next cell is in editing mode it loops.
> The method NSTableView validateEditing is called over and over. When
> click anywhere into the tableview to abort editing the cell, the loop
> stops!?
>
> #0 0xfdac1500 in _write () from /lib/libc.so.1
> #1 0xfdab2bb0 in write () from /lib/libc.so.1
> #2 0xfde3cdc0 in _NSLog_standard_printf_handler (message=0x258d518)
> at NSLog.m:174
> #3 0xfde3d618 in NSLogv (format=0x203cde8, args=0xffbfd438) at NSLog.m:357
> #4 0xfde3ce84 in NSLog (format=0xff139e88) at NSLog.m:253
> #5 0xfef0f7f0 in -[NSTableView validateEditing] (self=0x29e3fa8,
> _cmd=0xff1025e0) at NSTableView.m:3167
> #6 0xfecf5c40 in -[NSActionCell attributedStringValue] (self=0x1f61840,
> _cmd=0xff10e72c) at NSActionCell.m:54
> #7 0xfed7a87c in -[NSCell drawInteriorWithFrame:inView:] (self=0x1f61840,
> _cmd=0xfcf26868, cellFrame=
> {origin = {x = 689, y = 65.5}, size = {width = 49, height = 13}},
> controlView=0x29e3fa8) at NSCell.m:1952
> #8 0xfcee7038 in -[NSTextFieldCell(theme) drawInteriorWithFrame:inView:] (
> self=0x1f61840, _cmd=0xfcf26868, cellFrame=
> {origin = {x = 689, y = 65.5}, size = {width = 49, height = 13}},
> controlView=0x29e3fa8) at NSTextFieldCell.m:29
> #9 0xfcee7340 in -[NSTextFieldCell(theme) drawWithFrame:inView:] (
> self=0x1f61840, _cmd=0xfcf21238, cellFrame=
> {origin = {x = 689, y = 65.5}, size = {width = 49, height = 13}},
> controlView=0x29e3fa8) at NSTextFieldCell.m:63
> #10 0xfced64c0 in -[NSTableView(theme) drawRow:clipRect:] (self=0x29e3fa8,
> ---Type <return> to continue, or q <return> to quit---
> _cmd=0xfcf211d8, rowIndex=4, clipRect=
> {origin = {x = 0, y = 0}, size = {width = 912, height = 164}})
> at NSTableView.m:376
> #11 0xfced5e48 in -[NSTableView(theme) drawRect:] (self=0x29e3fa8,
> _cmd=0xff13e820, aRect=
> {origin = {x = 0, y = 0}, size = {width = 912, height = 164}})
> at NSTableView.m:293
You back trace did not show a loop, it just shows that validateEditing
gets called over and over again. And yes, we should try to avoid this.
Let's add an ivar to NSControl to store whether the editing has been
already validated. This would be set to invalid in the textDidChange
method and set to valid at the end (or begin?) of validateEditing. And
validateEditing just returns if this value is already set. Does this
make sense?
Another question is of course how we could avoid to redisplay the cell
while it gets edited. There is no chance to see what ever we draw here,
so why do we draw it at all? Now I just checked this and NSTableView
makes sure, we don't draw a cell while it gets edited. So the validation
you see comes actualy from the other cell, the one that isn't edited.
Perhaps we should just add an ivar to the cell to flag it is currently
being edited. This would be set in setUpFieldEditorAttributes: and
cleared in endEditing:. Only when this is set, we call validateEditing,
when the value of the cell is requested.
And is this instead of the optimisation on the control or in addition to
that? I will need some more comments here
Fred