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.
|
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.
|
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
|
Mon 29 May 2006 01:37:35 PM UTC, comment #7:
Tested the fix in Gorm and it works properly.
Thanks, GJC
|
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?
|
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.
|
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.
|
Mon 29 May 2006 06:15:47 AM UTC, comment #3:
Yes, it is fixed.
Yen-Ju
|
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
|
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.
|
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
|