I have troubles with a Styled TextArea and tabs

Talking about Tab (read my previous post), here’s another, but in TextArea.

As far as I can see, there is a phantom tab rule in TextArea who have different values depending on the platform.
(I do not care about the real differences of TextArea depending on the platforms; I am talking about the way the user will see it).

Cocoa and Carbon can display up to 12 \tabs in a 670 pixels width TextArea.
Starting with the 13th \tab things differs: on Carbon, the cursor is at the end of the line while in Cocoa, the cursor is nearly at the middle of the TextArea width.
In Carbon, a 13th \tab will move the Cursor for some pixels to the right (2, 3 ?)
In Cocoa, remember, the cursor is in the middle of the line (around 330 pixels on the 670 pixels the TextArea width is), a 13th \tab wrap the line and display the cursor at \tab position 1 of the next line (do it to understand)

Because we do not have control to the rule (this for example: margl767\margr767\margb767\margt767 *), we cannot efficiently use tabs with native code on Xojo. **

Cocoa Screen Shot

Carbon Screen Shot

There is the same number of tabs in the two screen shots above (12 ?), but the text appears at a different horizontal location.

I do not wasted my time with a Windows screen shot because it is basically the same as the Carbon screen shot.

  • Taken from a rtfd document created by me / Apple’s TextEdit.

** I tried to store the rtfdata into the clipboard / pasted it as text into a text document (Apple’s TextEdit) anddo not get the ‘phantom rule’.
I tried to change the TextArea Super to TextField: no more vertical scroll bar: the text disappear on the right part of the screen (now rap-around).
I tried to change the TextArea into Styles Off and many other properties changes to nothing better.
I am now waiting for a change from the Xojo team (I will not hold my breath).

Thank you for listening. Of course, I welcome a solution.

In the bug report I issued, I use a set of different screen shots and the text goes on the next line in the Cocoa screen shot / stays in the same line in the Windows screen shot. Other difference: in the other set of screen shots, I have text between tabs and in this set of screen shots I do not have.

There are many other differences between the two screen shots above (beside the resize icon in the Carbon window).


I’m a total newbie, so take anything I say with a healthy grain of salt. If I understand, being able to set the tabs would solve your problem. I’ve also been looking at RTF/RTFD issues and I believe you are mistaken when you say there is no control you can set. In what I’ve been looking at, the control word you want is “tx” where the following number is the tab position in twips from the left margin. “twips” I’ve recently learned is 1/1440 of an inch, so if you are European you’ll have to adjust.

For example, in an RTF doc I’m looking at in TextEdit, the relevant line is:


