Re: Clicking on a disabled ComboBox / FwUp: Window-closing sequence...
Re: Clicking on a disabled ComboBox / FwUp: Window-closing sequence...
- Subject: Re: Clicking on a disabled ComboBox / FwUp: Window-closing sequence...
- From: Chuck Pisula <email@hidden>
- Date: Thu, 28 Feb 2002 13:57:07 -0800
This is a known bug in 10.1.X. The workarounds are easy.... there are 2
choices:
1. Make sure there is atleast one control in the window that can accept
first responder (it can even be outside of the windows visible bounds).
This is a bit hackish....
2. Subclass NSComboBox do the following:
- (BOOL)acceptsFirstResponder {
if (![self isEnabled]) return NO;
else return [super acceptsFirstResponder];
}
Or you could do it in a category if you want to take care of all the
cases NSComboBox already properly handles.
-chuck
On Wednesday, January 30, 2002, at 08:11 AM, Andrea Perego wrote:
Hi!
Sherlock Holmes used to say that "when you have eliminated the
impossible whatever remains, *however improbable*, must be the truth".
I'd like to move in the opposite direction, trying to rule out any well
known developer pitfall or Cocoa bug, before starting a deeper search.
Thus, I'm asking once again the more expert fellows about another
"weird" behavior I'm experiencing.
My application uses a panel/palette window with some controls that
operate on a kind of document. Those controls are located within a
tabview and are disabled by code when no main window exists (or if the
main window does not display data of the appropriate kind). So far, so
good. One of the panes of my tabview contains some "NSComboBox"
instances, which work Ok, but for the fact that, if *all* the controls
of the pane are disabled (-setEnabled:NO) and one clicks on any of the
combo boxes, the application crashes in a "funny" way.
A "bad access" message appears and, if one is using gdb, the stack
frame area remains empty for, say, ten seconds or more; then, it fills
up with a very large list, more than 500 items, where no one seems to
refer to an application-specific method. I'm not so precise here, since
I'm just asking whether my story is a well-known one.
Besides the combo boxes, the pane contains also some buttons, text
fields and popup menus. Clicking on any of them causes no crash. Also,
if one does not disable one of the combo boxes, the crash is avoided.
I've found a solution/workaround by issuing "-setSelectable:NO" to each
combo box; I'd guess that the behavior is related to the unique field
editor provided by each window, but any suggestion is welcome.
----------------------------
And now, something completely different.
Some days ago, I posted to the list about the fact that a
windowcontroller subclass receives a -setDocument:null message as a
part of the window closing procedure. This message is sent "early"
enough, so that one has to be careful in referencing
[myWindowController document] during the closing process. Carlos
Weber(thanks again!) pointed me to the solution: the window controller
receives
in sequence:
-windowShouldClose....
-setDocument:null
-windowWillClose...
.....
-dealloc
If you wish to do something that requires [myWindowController document]
within the closing procedure, you may implement -windowShouldClose and
do it there.
TIA
Andrea Perego
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.