Stopping the User from Adding/Removing Lines to a field

[Ken Ray]

Igor,

Do you mean that you can't use Unicode text in list fields? I didn't know
that...

Ken Ray
Sons of Thunder Software
Email: kray at sonsothunder.com
Web Site: http://www.sonsothunder.com/


> From:     Igor Couto <igor at pixelmedia.com.au>
> Reply-To: use-revolution at lists.runrev.com
> Date: Sun, 29 Jun 2003 11:05:59 +1000
> To:     use-revolution at lists.runrev.com
> Subject: Re: Stopping the User from Adding/Removing Lines to a field
> 
> 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
> ----------------------------------
> 
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution