Hi,
When I press the tab key in my text area, it first of all moves only 1 character’s width to the right, and then only after pressing it again, does the proper space expected from a tab get inserted?
Is this expected behaviour?
Thank you.
Depends on where in the “default but invisible” tab stop position and current cursor positions are.
Do the same after removing one or two characters and watch if it behave the same (I do not think so).
I do not really knows how this works on Windows (even it today is the 14th consecutive day I use Windows only). OnOS X, there is a default but invisible rule (the same you can see in Apple’s TextEditin styled mode).
To see that, press many times into the tab key, cursor inside the TextArea and watch it carefully / compare with Apple’s TextEdit in styled mode.
In a textarea each line is divided in 8 characters width blocks. If your text is within a block of 8 characters the first tab should jump to the first character after that block of 8 characters, so it should move the cursor 1 to 7 characters in a partly filled block and 8 when the block is empty.
Unfortunately in the implementation of the textarea the tabs don’t work correct and is the tabbing unreliable.
To show this behaviour put a textarea on a window and set the textfont to “Courier New” on Windows or “Helvetica” i think it’s on a Mac. Then enter this text: “1234567890123456789012345678901234567890” in the textarea and then on the next line try tabbing from the start of the line and you will see that the tabs are not matching the tab-positions.
[quote=151385:@Andre Kuiper]In a textarea each line is divided in 8 characters width blocks. If your text is within a block of 8 characters the first tab should jump to the first character after that block of 8 characters, so it should move the cursor 1 to 7 characters in a partly filled block and 8 when the block is empty.
Unfortunately in the implementation of the textarea the tabs don’t work correct and is the tabbing unreliable.
To show this behaviour put a textarea on a window and set the textfont to “Courier New” on Windows or “Helvetica” i think it’s on a Mac. Then enter this text: “1234567890123456789012345678901234567890” in the textarea and then on the next line try tabbing from the start of the line and you will see that the tabs are not matching the tab-positions.[/quote]
Well yeah. You need to select a monospaced font for tabs to be consistent from line to line. Try this experiment with MS-Sans and Monaco and it does work properly.
Hi Greg,
Courier New is monospaced AFAIK. I tried MS-Sans and Monaco and both show the same fault.
Huh. It’s not doing that here. I wonder why.
Most fonts have monospaced digits. But tabs may be estmated on another character widths. Best use a monospace indeed.
How do I know which fonts are monospaced? I currently have my text area set to System 12.
Richard, if you Google it, you’ll find various lists out there, some more complete than others. Here’s one that I saw that has a number of them (42 to be exact) that might help you a bit.
Thanks Don !
BTW, Richard … Although I believe “System” is NOT a fixed width font, there is one in the Xojo Inspector drop-down font list that is called “Fixedsys” that I believe is (remember, I’m using Windows here). Might want to try it.
Cool - I will take a look. Thank you.
simple test will show it if a font is monospaced:
i (Underscore +i+underscore)
w (Undescore +w+underscore)
If these characters are equally width then chances are great it’s a monospaced font.
But MIchel is the font specialist on this forum and he can tell you exact how to know for sure.
[quote=151484:@Andre Kuiper]simple test will show it if a font is monospaced:
i (Underscore +i+underscore)
w (Undescore +w+underscore)
If these characters are equally width then chances are great it’s a monospaced font.
But MIchel is the font specialist on this forum and he can tell you exact how to know for sure.[/quote]
Your approach is good, Andre. I have another test :
123456789012345678
anticonstitutional
123456789012345678
anticonstitutional
The first set uses a proportional font, and the phrase comes up shorter, whereas the second in code with Courier, which is a standard monospaced font like American typewriter, both inspired by vintage typewriters, shows both lines to be of equal length.
Most standard font have monospaced digits, which explains why they line up so nicely in spreadsheets and listboxes.
Wrong… and true. For the first Tabs, this is wrong, but only some tabs are defined and after that in the first line of a paragraph, there is no tab until the end of the line.
As I stated before, run TextEdit and watch were are the tabs: these are the same used tabs you will found in Xojo TextArea.
At last, the use of monospaced fonts is a step backward of so many years. The real solution is to avoid Xojo native rtf and use OSXlib rtf and you will get a perfectly working and fast RTF in TextArea.
On the Windows side of things, I use the MBS WIN plug-in for anything RTF in a TextArea … solved every problem (including speed) that I ever had with the native Xojo RTF handling.