[davecom]

Why the heck won't my textfield become editable I don't know what to do i have looked through all of the frameworks related to text for hours. I set my textfield as enabled and editable - why won't it let me edit it! What's going on?
This is a PLEA if anybody knows anything,anything at all about why a textfield may not want to even show a cross hair above it in this manner please tell me! I need to know.
I'm almost literally pulling my hair out!
Thank you so so much for any help from anybody.
David Kopec

------------------
Think Different.

[lindberg]

Usually I would say to make sure the outlet in the nib is set, and that the nib has been loaded when you're calling your code. If those aren't true, then the textfield variable is nil, and nothing will happen when you send messages to it. Break in that area in gdb to print out the variable, or just NSLog it to make sure.

However, if the correct cursor isn't showing up, and you can't select any text in there either...

Is it possible that a transparent view has been layered over top of the textfield in the nib? That might explain it if the textfield does not respond to any mouse clicks at all.

Just to make sure, this is a regular NSTextField right, not a subclass where you might have overridden something important?

If all else fails, you can try deleting the textfield and putting in another one (connecting the outlet again, etc.). Can't see how it would help but you never know.

[davecom]

This textfield was not created in interface builder, it is programatically allocated. The text can be selected, but it gets selected using the regular pointer(arrow). I've done the setEditable and setEnabled methods properly to YES. It is not a subclass of NSTextField.

Thank you for repsonding,
David

[ali]

Is there anything special about the window the text field is in? Is it also programmatically created, or is it extracted from a nib? If latter, and you have a regular IB created text field in the same window, does it fail the same way?

Ali

[davecom]

Yes, there is some special stuff about the window. It is of type NSBorderlessWindowMask. It is created programatically. It has no border and is built from a custom class, it also has special stuff in the mousedown and dragging methods to allow it to be dragged from any part of it. The two textfields, one in a drawer, and one in the actual window both have the same above described problem. For more information about what the windows are like download the old version of URL Box(1.1) from macupdate,stepwise,versiontracker, or download.com.

Thank you for your continued support,
David

[hELLO wORLD]

Davecom, I have the solution

Your window is a subclass of NSWindow, and you have initialized the window with NSBorderlessWindowMask. In this case, your window cannot be the keyWindow, nor the mainWindow. It means that it does not respond to key Events. All buttons and sliders are grey, not blue, like a non selected window (because it cannot be the main window)
In your NSWindow subclass implementation, just add :
- (BOOL)canBecomeKeyWindow
{
return YES;
}

- (BOOL)canBecomeMainWindow
{
return YES;
}

(please, verify spelling of these functions in NSWindow documentation)
And it is magic ! You will be able to select, edit, ... :-)
You can find more info on these two overrides in NSWindow help documentation.

[hELLO wORLD]

double post...

[This message has been edited by hELLO wORLD (edited 05-13-2001).]

[ali]

Borderless windows are not in general designed for use with UI elements... I believe hELLO wORLD has hit it right on the head and his suggestion should help. Let us know!

Ali

[hELLO wORLD]

ali,

I know this works... I had the same problem...
I have spent time to read documentation about NSEvent, NSResponder, NSApplication, NSWindow, and to test different kind of stuff.
I had noticed that my window responded to key Events when it was normal, but not when it was NSBorderlessWindowMask... So I have found that keyWindow and mainWindow stuff, tried it and worked fine.
When a Window is initialized with NSBorderlessWindowMask, canBecomeKeyWindow and canBecomeMainWindow are automatically set to NO.

Cocoa is not finished yet, nor documentation. But is is very good yet, and very useable. The AppKit framework is very promising and is open to really great improvements! This is the easiest way to program major apps that needs to use intensively System Libraries or Frameworks.

[davecom]

A member of the MacNN community has saved the day once again. It works perfectly now. You've saved me countless hours. Email me at davecom@mac.com with your real name if you would like to be in the readme file of URL Box.

------------------
Think Different.