where the first tab is set to 720 twips (1/2 inch), the second at 1440 twips (1"), the third at 2160 twips, etc.

Hope this helps.


This may also be helpful:


The first and fourth tabs are still left tab stops; the second and fifth are center (“tqc”); the third and sixth are right (“tar”); and the seventh and eight are decimal (“tqdec”).

I think I send this before
Don’t rely on TABS in your text to do anything specific in a text area.
If you want text aligned in a specific way either use a control that explicitly supports tab stops (TextArea doesn’t really) or use a listbox or draw the text yourself using a canvas

Norman, not trying to argue, but the tab control codes have been in Microsoft’s RTF spec since the nineties. Xojo respects that for now and should for as long as RTF is a supported format, in my opinion. Seems like it would be work to remove that support.

Note I did not say “don’t use RTF” or any such thing.
You have no control over WHERE the tab stops occur.
So relying on a TAB to position consistently across platforms is where the problem is.
Thats what Emile is expecting and what I’m saying he should not be relying on.

Thanks for clarifying that. That actually begs the question, though, of why there is no control. I understand that there are no built-in properties. I’ve been assuming that it would be possible to just write the control codes into the text using standard string functions. I haven’t tried it (other than in the macoslib-extended version, where it works but that’s not the discussion here).

Anyway, if I try it and it doesn’t work, you told me so.

It might work.
But it’s not necessarily going to work xplatform.
The text area is not a “rich text editor” - which is a ton more work to support tab rulers, font selections etc etc etc
Which is where a third party has actually provided an option - see Bkeeney’s FTC

I did test this on a standard TextArea by pasting in an RTF doc created from TextEdit and all the tabs were where they should be and were of the proper type (left, right, center, etc.). Admittedly not the same as programmatically setting the tab stops, but it does show that Xojo (for now and on a Mac, at least) respects a subset of the RTF specs. I would imagine Windows would do at least as well since that’s where RTF came from.

Still, will take your caution to heart. Thanks

The rtf code I wrote were only to try to better explain - with my limited english - how the things are.
Yes, I know a lot about RTF (but not so much) have been used it since… ages (1988 or so) while I worked at Apple France.
At last, we can edit an Apple’s TextEdit rtf file (edit the rtf in the rtf file): marg __ 767 means a Tab width of (nearly) 1 cm instead of inch or twips…

RTFData in Xojo does not support Tab nor… Xojo support a very small subset of RTF.

How am I supposed to display (tons of) data from a (billion number of) text file(s) in a single TextEdit (TextField / TextArea) who have less than one line of text, more than one line in the paragraph, one or two or x… tabs to get vertically aligned data ?

Remember what I wrote far above: only the first 12 tabs are significant in Cocoa and the 12th location is near the middle of the TextArea width.
I read what you wrote, I think I understand what I read (in this case), but I cannot believe you wrote that or you understand what my description of the trouble is.
I also understand you cannot takes days to “check what a potential trouble can be”.

Using tabs in my TextArea works ‘correctly’ until I am near the middle of the TextArea width (in Cocoa, but works fine on Carbon / Windows). Text without tab can be displayed until near the end of the TextArea line (and wrap around only if the last word cannot be displayed on that line).

RTF support in TextArea is far less than basic and so I do not use it. I only load raw text from files (unfortunately) because of that with one exception.
In that exception file, I have to create, edit and save the rtf (to date, I use only one font in Standard and Bold flavors) in a specially created project to avoid troubles.
Troubles (files created with Apple’s TextEdit) : the used font in the original document is not displayed, Encoding is not used too on diacritical characters (é = \zyx and so on), etc. And sometimes I have to correct more than one time a single file.

At last, yes, if I pay some third party work, I probably will be able to do what I want (probably). But in that case, I’d better stop with a software that needs the user to buy add-ons to replace its half working included Controls:

Replace the built-in ListBox with XYZ (I forgot what misses in ListBox some found),
Replace the built-in TextArea with Formated Text Control…,
Replace the built-in ProgressBar if you want to display correctly the waiting string,
Replace the Report tool with another *

And the list grows.

Yes, I am disappointed a little by Xojo and in anger almost with each time I use it. **

  • I do not used Xojo built-in Report because I do not had time to learn how it worked before giving my Pro Bono application to the client. I do not experiment it because of the bad “reports” I read later, once I could take time to learn how it works.

** Latest bug to date:

The example code below comes from
If Obj.PictureAvailable Then
Me.Image = obj.Picture
ElseIf Obj.FolderItemAvailable Then
Me.Image = Picture.Open(obj.FolderItem)
End If

In the line:
Me.Image = Picture.Open(obj.FolderItem)

Obj.FolderItem may refer to any file type (from a text file to a directory) ON COCOA.

On Carbon, Windows (and probably Linux: not tested), only an image file of the type passed with Me.AcceptFileDrop() goes there. You cannot have a reference of a text file or a Folder there.

I do not write about the lack of Focus Ring around the Canvas when the Cursor is above it, nor the Mouse Cursor change, etc. ON COCOA OS X. These occurs on Windows XP.
I stop here because these are not TextArea related.


The RTF control codes you mention (\marg…) don’t have anything to do with tabs. “Margin” means the distance from the edge of the paper to where the text starts (or ends). So \margl refers to the left margin, \margr refers to the right margin, etc. The control codes to set the tab stops are the ones I indicated. Also, I think a cm would be about 567 twips.

Anyway, see what I mean by using TextEdit to make a new document. Use the “Show Ruler” command to get a ruler up where you can set a bunch of different tab stops. Go ahead and type in some text by tabbing to various tab stops to verify that it works. Then save the file and close it by clicking on the red close button. Now in TextEdit, go to preferences, click on the “open and save” tab and check “Display RTF file as RTF code instead of formatted text”. Now open the file you just created and you will see all the RTF control codes, including the tab control codes I indicated.

To prove this will work in Xojo, create a TextArea in a window, making sure multiline, styled text, and accept tabs are checked, and run it. Open the file you created earlier in TextEdit, but this time make sure “Display RTF file as RTF code instead of formatted text” is unchecked before you open it (otherwise the control codes will be interpreted as text). Do a command-A to select all the text and copy it to the clipboard. Paste this into your Xojo TextArea and you will find that all the tab stops are working as they should. Also, all formatting including fonts, bolding, italicizing, font sizes, and diacriticals are preserved. At least on a Mac. Haven’t tried on Windows or Linux. In those cases, you may have to specify a codepage to use, I don’t know

Theoretically, you should be able to set the tabs programmatically, I haven’t tried it. What I found won’t work is trying to paste in the RTF information as a “default value”. It will have to be set at runtime. Alternatively, you should be able to load an RTF file (at runtime, of course) with the appropriate tab stops and be good to go.

Given what Norman has said, I’m just suggesting that this could be used as a workaround for now.



I don’t know yet how to write directly to the RTF control codes in a TextArea, though I think it must be possible. I was able to do the following. This was added to the open event of a TextArea control since I knew I could manually paste and do the same:

[code] dim st as string = “{\rtf1\ansi\ansicpg1252\cocoartf1265” + EndOfLine + “{\fonttbl\f0\fswiss\fcharset0 Helvetica;}” + EndOfLine + “{\colortbl;\red255\green255\blue255;}” _

  • EndOfLine +"\margl1440\margr1440\vieww25800\viewh16040\viewkind0" + EndOfLine + “\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\tx10864\tx14820\tx18331\tx20772\tx22950\tx25047\pardirnatural” _
  • EndOfLine + EndOfLine + “\f0\fs24 \cf0 \'e0 \'c2 \'f1 \'ed}”

Dim c As New Clipboard


Running this on a Mac gives you several extra tabs and a few diacritical characters. I did find that there has to be SOME text and not just the control codes, or the default 12 tabs will be what you get.

I hope this is useful.

Thank you for your answers.

The RTF control codes you mention (\marg…) don’t have anything to do with tabs.
You are right !
That is why I had tx in my mind at writing time, but I used \marg because I checked with a rtf file. In that file, I set the margins to 1cm (more or less). I’ve made a mistake.


I don’t know yet how to write directly to the RTF control codes in a TextArea

You simply read the whole data from a rtf file with a TextInputStream and pass it to RTFData. Read the dos and you will better understand.

Before creating a new conversation, I checked what is in the RTFData (what Xojo put in RTFData) by making a copy in the Clipboard and pasting it elsewhere… There was no defined tabs (unless I’ve made another mistake ?).
So, I just checked and… no, no \tx in RTFData:

{\\rtf1\\ansi\\ansicpg1252{\\fonttbl{\\f0\\fnil Lucida Grande;}}{\\colortbl\\red76\\green78\\blue78;\\red0\\green0\\blue233;\\red0\\green0\\blue0;\\red64\\green128\\blue4;\\red0\\green22\\blue176;\\red108\\green6\\blue211;\\red0\\green4\\blue255;\\red74\\green30\\blue127;\\red38\\green18\\blue82;\\red68\\green21\\blue176;}\\uc0 \\ql\\f0\\cf0\\fs24

header of the RTFData with an empty line defined. The original document (copied from Apple’s TextEdit application) is an AppleScript’ Script, so you understand the defined colors in \colortbl.

rtf in Apple’s TextEdit application have:

and, if a line have defined tab(s), something like: \tx followed by a value in twips to define each \tab location as in:

\\cf2 	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20\\

Remember: 1 cm = 566.333333… I rounded the value to 567 and it seems to be OK in Apple’s TextEdit rule bar (the tab interface triangle seems to be above each cm bar) running with French defaults (cm instead of inch)

But all of this does not exists in Xojo.

Have a look at my screen shot (from Xojo app) in the next entry…

I wake up earlier today with an idea in mind: what if my TextArea is 1,400 pixels wide ?
[understand: what Xojo will do if I set a TextArea with 1,400 pixel width ?]

I checked that immediately and here is what you can see once the application is running, with a bit of text:

I typed as many as 13 times in the Tab key, added some comments and here you are.

The project is new (virgin), I set the window to 1,400 x 900 (?), added a TextArea and set its size to window size - 20, set AcceptTabs to True and run it in the IDE. Nothing more.
Xojo 2013r4.1, OS X 10.8.5

Imagine you have to put data in a A3 paper and in these data you have aligned values (using Tab, one cannot do that differently excepted using mono spaced fonts).
These data can comes from a raw text file.

I forgot to note that line 1 is inside a paragraph of 3 lines without any LF, Return or anything from me that will force a wrap-around.
If I typed some text, it may have filled the whole TextArea width, continuing far away from where the tab wraparound happens.

Xojo’s RTF does not support a feature that was present in typewriters ? Astonishing…


I had typewriter courses as early as 1970…

The introduction of the Tab key dates from 1897 ?

[quote]You simply read the whole data from a rtf file with a TextInputStream and pass it to RTFData[/quote] What I mean is that there is no direct way to do something like TextArea1.StyledText.RTFControlString = “\tx567\tx1134”. Xojo does explicitly handle bolding, alignment, italicizing, colors, and a few others, but there is not an obvious way to insert a generic control string. So far for me, Xojo interprets what I try to put in literally (as in Xojo thinks the control strings are text to be displayed).

That’s why I used the paste method and it DOES work. Seriously, put the following in the open event handler for a text area:

[code] // This will set tab stops every centimeter for 21 cm

dim st as string = “{\rtf1\ansi\ansicpg1252\cocoartf1265” + EndOfLine + “{\fonttbl\f0\fswiss\fcharset0 Helvetica;}” + EndOfLine + “{\colortbl;\red255\green255\blue255;}” _

  • EndOfLine +"\margl1440\margr1440\vieww25800\viewh16040\viewkind0" + EndOfLine _
  • “\pard\tx567\tx1134\tx1699\tx2266\tx2833\tx3400\tx3967\tx4534\tx5101\tx5668\tx6235\tx6802\tx7369\tx7936\tx8503\tx9070\tx9637\tx10204\tx10771\tx11338\tx11905\pardeftab720\pardirnatural” _
  • EndOfLine + EndOfLine + “\f0\fs24 \cf0 a}”

Dim c As New Clipboard

You will see that you do indeed now have 21 tab stops on one line. You’ll have to expand your window to see them all. You REALLY need to try this.


Xojo has done a great job implementing rtf. If you’ve ever worked with xcode, rtf support is @!#$/!. And the RTF view for cocoa is 500 euros (do a Google search)… so FTC really isn’t that expensive… All languages require an add on of sorts in one situation or another. . Even if it’s a set of specialized classes. … Like Norman has mentioned before, cocoa is a beast of its own in comparison to carbon… everything comes with a price even if it’s not monetary. And usually the income you generate from a piece of software pays for the add ons you invest in, and builds your “code arsenal.” So the means justify the ends. :slight_smile: you say that you are loading the text? Will the text need editing by the user or just to be viewed? If viewing only by the user, there are classes already available to display rtf in an htmlviewer. Really should at least look at the demo of FTC and see if it suits your needs. Bkeeny also has another control that does the same thing as FTC (without code lines etc…basically a text area control) for $15.00 that can do what you are looking for. $15 really isn’t that much in the scope of the situation. There is a demo of that as well, and it supports rtf/html and images.

No question there, but after playing with this for a while, I do think what would really round things out would be methods to set and get generic RTF control codes. The RTF spec has a whole boatload of control codes, and Apple has added their own for OS X. This doesn’t hurt anything since the spec also calls for the viewer/editor to ignore unhandled control codes (and doesn’t call for throwing those away, although that’s probably not prohibited).

By having a way to easily set and get control codes that Xojo doesn’t handle, the programmer can provide his own methods to deal with those. In addition, a lot of those things should stay with the document, good examples being \author, \title, and , yes, tab stops. It’s totally fine if Xojo chooses not to deal with a lot of these, but shouldn’t make it difficult for the programmer to get to them.

It’s especially galling in this case where the viewer DOES handle tabs correctly - the only issue being it is damn near impossible to set them.

Just my $0.02 and probably not worth that.

Hence why I’ve said more than once “I would not use RTF for this and expect anything approaching consistent results across platforms”
Hence why I’ve said I would not rely on RTF for what Emile is relying on it to do.

Oh well.