Re: Going Mad With Unicode
Hey, Jan! 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
Re: Going Mad With Unicode - Breakthrough!
To all who have been immensely helpful by following this thread and providing suggestions: I just managed to copy the extended unicode characters (in Esperanto) from one field to a specific line in another - using the HTMLTEXT property. There seems to be 2 ways to do it: The longer way: put the htmlText of field targetFld into newText put the htmlText of field sourceFld into newLine2 put newLine2 into line 2 of newText set the htmlText of field targetFld to newText Or the shorter way: set the htmlText of line 2 of field targetFld to the htmlText of field sourceFld For some reason, this IS working now! FABULOUS!!! Once again, many thanks to all who provided suggestions! -- Igor de Oliveira Couto -- [EMAIL PROTECTED] -- ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Going Mad With Unicode
--- Igor Couto [EMAIL PROTECTED] wrote: Dear Jan, Thank you for your prompt suggestion! [snip] In my test, targetf was 6 lines long. Much to my surprise, this script DID copy the right characters into line 2 of the target! However, after line 2, ALL CHARACTERS TURNED TO JAPANESE! *hehehehehe* This is reproducible, and always happens right after the 'pasted' line - ie, if I change the 3rd line of the script to say put theSource into line 4 of theTarget, then the source field ends up OK up until the end of line 4, and then it's just japanese gobbledigook! Jan, do you have any suggestions? It feels like we're getting close, here! -- Igor Hi Igor, Sorry to get back to you so late, but work gets in the way and stuff, heh. 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) Hope this helped, Jan Schenkel. = As we grow older, we grow both wiser and more foolish at the same time. (La Rochefoucauld) __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Going Mad With Unicode
Friend Revolutionaries, I have been trying to copy (via script) the contents of a field into a specific line in another field. The problem I'm experiencing is that the text contains roman-extended characters (Esperanto characters: , , , , and ), and even though I've tried everything I can think of, using the 'unicodeText' and the 'htmlText' properties, I still cannot make it work. I am using RunRev 2.0, with MacOS X 10.2.6. To reproduce what I am experiencing, try the following: 1) Make a new stack, and place 2 fields in it - let's call them sourceFld and targetFld. The source field can be just one line high, while the target field should be several lines high. Type something into the target field (it doesn't matter what) - for a few lines. 2) In the source field, type some text using the 'US Extended' keyboard layout. To type some of these Esperanto characters, for instance, while using the 'US Extended' keyboard, press option+6 (to activate the circumflex accent) and then either 'c', 's', 'g', 'j' or 'h'. 3) NOW: using the message box, try creating a script that copies the contents of sourceFld into a line (let's say, line 2) of targetFld. The extended characters either disappear or change... Here is what I've already tried: 1) put field sourceFld into line 2 of field targetFld RESULT: the extended characters appear in the targetFld as 'unknown character' boxes. 2) put the unicodeText of field sourceFld into line 2 of field targetFld RESULT: exactly the same as above - the extended characters appear as blank boxes. 3) set the htmlText of line 2 of field targetFld to the htmlText of field sourceFld RESULT: the characters disappear. If I check the 'htmlText' property of line 2 of the target field, I can see that it actually does NOT contain the same characters as the source field (compare with the htmlText property of the source field!). 4) set the unicodeText of line 2 of field targetFld to the unicodeText of field sourceFld RESULT: an error - I believe the ' unicodeText' is not a property that can be 'set' on a 'per line' basis. It only seems to work if you set the entire field! What seems to happen is that Revolution IS COPYING the right values out of the source field. If I 'split' the script, and get Rev to put the htmlText of the source field into a variable, and then check the contents of the variable, it actually DOES contain the right characters: put the htmlText of field sourceFld into myVar put myVar The contents of 'myVar' are IDENTICAL to the contents of the htmlText of field sourceFld. However, if we now say: set the htmlText of line 2 of field targetFld to myVar We see that Revolution is somehow changing the values of the extended characters... Does anyone know how to get around this? I'm sure that there must be a solution, as I understand Revolution has quite a few Japanese users, and they must be able to deal with this somehow! Any suggestions would be greatly appreciated! Many thanks, -- Igor de Oliveira Couto -- [EMAIL PROTECTED] -- ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Going Mad With Unicode
--- Igor Couto [EMAIL PROTECTED] wrote: Friend Revolutionaries, I have been trying to copy (via script) the contents of a field into a specific line in another field. The problem I'm experiencing is that the text contains roman-extended characters (Esperanto characters: Ä?, Ä, Å, ĵ, Ä¥ and Å), and even though I've tried everything I can think of, using the 'unicodeText' and the 'htmlText' properties, I still cannot make it work. [snip] Any suggestions would be greatly appreciated! Many thanks, -- Igor de Oliveira Couto Hi Igor, You can't set the unicodeText or htmlText of an individual line ; they're 'all or nothing' properties for the entire field. However, this workaround might do the trick : put the htmlText of fld source into tSource put the htmltext of fld target into tTarget put tSource into line 2 of tTarget set the htmlText of fld target to tTarget Most of the time, line i of the htmltext corresponds to line i of the text ; if not, you'll have to do some funny things with offset(p, tTarget) offset(/p, tTarget) to find out where line i of the text starts and ends in the htmlText. Hope this helped, Jan Schenkel. = As we grow older, we grow both wiser and more foolish at the same time. (La Rochefoucauld) __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
