I have a BB app (written with j2me and lwuit). There are a lot of text fields (com.sun.lwuit.TextArea objects) in the app. When running it, if I type characters in the text fields, the cursor advances after each character, except for space. When I press space (no matter how many times), the cursor does not move. If I press space many times and then press another key (letter or whatever), the spaces are there... they appear correctly and the cursor advances after the last character. I hope I explained it clearly.
Anyone can tell what is wrong here? There is nothing special about the TextArea objects... I just create them then set a hint and a max size, that's it.
Thanks a lot,
Silviu
Related
I have a unicode string that could contain characters from a right to left language such as Arabic or Hebrew, but could also contain text from left to right languages. I need to be able to know at which end is the start and in which direction to step when stepping through the string from beginning to end depending on which language is in the string. Is there a standard way of dealing with this?
TMemo appears to handle this in the way I want. I paste some hebrew text into a TMemo and the direction that the caret moves is the reverse of the arrow keys I use. I can even have a mixture of english and hebrew text in the same memo and the direction the caret moves will depend on whether it's within an english or hebrew section of text. I'd like to replicate this behaviour. I attempted to look into the Delphi code including FMX.Memo and FMX.Text, but couldn't find the code responsible. I have a feeling that the code for handling this may be hidden in a dll. I could write code myself that contains a list of all possible right to left unicode characters to test if a character is RTL or LTR, but I'd like to make use of code that already exists if possible. Can anyone point me in the right direction?
I do know about the unicode RLM mark, which is an invisible character used to mark a section of RTL text, but I don't think this is being used by TMemo. The hebrew text I'm pasting into the TMemo doesn't contain this or any other invisible character.
Is it possible to enter from keyboard special Unicode characters, link the ones below?
U+2603 ☃ SNOWMAN
U+2604 ☄ COMET
U+2605 ★ BLACK STAR
U+2606 ☆ WHITE STAR
U+2607 ☇ LIGHTNING
U+2608 ☈ THUNDERSTORM
U+2609 ☉ SUN
U+260A ☊ ASCENDING NODE
U+260B ☋ DESCENDING NODE
I would like for example to have buttons with up/down arrows in them, without loading images.
I have tried entering Alt+08593 on keyboard but other character (than the expected arrow) will be inserted.
Update:
The reason for this is LAZINESS. I am too lazy to search for icons or create my own icons. For example you can simply replace the notorious 'save' floppy disk icon. Just take a look at: 💾. BAM! Nice. Right?
Update:
It seems some characters such as 📗 (green book = 128215) are not accepted by Delphi, with copy/paste.
Update:
There is nice component that allows you to put unicode chanracters in a image list:
https://github.com/EtheaDev/IconFontsImageList
The Delphi IDE won't accept ALT key codes that high. A couple of alternatives:
Paste the text from somewhere else.
Enter the numeric code directly in the .dfm file.
As an example of the second approach, try this in your .dfm file for the button caption property:
Caption = #8592#8593#8594#8595
You also mention Green Book U+1F4D7. That is from outside the BMP, and hence encoded with a surrogate pair:
Caption = #55357#56535
My guess is that as soon as you want your glyphs to be shown in colour, or at a different size, you will find that using text makes this impossible. You are also likely to encounter fonts that don't contain glyphs for the characters you select. So you will find that using images is the most robust approach.
Or, alternatively, if you had a table of the decimal values:
9731 ☃ SNOWMAN
9732 ☄ COMET
9733 ★ BLACK STAR
9734 ☆ WHITE STAR
9735 ☇ LIGHTNING
9736 ☈ THUNDERSTORM
9737 ☉ SUN
9738 ☊ ASCENDING NODE
9739 ☋ DESCENDING NODE
then you can use the keyboard as follows in Delphi.
To change the caption of Button1 to be the snowman:
Press Alt+F12 to edit the form as text
Press Ctrl+E to enter incremental search mode
Type Button1, or as much of it as is required to locate the definition of Button1
To the right of the Caption = property definition (I'm assuming VCL here) enter # followed by the relevant Unicode value, e.g. #9731
Caption = #9731
If you want text as well as the snowman, the character code goes outside quotes, so e.g.
Caption = 'Snowman = '#9731
More info on the # syntax (which is more commonly entered in Delphi source, rather than in the text view of form files) can be found by reading about control strings, as they are actually called, in the online documentation.
What was the original historical use of the vertical tab character (\v in the C language, ASCII 11)?
Did it ever have a key on a keyboard? How did someone generate it?
Is there any language or system still in use today where the vertical tab character does something interesting and useful?
Vertical tab was used to speed up printer vertical movement. Some printers used special tab belts with various tab spots. This helped align content on forms. VT to header space, fill in header, VT to body area, fill in lines, VT to form footer. Generally it was coded in the program as a character constant. From the keyboard, it would be CTRL-K.
I don't believe anyone would have a reason to use it any more. Most forms are generated in a printer control language like postscript.
#Talvi Wilson noted it used in python '\v'.
print("hello\vworld")
Output:
hello
world
The above output appears to result in the default vertical size being one line. I have tested with perl "\013" and the same output occurs. This could be used to do line feed without a carriage return on devices with convert linefeed to carriage-return + linefeed.
Microsoft Word uses VT as a line separator in order to distinguish it from the normal new line function, which is used as a paragraph separator.
In the medical industry, VT is used as the start of frame character in the MLLP/LLP/HLLP protocols that are used to frame HL-7 data, which has been a standard for medical exchange since the late 80s and is still in wide use.
It was used during the typewriter era to move down a page to the next vertical stop, typically spaced 6 lines apart (much the same way horizontal tabs move along a line by 8 characters).
In modern day settings, the vt is of very little, if any, significance.
The ASCII vertical tab (\x0B)is still used in some databases and file formats as a new line WITHIN a field. For example:
In the .mer file format to allow new lines within a data field,
FileMaker databases can use vertical tabs as a linefeed (see https://support.microsoft.com/en-gb/kb/59096).
I have found that the VT char is used in pptx text boxes at the end of each line shown in the box in oder to adjust the text to the size of the box.
It seems to be automatically generated by powerpoint (not introduced by the user) in order to move the text to the next line and fix the complete text block to the text box. In the example below, in the position of §:
"This is a text §
inside a text box"
A vertical tab was the opposite of a line feed i.e. it went upwards by one line. It had nothing to do with tab positions. If you want to prove this, try it on an RS232 terminal.
similar to R0byn's experience, i was experimenting with a Powerpoint slide presentation and dumped out the main body of text on the slide, finding that all the places where one would typically find carriage return (ASCII 13/0x0d/^M) or line feed/new line (ASCII 10/0x0a/^J) characters, it uses vertical tab (ASCII 11/0x0b/^K) instead, presumably for the exact reason that dan04 described above for Word: to serve as a "newline" while staying within the same paragraph. good question though as i totally thought this character would be as useless as a teletype terminal today.
I believe it's still being used, not sure exactly. There might be even a key combination of it.
As English is written Left to Right, Arabic Right to Left, there are languages in world that are also written top to bottom. In that case a vertical tab might be useful same as the horizontal tab is used for English text.
I tried searching, but couldn't find anything useful yet.
I'm using ITextRange from a RichEdit control. I want to determine if a user's cursor is touching a word.
The problem is that calling iTextRange.expand(tomWord) will include tailing spaces:
Brackets indicate the range:
Before:
weas[]el .
After:
[weasel ].
My original plan was to expand the range, and check if it contained the cursor. But the user's cursor could be two spaces after "weasel", and the range will still expand to contain it. So what else can I do?
I can recall facing a similar problem: that is, how to select a word without selecting any trailing space. I think that code like this C++
textRange->StartOf(tomWord,tomMove,NULL);
textRange->MoveEnd(tomWord,1,NULL);
should give you the right selection, so that you can then test if the caret is in the selection.
How can I fully justify a block of text (like MS Word does, not only on the right and not only on the left but on both sides)?
I want to justify some texts (mainly arabic text) adjusted to certain screen size (some handheld device screen actually, and its text viewer doesn't have this function) and save this text as justified. So I can reload and reuse it again elsewhere.
(The problem with MS word is, that if you copy the justified text from MS Word and paste it to another editor it'll copy it un-justified).
Update : for now I'm thinking of doing it like this:
get-a-word
get-word-width
add-word-to-total-Word and add-Word-width-to-total-word-width
check if total-Word-width = myscreen-width then continue
else if total-Word-width is between myscree-wdith and (myscreen-width -3) then
add-spaces-To-total-word until it = myscreen-width
This is what I'm thinking now, but I put this question up and hope to see if there is a better solution, or somebody else already implemented it.
PS: I hope I have made my question clear and I'm sorry for bad expression if there is.
edit1 : changed the title to make it more clear.
If you want to justify plain text, you can only add extra spaces to the lines to get them align on the left and right. Unfortunately the character widths differ in fonts; so doing it this way will only work for a certain font, unless you limit yourself to monospaced fonts where all characters have the same size.
If you want a result like in Word, adding spaces won't cut it. Word will not add spaces, but stretch and shrink the existing spaces. This information is lost when you copy and paste it into another app.
Either way, justifying is an optimization problem. If you are interested in a good solution and its implementation: have a look a TeX. For an implementation that works on plain text with monospaced fonts have a look at par
There are some API calls that may help:
ExtTextOut and GetCharacterPlacement
Look at the GCP_JUSTIFY flag for GetCharacterPlacement
ExtTextOut is used by Canvas.TextRect
The problem you are going to face is always going to be differences in the rendering of the font. Word handles full justification by adjusting kerning as well as adjusting the number of pixels between words by a few (either way). The end result is lined up both margins. This pixel adjustment is done BOTH ways, and as evenly as possible.
To properly handle this in your portable device you will have to also perform the same algorithm for the display of the text there.
If this is not possible, then the ONLY way you can even get somewhat close would be to add whitespace between words.
As has been pointed out in other answers Word does full justification by stretching the existing spaces often by very small amounts. This is only possible if you have full control over how your text is drawn on the screen (which word - or any other windows program has).
You only real option in this regard would be to implement your own text viewer on the platform you are targeting. Eg you would need to draw the text on the screen yourself (any platform that allows games should allow you to draw on the screen). However this seems like an awful lot of trouble to get justified text.
Sorry couldn't be of more help.