Stopping the User from Adding/Removing Lines to a field

[Igor Couto]

Dear Ken,

Once again, thank you for the suggestion!

On Sunday, June 29, 2003, at 08:08  AM, Ken Ray wrote:

> How about using an actual list field, and only allow changing when the 
> user
> double-clicks on a line? You could bring up an "ask" dialog allowing 
> them to
> change the value of the line. This would prevent all the 
> clipboard/keydown
> issues completely.

Yep, that could have done the trick, if my users were not going to be 
using UNICODE text (international characters).

See, right now, the way that I have this setup is like this: when the 
user clicks on a line, I place a specially-sized field EXACTLY on top 
of that line, containing the line's text for the user to edit. This 
field has the 'tab on enter' and "don't wrap' set to true, so it only 
allows the user to edit/delete ONE LINE at a time - exactly the 
behaviour I want. However, the problem I am having is that Revolution 
is not very good (yet) in dealing with international (Unicode) text... 
Copying the user-selected line into the editing field is no problem - 
We can do that quite easily, using 'set the text of field editField to 
the unicodeText of line x of field sourceField'. However, I have not 
been able to successfully and reliably copy the contents of the 
editField back into LINE X of the sourceField - Revolution gets a bit 
messed up with changing just a single line of unicodeText...

Before you make any further suggestions, this is what has already been 
tried by me and a few others in this list:

a) putting the contents of the sourceField into a variable, placing the 
contents of the editField into line x of the variable, and then setting 
the unicodeText of the sourceField to the variable.

b) using the same technique described above, but with the htmlText 
property instead - this often yields better results.

It seems to me (perhaps wrongly) that Revolution tries to be 'optimal', 
and decide on a character-by-character basis whether that character 
should be Unicode or not - and it changes the ;textFont' property of 
the char to reflect its guess. What ends up happening is that a lot of 
times we get gibberish text, or it all just turns into Japanese text 
(even the roman characters), because Rev has set the textFont to 
",Japanese". I have already wasted hours and hours playing with the 
textFont, unicodeText, htmlText properties, and trying to script a 
reliable workaround to that. In the end, I ended up giving up, sending 
a message to Tuviah, and reporting this as a bug in the bug database.

So, now I'm approaching the problem from another angle: the user CAN, 
indeed, enter the correct international characters DIRECTLY in the 
field. What is 'messing up' the procedure is having to enter it in a 
separate field, and then bring it across into the list field. So, if I 
could just work out a way to LIMIT the entry of the user to a SINGLE 
LINE, I could do away with the need for the 'editField'...

Any further suggestions would be TREMENDOUS!

Kind Regards,
--
Igor
----------------------------------
igor at pixelmedia.com.au
----------------------------------