Text offset in new desktopTextArea

Targets macOS
1

New Xojo2025r3: I love new features, but what i love even more is when previous stuff works as it did before so i don’t have to spend time fixing stuff that wasn’t broken. Concerns the textarea control, where wrap is off (BTW this check box state does not stick in the IDE setting) and there is a horizontal scroll bar. Used to look like this:

image
image652×432 8.91 KB

with a comfortable margin at the left of the text. as of 25r3 it looks like this:

image
image684×480 10.1 KB

with the text uncomfortably glued to the left edge of the textarea with barely 1 pixel of whitespace. As if the horiz scroll can never quite get to 0. Am I doing something wrong? (I didn’t do anything).

Here is a project:

test.xojo_binary_project.zip (5.7 KB)

2

It’s likely a change due to the underlying SDK that was upgraded. Put a bug report in.

https://tracker.xojo.com/xojoinc/xojo/-/issues

3

I don’t see the difference using 2025r2.1 and 2025r3 here (macOS 15.7.2):

image
image355×410 28.2 KB

maybe Tahoe related?

4

sonoma 14.7.2

5

I do not have an answer for why they differ, but do have a workaround for making the padding as you desire. I use Einhugur plugins and this function to control (increase) the padding on my TextAreas:

Public Sub TextContainerInset(extends txt as TextArea, assigns ptInset as Point)
  #if TargetMacOS then
    var szInset as new EinhugurCoreBridge.NSSize(ptInset.X, ptInset.Y)
    EinhugurMacOSBridge.NSTextView.FromPtr(ptr(txt.Handle)).TextContainerInset = szInset
    
  #endif

End Sub

Used like:

// Pretty margins
txtCredits.TextContainerInset = new Point(2, 3)
6

Strange. Used your sample project and I have no difference between 2025r2.1 and 2025r3.

7

Thx Tim, back to 25r2.1 for me.

8

https://tracker.xojo.com/xojoinc/xojo/-/issues/80524

9

This is the MBS equivalent to what Tim suggested if you have those plugins.

me.NSTextViewMBS.textContainerInset = new NSSizeMBS(5,8)
10

thx Jared, i have MBS and will give it a try

11

Was looking fwd to trying watchpoints in 26r1 (something we’ve been waiting for for quite a while) but unfortunately the ugly margin-less textareas were not fixed:

image
image1026×350 56 KB

Curiously, when the window first opens with default text it looks OK:

image
image734×360 7.65 KB

and if i clear the field and type some text manually it also looks OK:

image
image302×186 2.16 KB

the top example only happens when the field is filled with new text programmatically. I added these additional observation to the case: https://tracker.xojo.com/xojoinc/xojo/-/issues/80524.

So possibly the previous tests where folks could not reproduce this were either default or user-entered text, not programmatically set text.

I know (and appreciate) the suggestions for workarounds, but I’d much prefer if this worked out of the box like it used to.

12

just downloaded 2026r2 hoping this would be fixed, but alas no, it looks like one of those bugs that will be relegated to the back burner, possibly forever. This is on Sequoia 15.7.3 (so occurs on several macOS versions for me).

The NSSizeMBS tip seems to work (thx Jared) so looks like i’ll have to remember to add this to every desktopTextArea from now on.