[bugs #9463] Changing the name of an outlet for a custom class fails

[Fred Kiefer]

This mail is an automated notification from the bugs tracker
 of the project: GNUstep.

/**************************************************************************/
[bugs #9463] Latest Modifications:

Changes by: 
                Fred Kiefer <FredKiefer@gmx.de>
'Date: 
                Sat 06/26/2004 at 11:45 (GMT)

------------------ Additional Follow-up Comments ----------------------------
I was the one who changed the NSTableView, so it is only fair that I did get 
the resulting problem. This change was made to allow other cells in a table 
view, for example combo boxes, to change their value without editing, that is 
just by a mouse click. So the code here is basically correct and needed. What 
we could change is to cache the value of the cell and see if it actually has 
changed.

There is an additonal idea from Matt Rice that the update should only be send 
when the sendsActionOnEndEditing method of the cell returns false and that 
NSTextFieldCell should set this to false. But I am still trying to understand 
the logic here






/**************************************************************************/
[bugs #9463] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=9463>
Project: GNUstep
Submitted by: Fred Kiefer
On: Sat 06/26/2004 at 00:18

Category:  Gorm
Severity:  3 - Ordinary
Item Group:  Bug
Resolution:  Fixed
Assigned to:  gcasa
Status:  Closed


Summary:  Changing the name of an outlet for a custom class fails

Original Submission:  Trying to change the name of a newly added outlet in a 
custom class (not a view) results in the exception:

Uncaught exception NSInvalidArgumentException, reason: Tried to init array with 
nil object

Follow-up Comments
------------------


-------------------------------------------------------
Date: Sat 06/26/2004 at 11:45       By: FredKiefer
I was the one who changed the NSTableView, so it is only fair that I did get 
the resulting problem. This change was made to allow other cells in a table 
view, for example combo boxes, to change their value without editing, that is 
just by a mouse click. So the code here is basically correct and needed. What 
we could change is to cache the value of the cell and see if it actually has 
changed.

There is an additonal idea from Matt Rice that the update should only be send 
when the sendsActionOnEndEditing method of the cell returns false and that 
NSTextFieldCell should set this to false. But I am still trying to understand 
the logic here

-------------------------------------------------------
Date: Sat 06/26/2004 at 03:47       By: gcasa
I have added some code in GormDocument's data source method 
"outlineView:setObjectValue:forTableColumn:byItem:" to correct the issue.  I'm 
also not certain that the behavior of NSTableView , as described in my previous 
note, is correct.  The change I made to Gorm should work correctly in either 
case.  GJC

-------------------------------------------------------
Date: Sat 06/26/2004 at 03:12       By: gcasa
I have tracked this to a recent change in the [NSTableView mouseDown:] method 
which calls:

                  [self _setObjectValue: [cell objectValue]
                        forTableColumn: tb
                        row: _clickedRow];
At NSTableView.m:3483

At this point the [cell objectValue] will always the current value of this 
since nothing has been changed in the cell.

Is there any reason for this?

This is what is causing the current breakage in Gorm and should cause issues in 
all other apps which use tables that accept data values typed by the user.

I am continuuing to look into the issue.

Also, this issue does not occur with the 0.9.3 release of GUI.

GJC

-------------------------------------------------------
Date: Sat 06/26/2004 at 01:22       By: gcasa
Recreated.   I was trying to do this through the class inspector, not the 
outline view.   Alex P. informed me that he was able to do it throught the menu 
and the outlineview, and I was able to see the issue.

The workaround to this issue is to use the inspector for class operations.  I 
have been considering removing the outline view recently as it would:

1) simplify code
2) avoid issues like this

However, a lot of people seem to like the outlineview as it is similar to the 
IB interface presented in OS4.2.

I believe I know what's causing this, so I should have a fix for it soon.

GJC

-------------------------------------------------------
Date: Sat 06/26/2004 at 01:04       By: gcasa
I am currently trying to recreat this without success.












For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=9463>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/