TextArea, whats up with Enabled or not ?

General
1

I can not get the TextArea.Enabled = FALSE to work, is still shows up as TRUE.

Whats the story here? 2014r3.2 is no good, confirm anyone ?

2

don’t have any problem over here…

3

Target?
Platform?
Works fine for me. OS 10.10
Desktop target

4

10.10.2, desktop mac.

5

Are you saying that if you set a TextArea.Enabled = False, that you can still enter data into the TA?

6

no i can not enter, thats ok, but it does not go grey, as textfield does, it just does not looks like it is deactivated, it stays in solid black, and other stuff goes grey.

7

OIC. File a feedback report.

8

First check if thats platform correct behavior as I suspect it might be

9

You could use a myenabled computed property which turns the text color gray when False, and reinstate the normal text colors when true. But it can be slow with RTFData or StyleRuns to save and reload. Or use a doppleganger of the TextArea at the same place, with the same size, with the same content gray you set visible and set the normal TextArea invisible. The other way around when enabled.

10

The underlying NSTextView does not visually indicate that it is disabled. So this is the standard on OS X. It’s probably due to the fact that NSTextView is not a subclass of NSControl, which implements the Enabled property.

11

Ok, a workaraound is to use enabled for the groupbox and additional set the color for textarea.textcolor to grey. This way it will looks like it is disabled.

Thanks

12

And will look out of place.

13

By using that workaround, you will change the appearance from native to non-native looking!
Why on earth would you want to do that?

14

But if I don’t it looks strange that all of my textfields and popupmenus goes grey, while my textarea don’t… It looks like some stuff is dimmed and some not… And, does that really look nice to a user ?

15

a short test with a textarea and a button

button.action

  if TextArea1.Enabled = True then
     TextArea1.Enabled = False
    TextArea1.BackColor = &ce9e9e900
  else
     TextArea1.Enabled = True
    TextArea1.BackColor = &cFFFFFF00
  end if
16

[quote=165589:@Axel Schneider]a short test with a textarea and a button

button.action

if TextArea1.Enabled = True then TextArea1.Enabled = False TextArea1.BackColor = &ce9e9e900 else TextArea1.Enabled = True TextArea1.BackColor = &cFFFFFF00 end if [/quote]

This is nice. I would also return true in MouseWheel to inactivate the scroll.

17

That’s Apple’s problem, not yours. If you do your own styling, when they do get around to fixing it your app will look even more out of place.

18

Odd but that IS standard now

19

Well, do we have to give in for the standard ?

If I don’t like what has become a standard, I don’t have to use the standard :slight_smile:

OR do I actually have to use it, because of MAS ?

20

[quote=165653:@Helge Tjelta]Well, do we have to give in for the standard ?

If I don’t like what has become a standard, I don’t have to use the standard :slight_smile:

OR do I actually have to use it, because of MAS ?[/quote]

You would be surprised by the opinionated reactions of the MAS reviewers. I am not religiously attached to Apple’s Human Interface Guidelines, and believe a measure of innovation should be present in Mac OS X programs. But you must be very careful to make sure your application remains usable without manual.

Pretty much like cars are usable without manual because their interface is standardized, Mac software relies on an ecosystem of standardized controls users expect to behave a certain way.

Actually, after this thread I have been giving a good thought at this notion of disabled TextArea. It makes perfect sense to have a read-only TextArea when the user is expected to read a long text but not modify it. For instance the long legalese terms of service of a software. But in many years of computing, I can’t recall text editors where all the sudden it is not possible to edit the text. Axel’s suggestion seems fine to me, but still, I feel it has the potential for the user to think your program is stuck. Before you know it, he will force quit the app and request a refund.

That is your app and you are free to do as you please, but for my own programs, I would rather remove the TextArea entirely rather than to leave it there frozen. Or show the user a new window so he can interact with the program in a more sensible way, without the annoyance of a dead control.