[Top][All Lists]

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

[bugs #10949] Gorm/NSTableView weirdness

From: Gregory John Casamento
Subject: [bugs #10949] Gorm/NSTableView weirdness
Date: Tue, 23 Nov 2004 20:46:49 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040921

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

[bugs #10949] Latest Modifications:

Changes by: 
                Gregory John Casamento <address@hidden>
                Wed 11/24/2004 at 01:41 (US/Eastern)

            What     | Removed                   | Added
              Status | Open                      | Closed

[bugs #10949] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=10949>
Project: GNUstep
Submitted by: 0
On: Tue 11/09/2004 at 00:30

Category:  Gorm
Severity:  5 - Average
Item Group:  Bug
Resolution:  Invalid
Privacy:  Private
Assigned to:  gcasa
Status:  Closed

Summary:  Gorm/NSTableView weirdness

Original Submission:  (Note: This may also be an AppKit issue, but it's far 
easier to reproduce this condition under Gorm, so this is how I'm categorizing 
this report.)

The first issue (there are two, but they seem very related) is that when I 
click in the rightmost portion of any NSTableView, an error, "not in frame, 
what's happening ?" is printed to standard output.

The second issue is that under particular circumstances, the column headers of 
an NSTableView are not drawn correctly.  When this happens, the far right 
column is drawn in the left, and all other column headers aren't rendered.

To reproduce this: use Gorm 0.8.0 (or from CVS) to make a new application.  
Drop one NSTableView onto the main window, then drop another.  When running a 
program with this interface, the first NSTableView you dropped onto the window 
will not render correctly.  The second one does.  However, both NSTableView 
column headers cause the program to print "not in frame, what's happening ?" to 
stdout when clicked on the far right.

Neither of these problems show up when using Gorm's "Test Interface".

A quick workaround: when you resize an NSTableView at runtime, both of the 
issues above disappear.

I've attached and thrown together a program that demonstrates all of these 

- Kairi Nakatsuki <address@hidden>
http://kanaka.jp/kairi.asc - AE0A 3566 B8BC D11B ACAA  4354 25CC 4A6F 6427 1D85

Follow-up Comments

Date: Wed 11/24/2004 at 01:18       By: Gregory John Casamento <gcasa>
>From looking at the .gorm and the code neither the delegate, nor the 
>datasource of either table is correctly set in the code or connected in the 
>.gorm file.  In order for the table to show anything it must have a datasource.

The reason the tables are showing okay in Gorm  (even in test mode) is due to 
the fact that Gorm provides a sample datasource so that you can get an idea 
what the table will look like when filled in.

Please look at the Apple documentation or GNUstep's documentation for 
NSTableView to learn more about NSTableView.

Please see the attached .jpg.

NOTE: There was a bug in NSTableView which was corrected to allow the drawing 
of the tablecolumns when the table isn't connected to a datasource in the 
latest CVS of GNUstep.

This is developer error and is not an issue in the current CVS of either Gorm 
or GNUstep.   GJC

File Attachments

Date: Wed 11/24/2004 at 01:18  Name: table.jpg  Size: 6.17KB   By: gcasa


Date: Tue 11/09/2004 at 00:30  Name: Test.tar.gz  Size: 28.11KB   By: None
An instance of this NSTableView weirdness.

For detailed info, follow this link:

  Message sent via/by Savannah

reply via email to

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