LiveCode Forums.

I have field, where is text with accented characters, in this example 1 dummy word "śmióaśw".
I have script to select all the word when I double click on it: - when I double click on last letter " ś", letter "w" or between them - selected is only "w"
- when I double click on any place between first "ś" including it and second "ś" - selected is "mióaśw" part of the word only
- only when I double click before first letter "ś" all the word is selected.

The same is if I replace mouseText with mouseChunk in my script.

Please help to locate the fault - is it on my side or is it the LC bug of working with unicode.

Marek

Hi marek,

It is a bug and it has never worked correctly in Revolution/LiveCode.

A possible workaround is to get the clickCharChunk and to use a repeat loop to search for the preceding and following uniEncoded spaces, returns or tabs.
This only works if the lockText of the field is true.

Kind regards,

Mark

Hi Mark,

Thanks a lot for quick reply. Your solution works perfectly, but I still have problem - I must use it without lockText set to true, because I need to select word and then paste in it's place another one.

I was trying lockText and unlock it by script, but there is not working "on mouseDoubleClick" handler when the field has lockText property set to true (I can't see the doubleClick message in message viewer also when lockField is true).

Marek

Hi Marek,

Did you set the traversalOn of the field to true? If yes, then you can still copy text. If you want to cut it, you need to write a commandKeyDown and a posibly a menuPick handler, which delete the selectedChunk.

Kind regards,

Mark

Hi Mark,

traversalOn is true.

I need to:
- type into (with unicode characters - like ąśźĄŚŻŁ etc.)
- select chunks (all words or continuous groups of words - by doubleClick or mouseDown-drag)
- select line (not problem after 3-rd click)
- delete or copy selected chunks
- paste into selected chunks
- remove / ignore any formatings when paste text

I can do it without problem if there are ASCII characters only. I need some even long runaround script. The problem is no knowledge of unicode text formating in LC as I'm using it with databases, sockets and WebViewer apps mainly.

Do you (or other community LC users also) can see the possibility to help me? I'll try to send "Quick Incident", but sorry if the staff will be ale to help me quick, as this bug for sure is known long time.

Thanks everybody for help in advance,
Marek

Hi Marek,

Perhaps it is better to contact me directly by e-mail and explain once more what you need exactly.

I don't understand what you mean with "if there are ASCII character only". If I use your text like śmióaśw and even ąśźĄŚŻŁ then my script seems to work fine.

I believe that you should be able to just paste text, but obviously this will be a problem is the field is locked. Perhaps you could fake a text cursor with a button that alternates an icon of a text cursor and an empty icon. Unfortunately, this is a lot of work for a bug that shouldn't exist in the first place.

Kind regards,

Mark

Hi Mark,

Yes, your script works very fine, but I cant type the text into field when its lockText property is set to true.

Once more from the beginning, I'd like to have possibility of this field to:
- type into (with unicode characters - like ąśźĄŚŻŁ etc.)
- select chunks (all words or continuous groups of words - by doubleClick or mouseDown-drag)
- select line (not problem if I can do the rest of this points)
- delete or copy selected chunks
- paste into selected chunks (replace or correct them after paste)
- remove or ignore any formatings when paste text from different sources with applied text formats

I don't understand what you mean with "if there are ASCII character only"

I can do it without problem "if there are ASCII characters only" - means that I can do it until there are unicode chars in the text. Even one of chars as "ąśźĄŚŻŁ" in the text makes my script impossible to work correctly (fulfills all 6 rules from points above)

If I use your text like śmióaśw and even ąśźĄŚŻŁ then my script seems to work fine.

Yes, but you can't type into replace selected text because the textLock set to true.

RunRev staff made great job introducing unicode text manipulation in LC5.5. Do you think that this stupid probably small and easy to catch bug should fall down their hard work? If I am on their place I'll make it the highest priority to finnish completely one block of new futures.
This bug makes new text manipulating futures of LiveCode v.5.5 useful in few percent only when using unicode (even UTF-16 native for LC). In my opinion it's worth additional time to finnish such expected futures as unicode conformity. Without that we are still limited to use english language only in our software. As I see it's the only limitation of LC to be perfect for developing of text manipulating software all lover the world (not only english language as now).

I have not your private email address. If you decide to "speak" about it outside of the forum, please feel free to contact me on my mail: [nm at studionm dot pl]

Marek

Marek,

Look at my signature.

Mark

Marek, what version of LiveCode do you use? Unicode text has recently been updated in the engine.

I copied the example word from your post and pasted it into a normal LiveCode field in version 5.5.1. A double-click correctly selects the whole word. I'm not sure if copying from the forum really creates unicode, but the diacriticals didn't interfere with word selection.

Hi Jackue,

I'm using LC 5.5.1 on Mac Os X 10.7.4
It depends from what part of text you double-click (like described in my first post) as well as what text you did copu and paste:
- if "ąśźĄŚŻŁ" - you are right, it's working OK, but there are only unicode chars. it's working like with ASCII chars.
- if "śmióaśw" - you will see what will happen when you double-click the last char "w" or any other. Its working OK only if you double-click before first char "ś".

I think we found that the bug is visible when we try to double-click the word mixed with standard ASCII and any unicode character.

Can you confirm above?

Marek,

I should add something to my previous message, which was very brief due to other duties.

I understand what your problem is. Yes, with normal ASCII characters all works fine, but with unicode characters things may go wrong. I can confirm this on LC 5.0.1. In LC 5.5.x, many things changed under the hood, but I don't think that this affects the way the user can select text with the mouse.

It happens quite often that RunRev introduces great wonderful new features, which are sufficient for the majority of RunRev's customers, but if you really push LiveCode to the edge of its capabilities, you will see that it breaks consistently. Another example of this is drag and drop, which may not work or even crash under very specific circumstances, which RunRev told me they're not going to fix. A professional LiveCode programmer's life is one of running into bugs and creating workarounds. If you like puzzles, then it is a nice way to make a living.

If you're looking for an alternative: RealStudio doesn't have this problem. Unicode text just works in RealStudio (I have tested it with your example). Drag and drop too,although the implementation is slightly more rigid.

Kind regards,

Mark

Marek, I see now. Yes, I can confirm. You'll need a little work-around to accomodate the new unicode text feature. Put this into the field script:

Mark,

I know I must look for workaround and did it few times (I started to learn and play with LC 7 months ago).
The switch to RealStudio is not solution for me. I spent some money and some time with LC, and hope LC will be better and better. I'm not crying because of my problem. I just look for some help and trying some ideas how to solve it by myself in the meantime.

But what brake my optimism is feeling alone who needs unicode text to work correctly with the same futures as ASCII has. If there are more people who need it to develop in LC, the chance to get it should be bigger. You can be right that RunRev is not interested in close subject of unicode, but it's strange for me. There are few times more developers using unicode than ASCII only. It narrows the quantity of RunRev customers dramatically. To make professional UI for your application in your native language customers is be or not to be on your market. It can be the reason that most of programers in my country treats LC as toy for students after first trial. I think there are hundreds of lost customers for RR because of such small "unicode" bugs (but can be wrong).

I'm developing apps for my company mainly, so it's not problem for me to tell my employers that in this app you can't select full word by double-click as in the rest of apps - must use workaround, just drag mouse-down this word to select it. I don't believe if you could sell such application to your customer.

I also don't believe it's big problem for RR developers. This bug is easy to remove as they know the source code perfect as I hope. It's working well for all chars to the right of clicked char. The problem is only for part of word when there is unicode character on the left of clicked one. It should be job for few hours, not few months or even years.

But i believe they are focused on something more important and dreaming about next beta or better 5.5.2 full unicode safe.

Anyway, still looking for unicode bugs workarounds. Thanks in advance to anybody who knows them and like to share their ideas.

Marek

Thanks a lot Jacque. I knew it should be possible with LC. It's visible kind of slow "progress bar" when selecting all the word, but WORKING!

Until now I had no problem to analyze somebody's scripts, but your is the first - I'm wondering where from you took condition and what it means?

Thanks a lot once more Jacque,

Marek

Jacque,

Your solution doesn't work, because it is impossible to select parts of words. With your script, a user can only select entire words but no individual characters or multiple words. It fixes the doubleClick selection but breaks everything else.

Currently, I can't think of any other solution than setting the lockText to true and faking a text cursor.

Kind regards,

Mark