Clicking on a disabled ComboBox / FwUp: Window-closing sequence...
Clicking on a disabled ComboBox / FwUp: Window-closing sequence...
- Subject: Clicking on a disabled ComboBox / FwUp: Window-closing sequence...
- From: Andrea Perego <email@hidden>
- Date: Wed, 30 Jan 2002 17:11:44 +0100
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