Thank you for your suggestion!
Sorry to get back to you so late, but work gets in the way and stuff, heh.
Now it's my turn to apologise for the delay - for the same reason...
Have you checked the textFont ? get the textFont of line 2 to 2 + the number of lines of fld "source" If the second item is "japanese" or something like that, it probably didn't get transfered from the source field. So you'll have to fix that : set the textFont of line 2 to 2 + the number of lines of fld "source" to "Arial,cyrillic" (Replace 'cyrillic' with the appropriate name)
Checking the "textFont" property yielded some interesting observations...
For those who haven't been following this thread: we are trying to copy UNICODE TEXT (specifically, in Esperanto), from one field into a SPECIFIC LINE of another.
Based on your suggestion, I tried first of all checking the 'textFont' of the SOURCE field (not the target). As I suspected after reading your post, the 'textFont' of all Esperanto characters typed in the field (ĉ, ŝ, ĝ, ĥ, ĵ, ŭ) is "Lucida Grande, Japanese" - even though the field's own 'textFont' property reports empty. It seems that any extended character in Rev is considered 'Japanese'...
So what is happening is that as I type the characters in the source field, using the extended unicode keyboard, Revolution is setting the textFont of each character on a character-by-character basis. Even if after typing I try to use the messageBox to set the 'textFont' of my Esperanto characters to empty, Revolution immediately sets it back to "Japanese"...
Now, the strange thing is what happens when I run the following script, trying to copy field "sourceFld" into line 2 of field "targetFld":
on mouseUp put the unicodeText of field "targetFld" into newText put the unicodeText of field "sourceFld" into newLine2 put newLine2 into line 2 of newText set the unicodeText of field "targetFld" to newText end mouseUp
The text of field "sourceFld" was : Ĉu vi ŝatas tiun pa ĝon?
The text of field "targetFld" was: This is line 1 of the target field. And this is line 2! This one should be the third line of the target. While THIS should be the 4th. If I keep on writing, we'll have 5 lines. And to finish, a line number 6!
Note that the last 3 characters in field "sourceFld" are NOT Esperanto characters - they are just normal letters, so that the 'textFont' property of the last 3 chars of line 2 of field "targetFld" now report "Lucida Grande" only (no "Japanese" in the second item).
After the script is run, however, EVERY character, starting from char 1 of line 3, has its textFont property set to "Lucida Grande, Japanese" - even though that's not what they were to start with... So that where before I had text in English, now I have a bunch of Japanese characters...
More oddities: even though "the number of lines in field "targetFld"" still reports "6", the 'returns' after line 2 are being IGNORED, so that the Japanese characters on the lines appear to just follow on and wrap around in the normal manner, as if there were no returns there at all, and just one big paragraph.
Last of all: if I try to set the textFont of these lines (or characters) back to empty, then the English characters reappear. The 'returns', however, now display as "forward delete" icons, and the field still ignores the line breaks, just as it did when the text was "Japanese" (ie, all of the lines following line 2 are 'grouped' into a big paragraph, which simply wraps around in the normal manner). I can't seem to find a way to make the 'returns' go back to normal...
This is very, very frustrating! So much work for something that should be such a simple thing to do! - copying one line from one field to another...
Any further help or suggestions are most welcome - I'm totally stunned...
-- Igor ---------------------------------- [EMAIL PROTECTED] ---------------------------------- _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
