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

 
 

You are not allowed to post comments on this tracker with your current authentication level.

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

Submitted by:  Gregory John Casamento <gcasa>
Submitted on:  Mon 29 May 2006 04:41:04 AM UTC  
 
Category: Gui/AppKitSeverity: 4 - Important
Item Group: BugStatus: Fixed
Privacy: PublicAssigned to: None
Open/Closed: Closed

(Jump to the original submission 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>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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>
Project Administrator

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 2 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Sun 04 Jun 2006 08:55:23 AM UTCCaSStatusNone=>Fixed
  Open/ClosedOpen=>Closed

Back to the top


Powered by Savane 3.1-cleanup1