Hello Patrick,
On Feb 25, 2009, at 12:38 AM, Patrick Mau wrote:
I was going through your last messages on this list, because I'm
working on a similar problem.
Reading through the code snippets you showed here, it isn't clear to
me how your controls are being created.
I have a XIB with a NSTextField...here is an over all picture of what
that XIB contains:
http://ericgorr.net/cocoadev/outlinetable/namedparts.png
This is simple one item among many (perhaps a few thousand) as
pictured here:
http://ericgorr.net/cocoadev/outlinetable/outlineview.png
If you need more details, let me know.
This table I am using is of my own creation as none of Apple's table
views or the image browser worked the way I needed them to...so, I
have to write my own custom solution mostly from scratch.
Are you creating a subclass of NSControl and afterwards add your GUI
elements as sub-views programatically?
I could not figure out if you use one NSControl with NSCell's, sorry
if I missed it.
No, I am just using NSControl's. I am not using any NSCell's explicitly.
Unfortunately, it does not work either.
If anyone has any further ideas on how to correctly end an editing
session of a NSTextField, I am interested.
To summarize the proposed and failed solutions:
*** [[[self view] window] endEditingFor:nil];
Pressing return or pressing the tab key will not end the editing
session
As far as I understand, TAB will focus the next control using the
responder chain.
It is not really remove the editor, because you could TAB back to
your control/cell
and still have the same state for editing.
I am more concerned that I don't have a way to guarantee the edit
session will stop. This seems very odd and very broken to me.
However, in my case, I believe it is appropriate for the edit session
to stop when the tab key is pressed. I have attempted to setup my
custom table view as a responder and this is what I switch to when the
user presses the return key. hummm...perhaps what is happening is that
I switch to my custom table view, but the processing of the tab key
hasn't completed yet so it moves onto to the next responder which is
still that very annoying NSTextView that just won't go away.
*** [[[self view] window] makeFirstResponder:[self view]];
Pressing return will allow the editing session to end, but pressing
the tab key will not.
I would suggest you write a small debug function to output the
responder chain.
Call it after all your elements are setup and again after you
started editing.
Good idea.
*** NSTextView *fieldEditor = [[aNotification userInfo]
objectForKey:@"NSFieldEditor"];
NSView *v = fieldEditor;
while ( v && ( [v superview] != [aNotification object] ) )
v = [v superview];
[v removeFromSuperview];
Pressing return or pressing the tab key will not end the editing
session
It works for me using one NSView only drawing NSCell objects.
But it was only a hack I tried to remove the field editor.
What happens when you NSLog all views you traverse on your way up?
Could you send the output?
NSTextView *fieldEditor = [[aNotification userInfo]
objectForKey:@"NSFieldEditor"];
NSView *v = fieldEditor;
while ( v && ( [v superview] != [aNotification object] ) ) {
NSLog( @"ResourceItemController: v: %@", v );
v = [v superview];
}
NSLog( @"ResourceItemController: v: %@", v );
[v removeFromSuperview];
outputs:
2009-02-25 09:36:12.860 OutlineCollection-VB[56709:813]
ResourceItemController: v: <NSTextView: 0x3afd20>
Frame = {{0.00, 0.00}, {76.00, 13.00}}, Bounds = {{0.00, 0.00},
{76.00, 13.00}}
Horizontally resizable: NO, Vertically resizable: YES
MinSize = {76.00, 12.00}, MaxSize = {40000.00, 40000.00}
2009-02-25 09:36:34.532 OutlineCollection-VB[56709:813]
ResourceItemController: v: <_NSKeyboardFocusClipView: 0x3f3040>
What I am just about ready to do is stop using the NSTextField control
and do the drawing myself using drawWithRect:options:attributes:. I
believe I can get the metric I want, which doesn't seem possible with
a NSTextField, with boundingRectWithSize:options:attributes: ... of
course, this may not work as I believe I would loose the ability to
accurately determine on which character the user clicked so I could
begin an edit session with the cursor positioned correctly. However,
since I would be explicitly brining the NSTextView into existence for
editing, I should be able to get rid of it completely.
sigh.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
