I have a text box, the size will change, using Ctrl+a I have highlight the text in the text box, how to get the coordinates of this highlighted text? so that I can readtext() that area. Actually I tried copying the highlighted text to clip board and then to put in a variable. But if I compare with an existing text I am getting an \n for the end of the line, if I compare the text retrieved with original text , they don't match. so I am thinking of using readtext()
Please help me in this regard.
Can you try with format function. Should get rid of escape sequences.
typeText controlKey&a
typeText controlKey&c
put remoteClipboard() into yourVariable
put format("%b", yourVariable) into newVariable
Reference link: SenseTalk
how are you comparing in your scenario?
When your use "contains" in your condition you can achieve what you have expected.
I have a UILabel that is supposed to be two lines long. The text is localized into French and English.
I'm setting the attributedText property of the label. The text is constructed from three appended strings, say textFragment1, textFragment2 and textFragment3. The middle string is actually an image created with an NSTextAttachment.
I want to make sure that textFragment2 and textFragment3 are on the same line. The first string may or may not wrap depending on how long it is. The problem is that my French text is currently fairly short, so the line is wrapping after textFragment2.
I have fixed this temporarily by adding a line break symbol in the localized French text for textFragment1. I don't really love this solution though. I was wondering if there is a way to treat textFragment2 and textFragment3 so that they will always be together on the same line.
You could use a non-breaking space (\u00a0) to join textFragment2 and textFragment3. This character looks just like a normal space—i.e. it results in the same amount of whitespace—but line breaking will not take place on either side of it.
You could also use a zero-width space (\u2060). Using this character will not result in any whitespace, but it will still prevent line breaking on either side. This is what you want if you don’t want any space between textFragment2 and textFragment3 but you still want to prevent line breaking there. (It’s also useful if you have a word with a hyphen in the middle of it but you want to prevent the line from being broken after the hyphen.)
You can read more about these kinds of characters on Wikipedia.
I am writing a vba macro that checks that word documents are formatted correctly to meet certain specifications. One of the things I have to check for are the left margins of each line - different paragraphs are supposed to have different first indents and hanging indents depending on the context. This should be as simple as checking the style, but unfortunately it is not - some of the documents use styles to change the indents, but others use manual spaces and tabs to position the text correctly. So I need some way to check the actual physical position of the first physical character in each Document.Paragraphs. I have no problem getting a range with the first visible character in the paragraph, but I'm not sure about getting the distance from the margin (or from the left side of the page - doesn't make a difference because the margins are consistent).
I found the Window.GetPoint method, but I'm nervous to use it, because that is based on the actual physical location on the screen. This macro is going to be used on different computers, with different versions of word, and I'm not sure about how it is affected by other view settings (like print layout, zoom, etc.) Is there a consistent way to use this method to determine the distance from the margin?
The other method would be (because all of the documents are in Courier New 12) to look at the firstindent property of the style, and the count manually all of the spaces and tabs (but that would need to take into account tabstops). This I'm also not sure how to do.
I would think that there should be a much simpler way of doing this, but I can't find it, so if anyone has any suggestions I would really appreciate any help.
It was there after all! Range.Information(wdHorizontalPositionRelativeToPage)
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
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.