Toolbox: Unusual TextArea behavior?

Not necessarily confident enough to call it a bug per se, but…

I’ve noticed in both C and Python that when I try to set the text of a TextArea through the Toolbox_ObjectMiscOp SWI with text containing a newline, it eats a large chunk of the text following the newline. However, when I use the C veneer textarea_set_text, it works perfectly fine. To illustrate, a line from the test program I made to try to figure this one out:

/* This one works perfectly! */
    textarea_set_text(0,id_block->self_id,2,"Hello\nworld");
    /* But this one swallows everything after the newline! */
    _kernel_oserror *err;
    err = _swix(0x44EC6,_INR(0,4),0,id_block->self_id,0x401A,2,"hello\nworldthequickbrownfoxjumpsovverthelazydog"); 
The second one results in:

hello
quickbrownfoxjumpsoverthelazydog

I haven’t pored over all the code (I don’t think I’m qualified anyway) but the veneer really does seem to be just that, so I’m baffled why one would work and the other wouldn’t. The stakes are, this of course makes it impossible to properly set multiline text in a TextArea from Python. Anyone have a clue?

Is the text actually not there, or is it just not showing up?

Interesting – looks like TextArea has been a gadget since about 1997; no mention of it in the Toolbox manual. Hmm. 🤔

First, I should amend that and say the first example is no longer working now that I’ve gone back to check, so I guess that was a fluke… but that makes more sense, since they shouldn’t behave differently.

But good eye, Rick. If I pull the text back out to a different buffer after it’s set, it all comes back out, so it’s looking like it’s a display issue.

And yeah, only docs on this one are the header, the source, and a little doc buried somewhere on gitlab. But it was in the box when I got Toolbox, unlike Tabs, say.

Yes, I’ve seen the same using both assembly and AppBasic. Editing the text causes the missing bits to appear which confirms that the text has been transferred correctly.

so it’s looking like it’s a display issue.

Agreed, more specifically it looks like an initialisation problem. I’ve found that you can avoid the problem by setting an empty text (first byte is 0) before actually using the TextArea. Changing its font before use also seems to fix the redraw issue.

It’s not the only problem with TextArea though. It doesn’t adjust the width used for wordwrap when you resize the area (using Gadget_MoveGadget) or when you change its font.

I’ve found that you can avoid the problem by setting an empty text (first byte is 0) before actually using the TextArea.

Sure enough, that did it. In that case, I’m not expecting anyone to rush out and fix it, but is this tracked anywhere?