In Xojo, you can have localised strings constants, used for targeting several languages (so a given app is displayed in english when launched on an english system, but shows in german if running on a german OS (if you define those localisations)).
If you don’t use them (and you would know that, as you explicitly chose to), then my suggestion has to be trashed. If you use them, however, it’s common to be confused and ending up with strings being blank because no language matches the current OS setup.
Thank you Arnaud for your explanation, and others for suggestions. Now your point is clear to me and the answer is no, I did’nt use localised strings. However, this suggests to me to check well the nature of the strings that are to be displayed. Unfortunately, I cannot do as many tests as I want, when and how I want, because the offending computers do not belong to me. This is the answer to those like Valdemar and Jeff who ask me to post a screenshot of the problem, because it is not easy for me to ask remotely people to photograph particular moments of program execution. However, the next step will be to have people who encounter this problem try, when possible, a simple program as suggested by Jeff.
You can always take screenshots programmatically (your app takes a screenshot of itself when it feels it should (or when the user clicks a button)).
Ok, good to know it’s not the issue.
You can always add debugging capabilities to a specific release of your app. You’d send the special version to the user having the trouble and your app would log extra data, e.g. to a file (and it could even send the file back to you; but that’s beyond the point).
In your case, one thing you could do (it’s an example):
When the blank caption appears, the user would click on a “debug” button you’d have put for him/her, which would dump the string to a temporary file, along with storing each character’s code. The file could look like:
This is my caption.
84,104,105,115,32,105,115,32,109,121,32,99,97,112,116,105,111,110,46
(the numbers being the characters code)
Possibly also take a screenshot that you save to another file. Then reveal the files and ask the user to send them to you.
Hi all. I was finally able to get feedback from users of the program. I think things are now clear.
I made a program that displays a window with a desktop label, a label, a textfield, a text area, a Desktop Button, a PushButton.
On Mac, when set in DarkMode, if the background of the window is white, even though you can see the outline of all the controls, you only read the text of the DesktopButtons (in white with blue background by default) and the text of the TextArea (in white on black).
But if you set the HasBackgroundColor property of the window to False, then you read ALL the text (all in white, on black or gray background, except for DesktopButton, still in white with default blue background).
This problem also occurs in Windows 10 and 11 in the dark mode. In this case with the window having a white backgrund everything reads white on black except for the Label and DesktopLabel which do not read. When the window background is off, you see everything in black and all the lettering in white.
So the problem depends on the combination of dark mode of the system and the window background. I don’t know if this is a bug but maybe this should be addressed.
When you enable Dark Mode, the system assumes it can paint text on a dark background and will use white or something very close to it as text color.
Choosing a white background for your window in dark mode is against this logic.
Either you disable dark mode support in your project or you should define all relevant colors for a window that has a different background. In a DM enabled app, users usually will not like a white background because the contrast against system colored windows is too high. You might consider using ColorGroups instead of simple colors to find a color scheme that will suit DM too.
Xojo is trying to handle automatic dark mode for you. There might be documentation somewhere about what switches automatically, when, and why; but I don’t know where that is.
If you’re not ready to support dark mode yet, you can disable the color switching using the “Supports Dark Mode” switch in build settings.
This is really a useful suggestion, thank you. In fact, disabling “Supports Dark Mode” in the build settings the problem no longer occurs. However, it had seemed to me that dark mode support meant that in dark mode everything worked without intervention from the program, and instead it is the other way around. I was assuming that black text inside a white control would remain black and not turn white to match the general background. Anyway now the problem should be solved, thank you all.
