Text in text fields

When text in a text field is initially populated from the program (allowing a user override by a mouse down), the text appears difficult to read, not sharp and prominent like when the user actually types something in the field.

It appears when a text field is enabled, the text is sharp and clear, but when it is disabled, the text is muted.

Is there a place in Xojo to override this and make the text appear the same in a text field whether enabled or not? Leaving the field always enabled is not desirable in my program.

Start with some basics:

  • Your operating system and version
  • Xojo version
  • Is it reproducible in a simple project? If so, share that project.

I have never seen text being “not sharp” before.

Edit: It seems like maybe you don’t quite know the correct words. Sharpness is how fuzzy something is or is not. This can be caused by using the wrong resolution graphics object. It seems more like simply mean the “disabled” look, which is not considered “not-sharp”.

Yes, a disabled control has lighter coloring to distinguish the fact that it is disabled.

It sounds like you have put the initial text in the ‘hint’ box, rather than the ‘Text’ field. The grey ‘hint’ is not a default value for the field it is a comment on how to complete the box. As such it is grey when shown. As soon as you click in it disappears and the user gets to enter their own text. The value of ‘hint’ is not returned to the program if the user doesn’t enter anything.

Is that perhaps what you are seeing?

Screenshot 2023-11-24 at 16.03.47

Yes, Tim, I mean ‘disabled’. Thanks for the clarification.

I have an iMac I-7 running Mac OS Monterey 12.7.1.

So I guess to rephrase, is it possible to override the “disabled control” lighter text or is that fixed in the Xojo OS? (Come to think of it, this is a much more sensible question once you get the right semantics!)

Not with the Enabled property. However you can replicate the behavior of not allowing changes if that’s what you want to do. You can return true in the KeyDown event to prevent changes.

Maybe you are looking for the ReadOnly property?

2 Likes

Enabled is aimed at a control that isn’t currently relevant, ie a control that is greyed out because you aren’t going to use the data it contains.

Read only is good for controls that are going to make a difference but the contents could come from other places, for example a summary of the settings you’ve chosen with other controls. Obviously, If you set read only people can’t click in the field and enter any data.

Today was my turn to forget a basic framework feature
 thanks! :smiley:

Not everything is black or white, there are many many more use cases.

But they can see the text NOT greyed out AND they can click in the field, select and copy the text.

According to Apple UI


1 Like

Spent several days swapping out the [Enabled] command with the [ReadOnly] command. As mentioned in the answers above, this change results in clear text in the fields on the screen. I also learned that I can have a [MouseDown] event in a Read Only field, then remove the restriction if the field is OK for user editing at that point.

Thanks to those who answered - my program is much more user-friendly as a result of this and the other answers I have gotten in this forum.

You should also think about what happens in the user presses tab and enters the field. It would be odd if clicking made it editable and tab didn’t?

Ian, in my program, the user progresses through a number of text boxes entering information. I allow them to (1) restart the process by a MouseDown in the Date field (the first item to be entered). During data entry, TAB advances the user to the next field; and (2) I allow the user to use MouseDown to change a field they want to change.

Input by the user is evaluated each time a TAB is pressed; it must pass the ‘smell’ test (Date must be validated for example; Amount must be within some bounds; and other tests). If the input is validated the TAB moves the user to the next entry point.

Some fields can be auto-filled based on user input. If the user knows a vendor number, for example, it is not necessary to enter the vendor name. That field can be populated automatically. But the user retains the ability to MouseDown on a field that they want to change without deleting the rest of their input (in my example, if the user overrides the computer generated Name field, the Vendor Number field would be automatically blanked out - or repopulated after a look-up in the Vendor file).

I am not a professional coder so there may be times when I violate what pros consider good practice; but I have 50 years in Accounting and Finance and know how to expedite data entry and improve accuracy.

At the end of the day, I write for my own use and not for sale, so any quirks in my approach are for my own - perhaps “selfish” desires. Thanks for your comments as I like to be challenged on why I do things the way I do, and I like to consider the viewpoint of those who do this stuff for a living. For me it’s merely a hobby, and I learn more every day!

No problem. Just that some users almost never use a mouse and others almost always use one, and not the keyboard. It just sounded odd if the user could click on the field and edit bit not tab / shift-tab into it and do the same thing.