[bug #6354] Failing to load a .gorm which uses a NSImageView custom class in a NSScrollView

[nobody]

=================== BUG #6354: LATEST MODIFICATIONS ==================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=6354&group_id=99

Changes by: Gregory John Casamento <greg_casamento@yahoo.com>
Date: Sun 11/23/2003 at 16:26 (US/Eastern)

            What     | Removed                   | Added
---------------------------------------------------------------------------
              Status | Analyzed                  | Closed


------------------ Additional Follow-up Comments ----------------------------
Given the analysis done by Alex, I am closing this.



=================== BUG #6354: FULL BUG SNAPSHOT ===================


Submitted by: gcasa                   Project: GNUstep                      
Submitted on: Tue 11/04/2003 at 03:39
Category:  Gui/AppKit                 Severity:  3                          
Bug Group:  Bug                       Resolution:  Fixed                    
Assigned to:  gcasa                   Status:  Closed                       

Summary:  Failing to load a .gorm which uses a NSImageView custom class in a 
NSScrollView

Original Submission:  This only occurs when the application is using 
NSWindowController and uses a NSScrollView which contains an instance of a 
custom class (specifically a subclass of NSImageView).   I have been unable to 
recreate this under any other circumstance.



I don't believe this to be a Gorm issue since the Gorm file loads and saves 
find and upon inspection doesn't appear to have any problems.

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

-------------------------------------------------------
Date: Sun 11/23/2003 at 16:25       By: gcasa
Given the analysis done by Alex, I am closing this.

-------------------------------------------------------
Date: Sat 11/22/2003 at 09:20       By: alexm
The root cause is that the app in question makes calls that manipulate the view 
hierarchy from -drawRect:. It removes the NSScroller subviews of the 
NSScrollView. This confuses the display machinery which still tries to make 
calls to the NSScroller:s that are now outside the view hierarchy, and this 
causes the exception.



Recovery from the exception fails because the gorm-loading code is releasing 
all connections twice, leading to memory corruption and, usually, a segfault. 
I've fixed this part in cvs.





As I see it, view manipulation from inside the display machinery (including 
-drawRect:) is not allowed, and changing the view hierarchy is definately an 
error. Thus, I consider this an application error.



Since this was pretty obscure and took a bit of work to track down, I'll try to 
get some asserts in place to catch view hierarchy manipulation during 
displaying earlier.



-------------------------------------------------------
Date: Sun 11/09/2003 at 20:07       By: gcasa
Tried this with all other types of containers and it works fine.   I can only 
reproduce this with NSScrollView.   I have tried this with another application 
and I cannot reproduce this.  The only time it appears is when the application 
is document based app.


CC list is empty


No files currently attached


For detailed info, follow this link:
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=6354&group_id=99

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