bugGNUstep - Bugs: bug #16688, "NSInvalidArgumentException:...

Group
 
 

bug #16688: "NSInvalidArgumentException: stopModalWithCode: when not in modal session" when hitting return in textfield.

Submitter:  Gregory John Casamento <gcasa>
Submitted:  Mon 29 May 2006 04:41:04 AM UTC
   
 
Category:  Gui/AppKit Severity:  4 - Important
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 31 May 2006 01:16:29 PM UTC, comment #10: 

Well I tried some tests on MacOS-X, and it looks like the behavior there is significantly different to NeXTstep ... with performKeyEquivalent: being sent to the main menu and its submenus (whether hidden or not) and to the key window, but not to other windows/panels.
I guess we must go with the MacOS-X behavior.
I've updated the library to be MacOS-X compatible.

Richard Frith-Macdonald <CaS>
Group Member
Tue 30 May 2006 03:24:23 PM UTC, comment #9: 

"As long as those buttons are connected to an outlet, it should be easy to disable them."

Sure ... I didn't express myself at all well ...
What I meant was that there is no way to deal with the issue in Gorm without coding  ... you would have to make the button available as an outlet and then write code to actually enable/disable the button when the pannel is hidden/off-screen.

When I do stuff graphically using Gorm, I want to write as little code as possible, so it seems as though there ought to be some standard behavior built into the library to just do the right thing.  Maybe there is in Cocoa, but if so I haven't been able to find it in the documentation.

For instance, the NSButton implementation of performKeyEquivalent: could have logic in it like 'if the window I'm in is hidden and is not a menu then return NO'
I guess I need to write a test application on MacOS-X and see what it does.

Richard Frith-Macdonald <CaS>
Group Member
Tue 30 May 2006 03:32:59 AM UTC, comment #8: 

"Other panels may have similar problems and may not be created programatically (eg they are Gorm files) and cannot therefore easily have their buttons disabled when they are closed."

As long as those buttons are connected to an outlet, it should be easy to disable them.

GJC

Gregory John Casamento <gcasa>
Group administrator
Mon 29 May 2006 01:37:35 PM UTC, comment #7: 

Tested the fix in Gorm and it works properly.

Thanks, GJC

Gregory John Casamento <gcasa>
Group administrator
Mon 29 May 2006 09:06:47 AM UTC, comment #6: 

Have implemented the easy fix of disabling the ok buttons when not in use  ... still not convinced it's correct though.
Should the message only be sent to all windows if the command key is down (I think that's how NeXTstep did it), and just sent to the key window otherwise?  That would mean you can't properly use things like CR or DEL as shortcuts on menus, but how often would anyone want to do that anyway?

Richard Frith-Macdonald <CaS>
Group Member
Mon 29 May 2006 08:00:43 AM UTC, comment #5: 

We can easily fix the save and open panel code by disabling the 'ok' button when the panel is not in use.  However, it seems to me that there ought to be some automatic/better way of doing things.  Other panels may have similar problems and may not be created programatically (eg they are Gorm files) and cannot therefore easily have their buttons disabled when they are closed.
Perhaps there is some behavior that should be implemented that we are missing ... maybe all controls on a closed window should return NO for isEnabled or something like that.

Richard Frith-Macdonald <CaS>
Group Member
Mon 29 May 2006 06:23:20 AM UTC, comment #4: 

I believe that the 'fix' of disabling -performKeyEquivalent: is incorrect, since the method is supposed to be sent to all windows.  Certainly in NexTstep it used to be sent to off-screen panels, not just visible ones.  The reason for this is that key equivalents for menu items should operate whether the item is visible or not, and the 'fix' means that menu item key equivalents no longer work for menus on hidden windows.
Arguably the change breaks more than it cures.

The old NeXTstep documentation suggests that hidden panels should deal with receiving perfrormKeyEquivalent: messages (see the last para of the documentation on the old commandKey: method at http://www.channelu.com/NeXT/NeXTStep/3.3/nd/GeneralRef/02_ApplicationKit/Classes/Panel.htmld/index.html) and the latest Apple documentation still says that the message should be sent to every window:
http://developer.apple.com/documentation/Cocoa/Conceptual/BasicEventHandling/Concepts/KeyEquiv.html

This suggests that the bug is in the save panel .. though it's not clear to me where the correct fix would be.

Richard Frith-Macdonald <CaS>
Group Member
Mon 29 May 2006 06:15:47 AM UTC, comment #3: 

Yes, it is fixed.

Yen-Ju

-Deleted Account- <yjchen>
Mon 29 May 2006 05:08:57 AM UTC, comment #2: 

Yen-Ju,

Please updated and try it now.  I have committed the change I believe should fix it.

Thanks, GJC

Gregory John Casamento <gcasa>
Group administrator
Mon 29 May 2006 04:52:29 AM UTC, comment #1: 

I got the same error when using Vindaloo, a PDF viewer.

1. Open a PDF file.
2. Menu "Find" -> "Find text". A textfield will show up.
3. Type anything in textfield and hit "ENTER".
4. The exception happens.

PS. I didn't test earlier version of GNUstep.

-Deleted Account- <yjchen>
Mon 29 May 2006 04:41:04 AM UTC, original submission:  

After the following change was made I am getting an error panel saying:

NSInvalidArgumentException: stopModalWithCode: when not in modal session.

The procedure to recreate this is:

1) open Gorm.app
2) Select Gorm->Open and open an existing Gorm file *OR* simply close the open panel without opening anything and create a new document.
3) Select the classes view
4) Click on any class
5) Select Gorm->Classes->Create Subclass
6) Go to the attributes inspector and change the name of the new class
RESULT: You will get the panel above
EXPECTED: No exception should occur.

The latest release version 0.10.3 (r22664) does not exhibit this issue using the same procedure as above in Gorm.

Here is the change in r22834...



2006-04-28  Richard Frith-Macdonald <rfm@gnu.org>

  • Source/NSApplication.m: ([-sendEvent:]) try key equivalents for

every key down, not just command modifiers ... consistent with
MacOS-X and allows carriage return as a button/menu key.

  • Source/NSWindow.m: ([-performKeyEquivalent:]) only pass on to

our views if this is the key window (NSMenu overrides this).



I believe that the issue is that it is trying to execute the key equivalent on the "ok" button on the save panel when it is not currently being displayed.  The save/open panel is a singleton and is thus always around even when not used.

Thanks, GJC

Gregory John Casamento <gcasa>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only logged-in users can vote.

 

Follow 2 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2006-06-04 CaS StatusNone Fixed
    Open/ClosedOpen Closed

Back to the top

Powered by Savane 3.13-d3ae.
Corresponding source code