Selectable text in NSTableView?


 

I’ve got a view-based NSTableView that uses NSTextFields. I’d like to be able to select text in some of the columns, mostly so it can be copied to the pasteboard.

If I set the “selectable” property of the NSTextField, nothing happens.
If I set the “editable” property, I can select text … but the text field immediately becomes editable when the row is clicked to select it (i.e. its background changes to white and a focus ring is drawn around it.)

I’d prefer to have the field become editable on a second click, after selecting the row. But I can’t think of a clean way of doing this without a bunch of gnarly AppKit subclassing and method-overriding. Any suggestions?

—Jens

PS: This is *MAC OS*, not iOS.


Alex Zavatone
 

Wild guess, but what about the “can” methods.

In the headers is there any hidden secret docs hat might help?

On May 3, 2019, at 4:52 PM, Jens Alfke <jens@mooseyard.com> wrote:

I’ve got a view-based NSTableView that uses NSTextFields. I’d like to be able to select text in some of the columns, mostly so it can be copied to the pasteboard.

If I set the “selectable” property of the NSTextField, nothing happens.
If I set the “editable” property, I can select text … but the text field immediately becomes editable when the row is clicked to select it (i.e. its background changes to white and a focus ring is drawn around it.)

I’d prefer to have the field become editable on a second click, after selecting the row. But I can’t think of a clean way of doing this without a bunch of gnarly AppKit subclassing and method-overriding. Any suggestions?

—Jens

PS: This is *MAC OS*, not iOS.


Quincey Morris
 

On May 3, 2019, at 14:52 , Jens Alfke <jens@...> wrote:

If I set the “selectable” property of the NSTextField, nothing happens.

In a similar recent scenario, I found it takes two clicks when the text field is selectable but not editable. (Well, one click and one drag, if you’re actually trying to select text.)

What makes this seem unresponsive is that there’s no I-beam cursor in selectable-but-not-editable mode. It’s there but invisible after a second click (you can even move its — invisibly — with the arrow keys), but your brain resists believing it.

The reality is, it’s probably better to go ahead and subclass NSTableView and force it to pass the first click (or first drag, more likely) to the text field. I haven’t tried to do it yet, but I think there’s no built in behavior that isn’t going to make you angry on an ongoing basis.


John Brownie
 

Well, some further testing revealed that this was a way to make it work. It had the side benefit of making the window update more efficiently! Still, it would be nice to know why it was crashing in the first place...

John
--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland


 



On May 6, 2019, at 7:15 AM, John Brownie <john_brownie@...> wrote:

Well, some further testing revealed that this was a way to make it work. It had the side benefit of making the window update more efficiently! Still, it would be nice to know why it was crashing in the first place...

I think that reply was meant for a different thread?

—Jens


 



On May 3, 2019, at 5:33 PM, Quincey Morris <quinceymorris@...> wrote:

In a similar recent scenario, I found it takes two clicks when the text field is selectable but not editable. (Well, one click and one drag, if you’re actually trying to select text.)

That’s the behavior I was getting the last time I worked on this app, a few months ago, but it’s somehow stopped working and I can’t get it to work again. Specifically, what used to work was
1. Click on row to select it
2. Mouse-down in text, drag horizontally
This no longer works, and I can’t get the text to select at all unless I change the NSTextField’s mode to Editable, which causes the problems I described earlier.

I haven’t done much with the table-related code since I had this working. I’m kind of suspecting some undocumented AppKit change in 10.14.4, but there are so many variables that can affect behavior that I’m not ready to file a bug report yet.

—Jens


John Brownie
 

Oops, yes. This was on the crash in dragImageForSelection.

Jens Alfke wrote on 6/5/19 20:02:



On May 6, 2019, at 7:15 AM, John Brownie <john_brownie@...> wrote:

Well, some further testing revealed that this was a way to make it work. It had the side benefit of making the window update more efficiently! Still, it would be nice to know why it was crashing in the first place...

I think that reply was meant for a different thread?

—Jens

--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland