How to get number of rows in the multline text input (TextArea)

Hello,

I would like to make autoresizeable multiline text input control for the Chatcube but I hit in many problems.
Me need to get somehow number of rows (or extent) in the input field and change gadget size and reposition it to show without scrolling as in many chat clients on other platforms.

I found there only one multiline input gadget – the Textarea. The WritableField/Button/Icon can handle only 1 line (or i’m wrong?)

1. TextArea does not send any events when text changed. The WritableField send TextChanged event but TextArea not, WHY?? (OK, I can poll for changes using timer – it is ugly but seems will work).

2. It seems not possible to get number of text rows in the TextArea or cursor position as row:col format, it return cursor position only as index to text buffer (as int). WHY?? I read source code of Toolbobx TextArea gadget and its internal structure PrivateTextArea structure have all that me need. Is there any way to get a pointer for that structure outside? I know that is bad to use undocumented internal structure but I not see better solution.

Another (last?) way is to try to get the font and TextArea gadget dimensions and try to reformat the text by hand using rufl to get number of lines but this is too complex for that simple task, add too much overhead as needs to do this on every keypress and anyway this not give 100% correct results as I don’t know the exact line spacing and margins.

Is anyone know better way to get number of lines in the multiline text input?

1. TextArea does not send any events when text changed. The WritableField send TextChanged event but TextArea not, WHY?? (OK, I can poll for changes using timer – it is ugly but seems will work).

If you set bit 8 of the TextArea state, then you’ll get Wimp KeyPressed events delivered to your task on each key press.

Alas, there is no support for bit 8 in the RO5 Toolbox, only in the ROL Toolbox.

One of our next projects is likely to be Toolbox enhancements, with a specific emphasis on TextArea. Availablity/willingness of programmers (ie. time) is the biggest factor preventing this.

As Fred (effectively) points out, it is a nonsense that there are still differences between ROL AND OS5 toolbox modules, and that they’re still stuck in the 1990s effectively.

I think one of the problems is that to really improve the toolbox, you need someone working on it who is actually familiar with using it seriously, and many RISC OS coders have their own ways of doing Wimp stuff which predates Toolbox.

Alas, there is no support for bit 8 in the RO5 Toolbox, only in the ROL Toolbox.

Ah, I was going off the Toolbox StrongHelp file supplied by ROOL as part of their 5.28 disc image for the Pi! That says that bit 8 required v0.34 of TextGadgets and RO5 has v0.44. I was, foolishly, assuming that ROOL supplied documentation for the modules they supplied, rather than someone else’s modules which they didn’t supply!

It’s no wonder people don’t really use the Toolbox given the absolute mess it appears to be in!

@ Andrew

One of our next projects is likely to be Toolbox enhancements

Niceeeeee :D great news (if it happens). Also hopefully the re-unification of the 2 toolboxes would be very very nice plus… (just sayin… lol)

Let us say toolbox and therefore TBX cover 95% of WIMP programming needs. Now there is nothing wrong with solving the remaining 5% directly. I once had a persistent redraw problem and the solution was just:

#define SWI_Wimp_ForceRedraw "0x0400D1"
void Wimp_ForceRedraw(int r0, int r1, int r2, int r3, int r4)
{
  __asm__ ("swi " SWI_Wimp_ForceRedraw);
}

> OK, I can poll for changes using timer – it is ugly but seems will work

You mean calling TBX text_length() regularly in timer? Yes this should do.

Just to add to the confusion, I’m back in front of a Pi now so just tried it, and setting bit 8 of the TextArea state DID result in getting Wimp KeyPressed events every time I typed in the text area! RISC OS 5.29 (24th Nov 2020), TextGadgets v0.44

It’s no wonder people don’t really use the Toolbox given the absolute mess it appears to be in!

I have to say that in some small part I initiated some of the non-use when I pointed out, politely, to a few different developers that they were doing part¹ of their audience a disservice by using features that were only available “over the other side”
e.g. Check the early versions of some software from Squeaky software and then the later versions that worked on both OS forks.

Hopefully with a more unified OS development all the facilities will be available to all the users straight out of the box.

¹ The growing part.

DavidS – the problem is that RISC OS doesn’t have multi-line writeable text icons. That’s Sergey’s problem that he’s trying to solve. Only Toolbox offers that, via the TextArea gadget (designed for browser TextAreas in the 1990s).

We’ve actually been using a bit for the Pinboard 2.0 “stickies”, and it works OK, but is very limited (or rather, fixed in what it can do). It would greatly benefit from some work to allow it to be customised a bit, and also to allow text selections, copy/paste and so on.

I seems found the ugly workaround how to measure the TextArea content.

TextArea have subwindow inside where it draw the text.
I will check all keypress events comes from Wimp to my app. If event comes from TextArea then it will have parent object id pointed to my window where the TextArea gadget is placed. Then I will get window (from event) visible dimensions and compare to gadget dimensions and if it is fits then I found my TextArea window and I can resize the gadget to its window extent + some gap for margins. Because I don’t have many TextAreas this way is should work for me..

Of course much better if TextArea provide read-only access to its internals but it does not..

@Andrew Rawnsley
If you or someone else have a plan to improve Toolbox then would be great to have some generic subwindow gadget, I mean gadget with subwindow only where “redraw” routine can be defined in the code and attached to it somehow. Then gadget can be placed via ResEd and actual look and behavior can be defined in the code. This will solve many problems with custom controls.