Unicode

classic Classic list List threaded Threaded
47 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Unicode

Peter Haworth
Is there a lesson/guide anywhere that shows how to use unicode in LC 7?

All I need to do is SELECT data from an UTF8 encoded SQLite
database/display it in fields/datagrid and read input from fields/
INSERT/UPDATE it to the database.

I've got things working using unicodeText/uniencode/unidecode in LC 6.6 but
wondering how things work in 7.  Or even if it's worthwhile even using LC 7
for something as simple as this.

The LC7 release notes document all the new properties/commands but don't
have any examples for straightforward use.  Am I right in thinking that I
don't need to use unicodeText/uniencode/unidecode in LC7 to do the above
tasks?  Just simple put into field/put field into var is all I need?

Pete
lcSQL Software <http://www.lcsql.com>
Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Unicode

Peter W A Wood
Pete

LiveCode 7+ stores text data encoded according to UTF-16 so, as I understand, you will need to convert the UTF-8 encoded data using the textEncode function.

Regards

Peter


> On 26 Jan 2015, at 06:45, Peter Haworth <[hidden email]> wrote:
>
> Is there a lesson/guide anywhere that shows how to use unicode in LC 7?
>
> All I need to do is SELECT data from an UTF8 encoded SQLite
> database/display it in fields/datagrid and read input from fields/
> INSERT/UPDATE it to the database.
>
> I've got things working using unicodeText/uniencode/unidecode in LC 6.6 but
> wondering how things work in 7.  Or even if it's worthwhile even using LC 7
> for something as simple as this.
>
> The LC7 release notes document all the new properties/commands but don't
> have any examples for straightforward use.  Am I right in thinking that I
> don't need to use unicodeText/uniencode/unidecode in LC7 to do the above
> tasks?  Just simple put into field/put field into var is all I need?
>
> Pete
> lcSQL Software <http://www.lcsql.com>
> Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
> SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Unicode

Peter Haworth
Thanks Peter.  If that's the case, I'm not seeing much in the way of a
coding advantage over pre 7.0.  Sounds like using textEncode/textDecode
instaed of uniencode/unidecode?

That does answer another question I had though which is what is needed if
the database is UTF-16 encoded.  Sounds like nothing needs to be done.  I
guess I'll have to set up some tests.

Pete
lcSQL Software <http://www.lcsql.com>
Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>

On Sun, Jan 25, 2015 at 5:08 PM, Peter W A Wood <[hidden email]>
wrote:

> Pete
>
> LiveCode 7+ stores text data encoded according to UTF-16 so, as I
> understand, you will need to convert the UTF-8 encoded data using the
> textEncode function.
>
> Regards
>
> Peter
>
>
> > On 26 Jan 2015, at 06:45, Peter Haworth <[hidden email]> wrote:
> >
> > Is there a lesson/guide anywhere that shows how to use unicode in LC 7?
> >
> > All I need to do is SELECT data from an UTF8 encoded SQLite
> > database/display it in fields/datagrid and read input from fields/
> > INSERT/UPDATE it to the database.
> >
> > I've got things working using unicodeText/uniencode/unidecode in LC 6.6
> but
> > wondering how things work in 7.  Or even if it's worthwhile even using
> LC 7
> > for something as simple as this.
> >
> > The LC7 release notes document all the new properties/commands but don't
> > have any examples for straightforward use.  Am I right in thinking that I
> > don't need to use unicodeText/uniencode/unidecode in LC7 to do the above
> > tasks?  Just simple put into field/put field into var is all I need?
> >
> > Pete
> > lcSQL Software <http://www.lcsql.com>
> > Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
> > SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Unicode

Peter W A Wood
Pete

 I think the real coding advantage with Unicode in 7+ comes when processing text.

Personally, I think that it is safer to stick with UTF-8 encoding for external data as it is the only encoding format that you don’t need to worry about processor “endianness”.

Regards

Peter

> On 26 Jan 2015, at 10:15, Peter Haworth <[hidden email]> wrote:
>
> Thanks Peter.  If that's the case, I'm not seeing much in the way of a
> coding advantage over pre 7.0.  Sounds like using textEncode/textDecode
> instaed of uniencode/unidecode?
>
> That does answer another question I had though which is what is needed if
> the database is UTF-16 encoded.  Sounds like nothing needs to be done.  I
> guess I'll have to set up some tests.
>
> Pete
> lcSQL Software <http://www.lcsql.com>
> Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
> SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>
>
> On Sun, Jan 25, 2015 at 5:08 PM, Peter W A Wood <[hidden email]>
> wrote:
>
>> Pete
>>
>> LiveCode 7+ stores text data encoded according to UTF-16 so, as I
>> understand, you will need to convert the UTF-8 encoded data using the
>> textEncode function.
>>
>> Regards
>>
>> Peter
>>
>>
>>> On 26 Jan 2015, at 06:45, Peter Haworth <[hidden email]> wrote:
>>>
>>> Is there a lesson/guide anywhere that shows how to use unicode in LC 7?
>>>
>>> All I need to do is SELECT data from an UTF8 encoded SQLite
>>> database/display it in fields/datagrid and read input from fields/
>>> INSERT/UPDATE it to the database.
>>>
>>> I've got things working using unicodeText/uniencode/unidecode in LC 6.6
>> but
>>> wondering how things work in 7.  Or even if it's worthwhile even using
>> LC 7
>>> for something as simple as this.
>>>
>>> The LC7 release notes document all the new properties/commands but don't
>>> have any examples for straightforward use.  Am I right in thinking that I
>>> don't need to use unicodeText/uniencode/unidecode in LC7 to do the above
>>> tasks?  Just simple put into field/put field into var is all I need?
>>>
>>> Pete
>>> lcSQL Software <http://www.lcsql.com>
>>> Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
>>> SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>
>>> _______________________________________________
>>> use-livecode mailing list
>>> [hidden email]
>>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Unicode

Fraser Gordon-3
In reply to this post by Peter Haworth

On 26 Jan 2015, at 02:15, Peter Haworth <[hidden email]> wrote:

> Thanks Peter.  If that's the case, I'm not seeing much in the way of a
> coding advantage over pre 7.0.  Sounds like using textEncode/textDecode
> instaed of uniencode/unidecode?

Assuming you have UTF-8 encoded data from a source outside LiveCode:

local tUTF8Data — This is binary data
local tString — This is a textual string
put textDecode(tUTF8Data, “UTF-8”) into tString

The important difference is that uniEncode becomes textDecode - because you are decoding some binary data to text.

The big difference between 7.0 and previous versions is that Unicode text works everywhere - you don’t need to use special Unicode properties or commands any more.

>
> That does answer another question I had though which is what is needed if
> the database is UTF-16 encoded.  Sounds like nothing needs to be done.  I
> guess I'll have to set up some tests.

If your external data is UTF-16 you still need to textDecode it - if you don’t, it will treat the data as 8-bit text and you’ll get corrupted text back. This 8-bit default is necessary from a backwards compatibility point of view - if we changed it to accept UTF-16 by default, anyone who gets text from an external source and doesn’t textDecode it will suddenly find that their stacks don’t work.

One way of looking at things is that all external interfaces (files, processes, etc) return binary data and you need to do something to turn that into text (textDecode) and you need to turn your text into binary data when writing to them (textEncode). By using something like UTF-8 as an encoding, it also avoids the problems that occur because the “native” encoding differs between our platforms - it is MacRoman on OSX, CP1252 on Windows and ISO-8859-1 on Linux.

Regards,
Fraser


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Unicode

Devin Asay

On Jan 26, 2015, at 4:42 AM, Fraser Gordon <[hidden email]> wrote:

>
> On 26 Jan 2015, at 02:15, Peter Haworth <[hidden email]> wrote:
>
>> Thanks Peter.  If that's the case, I'm not seeing much in the way of a
>> coding advantage over pre 7.0.  Sounds like using textEncode/textDecode
>> instaed of uniencode/unidecode?
>
> Assuming you have UTF-8 encoded data from a source outside LiveCode:
>
> local tUTF8Data — This is binary data
> local tString — This is a textual string
> put textDecode(tUTF8Data, “UTF-8”) into tString
>
> The important difference is that uniEncode becomes textDecode - because you are decoding some binary data to text.
>
> The big difference between 7.0 and previous versions is that Unicode text works everywhere - you don’t need to use special Unicode properties or commands any more.
>
>>
>> That does answer another question I had though which is what is needed if
>> the database is UTF-16 encoded.  Sounds like nothing needs to be done.  I
>> guess I'll have to set up some tests.
>
> If your external data is UTF-16 you still need to textDecode it - if you don’t, it will treat the data as 8-bit text and you’ll get corrupted text back. This 8-bit default is necessary from a backwards compatibility point of view - if we changed it to accept UTF-16 by default, anyone who gets text from an external source and doesn’t textDecode it will suddenly find that their stacks don’t work.
>
> One way of looking at things is that all external interfaces (files, processes, etc) return binary data and you need to do something to turn that into text (textDecode) and you need to turn your text into binary data when writing to them (textEncode). By using something like UTF-8 as an encoding, it also avoids the problems that occur because the “native” encoding differs between our platforms - it is MacRoman on OSX, CP1252 on Windows and ISO-8859-1 on Linux.
>
> Regards,
> Fraser


It would be great if there were a stack property we could set that would specify what format outputted text would be. The default could be “native”; i.e., the native encoding for the platform, but then we could set it to things like “utf8” or “utf16” or “ISO”. It would essentially do the textEncode/decode for us.

Is this an idea that appeals to folks here?

Devin


Devin Asay
Office of Digital Humanities
Brigham Young University


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Unicode

Peter Haworth
In reply to this post by Fraser Gordon-3
On Mon, Jan 26, 2015 at 3:42 AM, Fraser Gordon <[hidden email]>
wrote:

> One way of looking at things is that all external interfaces (files,
> processes, etc) return binary data and you need to do something to turn
> that into text (textDecode) and you need to turn your text into binary data
> when writing to them (textEncode). By using something like UTF-8 as an
> encoding, it also avoids the problems that occur because the “native”
> encoding differs between our platforms - it is MacRoman on OSX, CP1252 on
> Windows and ISO-8859-1 on Linux.


Thanks Fraser, I like that explanation, plus it answers the next question I
had regarding ISOToMac/MacToISO.

Pete
lcSQL Software <http://www.lcsql.com>
Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Unicode

Peter Haworth
In reply to this post by Devin Asay
Well I guess I spoke too soon :-)  When I said I had things working, I
meant I could successfully get data from a UTF8 database and display it
correctly.

I'm now trying to get input from field controls and get it into the
database.  I found a lorem ipsum generator that would create text in
various languages to I got some Russian text from it and pasted it into an
LC field.

In my handler, I need to put the contents of the field into a variable and
then hand it off from there to an INSERT statement. I've tried every
combination of unicodeText, uniencode, unidecode, or none of the above to
get the correct value into the variable but it either ends up as question
marks or something that looks nothing like the characters in the field.

This is all with pre 7.0.  I think I'm beginning to understand why 7.0 is a
lot better to use than pre 7.0 when heavy unicode handling is needed!

But in the meantime, how should I be handling the above situation in pre
7.0?

Pete
lcSQL Software <http://www.lcsql.com>
Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>

On Mon, Jan 26, 2015 at 9:01 AM, Devin Asay <[hidden email]> wrote:

>
> On Jan 26, 2015, at 4:42 AM, Fraser Gordon <[hidden email]>
> wrote:
>
> >
> > On 26 Jan 2015, at 02:15, Peter Haworth <[hidden email]> wrote:
> >
> >> Thanks Peter.  If that's the case, I'm not seeing much in the way of a
> >> coding advantage over pre 7.0.  Sounds like using textEncode/textDecode
> >> instaed of uniencode/unidecode?
> >
> > Assuming you have UTF-8 encoded data from a source outside LiveCode:
> >
> > local tUTF8Data       — This is binary data
> > local tString         — This is a textual string
> > put textDecode(tUTF8Data, “UTF-8”) into tString
> >
> > The important difference is that uniEncode becomes textDecode - because
> you are decoding some binary data to text.
> >
> > The big difference between 7.0 and previous versions is that Unicode
> text works everywhere - you don’t need to use special Unicode properties or
> commands any more.
> >
> >>
> >> That does answer another question I had though which is what is needed
> if
> >> the database is UTF-16 encoded.  Sounds like nothing needs to be done.
> I
> >> guess I'll have to set up some tests.
> >
> > If your external data is UTF-16 you still need to textDecode it - if you
> don’t, it will treat the data as 8-bit text and you’ll get corrupted text
> back. This 8-bit default is necessary from a backwards compatibility point
> of view - if we changed it to accept UTF-16 by default, anyone who gets
> text from an external source and doesn’t textDecode it will suddenly find
> that their stacks don’t work.
> >
> > One way of looking at things is that all external interfaces (files,
> processes, etc) return binary data and you need to do something to turn
> that into text (textDecode) and you need to turn your text into binary data
> when writing to them (textEncode). By using something like UTF-8 as an
> encoding, it also avoids the problems that occur because the “native”
> encoding differs between our platforms - it is MacRoman on OSX, CP1252 on
> Windows and ISO-8859-1 on Linux.
> >
> > Regards,
> > Fraser
>
>
> It would be great if there were a stack property we could set that would
> specify what format outputted text would be. The default could be “native”;
> i.e., the native encoding for the platform, but then we could set it to
> things like “utf8” or “utf16” or “ISO”. It would essentially do the
> textEncode/decode for us.
>
> Is this an idea that appeals to folks here?
>
> Devin
>
>
> Devin Asay
> Office of Digital Humanities
> Brigham Young University
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Unicode

Devin Asay

On Jan 26, 2015, at 5:35 PM, Peter Haworth <[hidden email]> wrote:

> Well I guess I spoke too soon :-)  When I said I had things working, I
> meant I could successfully get data from a UTF8 database and display it
> correctly.
>
> I'm now trying to get input from field controls and get it into the
> database.  I found a lorem ipsum generator that would create text in
> various languages to I got some Russian text from it and pasted it into an
> LC field.
>
> In my handler, I need to put the contents of the field into a variable and
> then hand it off from there to an INSERT statement. I've tried every
> combination of unicodeText, uniencode, unidecode, or none of the above to
> get the correct value into the variable but it either ends up as question
> marks or something that looks nothing like the characters in the field.
>
> This is all with pre 7.0.  I think I'm beginning to understand why 7.0 is a
> lot better to use than pre 7.0 when heavy unicode handling is needed!
>
> But in the meantime, how should I be handling the above situation in pre
> 7.0?
>

Pete,

I’ve done this a lot pre-7. Here’s the relevant bit of code:

  put unidecode(the unicodeText of line 1 of fld “russStuff","utf8") into tRussTxt

At that point, since the text in tRussTxt is expressed in plain ASCII you can just INSERT it or UPDATE your database. To get it out again you reverse the process:

  set the unicodeText of fld “russStuff” to uniencode(tRussFldFromDB,”utf8”)

LC 7 of course simplifies this process, but you still have to textEncode/textDecode the text as you’re outputting/inputting it.

  put textEncode(the text of fld “russStuff”,”utf8”) into tRussTxt # prep for DB
 
  put textDecode(tRussFldFromDB,”utf8”) into fld “russStuff”  # display text from DB

HTH

Devin


Devin Asay
Office of Digital Humanities
Brigham Young University


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Unicode

Devin Asay
In reply to this post by Devin Asay

On Jan 26, 2015, at 10:01 AM, Devin Asay <[hidden email]> wrote:

> It would be great if there were a stack property we could set that would specify what format outputted text would be. The default could be “native”; i.e., the native encoding for the platform, but then we could set it to things like “utf8” or “utf16” or “ISO”. It would essentially do the textEncode/decode for us.
>
> Is this an idea that appeals to folks here?

Of course, then I discovered that this property already exists! A global property called outputTextEncoding. But it is limited to output from Server. It would be nice to see that extended to all LC editions.

Devin


Devin Asay
Office of Digital Humanities
Brigham Young University


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Set Script Limits in Standalones

Ray Horsley-2
In reply to this post by Devin Asay
As I recall there's a limit to the number of lines in a script which is
set in a standalone.  I thought it was 16 lines.  This limitation, if it
still exists, is not documented in the dictionary.  Does anybody know
what it is or if it got removed with the advent of the community edition?

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Set Script Limits in Standalones

Bob Sneidar-2
I think the 16 line limit was for in line compilation, as in creating a list of commands and executing them with a do command. I do not think it means that every script in a standalone is limited to 16 lines, and I believe that limit has been removed anyway, or else greatly increased.

Bob S


> On Jan 27, 2015, at 07:56 , Ray <[hidden email]> wrote:
>
> As I recall there's a limit to the number of lines in a script which is set in a standalone.  I thought it was 16 lines.  This limitation, if it still exists, is not documented in the dictionary.  Does anybody know what it is or if it got removed with the advent of the community edition?
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Set Script Limits in Standalones

Richard Gaskin
Bob Sneidar wrote:

 >> On Jan 27, 2015, at 07:56 , Ray <ray at linkit.com> wrote:
 >>
 >> As I recall there's a limit to the number of lines in a script
 >> which is set in a standalone.  I thought it was 16 lines.  This
 >> limitation, if it still exists, is not documented in the
 >> dictionary.  Does anybody know what it is or if it got removed
 >> with the advent of the community edition?
 >
 > I think the 16 line limit was for in line compilation, as in creating
 > a list of commands and executing them with a do command. I do not
 > think it means that every script in a standalone is limited to 16
 > lines, and I believe that limit has been removed anyway, or else
 > greatly increased.

The scriptLimits global property was originally invented to allow
MetaCard to deliver a demo version with no time limit.  The limits were:

   10 executable statements with "do", "value" or "set the script of...."
   10 frontScripts
   10 backScripts
   50 libraries

Some were able to deliver complete working apps within those limits, but
Dr. Raney felt it was still a good balance because sooner or later
they'd get tired of the workarounds for such things and just get a license.

Since the concept of having arbitrary limits on utility for licensing
purposes is incompatible with the GPL, the scriptLimits property was
removed from the Community Edition on first release of that version (6.0
if memory serves).

After review, it was also removed from the Commercial edition as of v6.7
- here's the bug report on that, with Mark Waddingham's comment:

<http://quality.runrev.com/show_bug.cgi?id=11797>

     Having considered this for a while and based on feedback
     from yourselves and others I can confirm that we will be
     removing the scriptLimits from commercial in 6.7 onwards
     (and thus 7.0). This change should take effect in the next
     build after 6.7-dp-6 / 7.0-dp-8.


This is consistent with the design mandate of the two editions now that
LiveCode is open source, in which if there are any differences at all
they favor the Commercial so it represents a superset of Community features.

That said, RunRev is sincere about their commitment to open source, so
Community is not "crippleware" at all:  both engines have complete
feature parity across the board, with the only exceptions being
Commercial features which may be incompatible with the GPL.  Currently
these are limited to Oracle database connectivity (since Oracle's
drivers are closed-source), and password-protected stacks (since
concealing source is incompatible with the GPL's mandate for free and
open sharing).

--
  Richard Gaskin
  LiveCode Community Manager
  [hidden email]


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Set Script Limits in Standalones

Ray Horsley-2
In reply to this post by Bob Sneidar-2
Thanks Bob.  What I'm actually doing is executing something like 'set
the script of button myButton to myScript' where myScript is greater
than 16 lines.  Historically this has worked in the IDE but fails in the
standalone because of the limitation.

On 1/27/2015 1:21 PM, Bob Sneidar wrote:

> I think the 16 line limit was for in line compilation, as in creating a list of commands and executing them with a do command. I do not think it means that every script in a standalone is limited to 16 lines, and I believe that limit has been removed anyway, or else greatly increased.
>
> Bob S
>
>
>> On Jan 27, 2015, at 07:56 , Ray <[hidden email]> wrote:
>>
>> As I recall there's a limit to the number of lines in a script which is set in a standalone.  I thought it was 16 lines.  This limitation, if it still exists, is not documented in the dictionary.  Does anybody know what it is or if it got removed with the advent of the community edition?
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Set Script Limits in Standalones

Ray Horsley-2
In reply to this post by Richard Gaskin
Richard - your post just came in and thanks for this clarification. It's
alos good news all the way around.

"Raney"  Now there's a name I haven't heard in a long time.  I didn't
know Scott had a doctoral degree and I hope he was never offended that I
didn't address him with this title.  I wonder what he's doing these days?

On 1/27/2015 2:01 PM, Richard Gaskin wrote:

> Bob Sneidar wrote:
>
> >> On Jan 27, 2015, at 07:56 , Ray <ray at linkit.com> wrote:
> >>
> >> As I recall there's a limit to the number of lines in a script
> >> which is set in a standalone.  I thought it was 16 lines.  This
> >> limitation, if it still exists, is not documented in the
> >> dictionary.  Does anybody know what it is or if it got removed
> >> with the advent of the community edition?
> >
> > I think the 16 line limit was for in line compilation, as in creating
> > a list of commands and executing them with a do command. I do not
> > think it means that every script in a standalone is limited to 16
> > lines, and I believe that limit has been removed anyway, or else
> > greatly increased.
>
> The scriptLimits global property was originally invented to allow
> MetaCard to deliver a demo version with no time limit.  The limits were:
>
>   10 executable statements with "do", "value" or "set the script of...."
>   10 frontScripts
>   10 backScripts
>   50 libraries
>
> Some were able to deliver complete working apps within those limits,
> but Dr. Raney felt it was still a good balance because sooner or later
> they'd get tired of the workarounds for such things and just get a
> license.
>
> Since the concept of having arbitrary limits on utility for licensing
> purposes is incompatible with the GPL, the scriptLimits property was
> removed from the Community Edition on first release of that version
> (6.0 if memory serves).
>
> After review, it was also removed from the Commercial edition as of
> v6.7 - here's the bug report on that, with Mark Waddingham's comment:
>
> <http://quality.runrev.com/show_bug.cgi?id=11797>
>
>     Having considered this for a while and based on feedback
>     from yourselves and others I can confirm that we will be
>     removing the scriptLimits from commercial in 6.7 onwards
>     (and thus 7.0). This change should take effect in the next
>     build after 6.7-dp-6 / 7.0-dp-8.
>
>
> This is consistent with the design mandate of the two editions now
> that LiveCode is open source, in which if there are any differences at
> all they favor the Commercial so it represents a superset of Community
> features.
>
> That said, RunRev is sincere about their commitment to open source, so
> Community is not "crippleware" at all:  both engines have complete
> feature parity across the board, with the only exceptions being
> Commercial features which may be incompatible with the GPL.  Currently
> these are limited to Oracle database connectivity (since Oracle's
> drivers are closed-source), and password-protected stacks (since
> concealing source is incompatible with the GPL's mandate for free and
> open sharing).
>


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Unicode

Peter Haworth
In reply to this post by Devin Asay
Hi Devin,
That works perfectly in pre 7 and 7, thanks a lot.

It's somewhat of a pain to deal with this when putting data into a datagrid
since it requires a custom column behavior to format the data correctly.  I
haven't tried editing a datagrid cell with unicode in it yet, but I'm
guessing that will require some custom coding too.

It seems like there should be a datagrid column property by now that
indicates whether translation to/from unicode is required, especially in 7
since that's its focus.  Similar to your idea of a stack property I guess.

I did find one other motivation to move to 7.0 for unicode.  It seems you
can't copy/paste a unicode string into the pre 7 script editor, you just
end up with question marks.  In 7, it pastes correctly.

Pete
lcSQL Software <http://www.lcsql.com>
Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>

On Tue, Jan 27, 2015 at 7:50 AM, Devin Asay <[hidden email]> wrote:

>
> On Jan 26, 2015, at 5:35 PM, Peter Haworth <[hidden email]> wrote:
>
> > Well I guess I spoke too soon :-)  When I said I had things working, I
> > meant I could successfully get data from a UTF8 database and display it
> > correctly.
> >
> > I'm now trying to get input from field controls and get it into the
> > database.  I found a lorem ipsum generator that would create text in
> > various languages to I got some Russian text from it and pasted it into
> an
> > LC field.
> >
> > In my handler, I need to put the contents of the field into a variable
> and
> > then hand it off from there to an INSERT statement. I've tried every
> > combination of unicodeText, uniencode, unidecode, or none of the above to
> > get the correct value into the variable but it either ends up as question
> > marks or something that looks nothing like the characters in the field.
> >
> > This is all with pre 7.0.  I think I'm beginning to understand why 7.0
> is a
> > lot better to use than pre 7.0 when heavy unicode handling is needed!
> >
> > But in the meantime, how should I be handling the above situation in pre
> > 7.0?
> >
>
> Pete,
>
> I’ve done this a lot pre-7. Here’s the relevant bit of code:
>
>   put unidecode(the unicodeText of line 1 of fld “russStuff","utf8") into
> tRussTxt
>
> At that point, since the text in tRussTxt is expressed in plain ASCII you
> can just INSERT it or UPDATE your database. To get it out again you reverse
> the process:
>
>   set the unicodeText of fld “russStuff” to
> uniencode(tRussFldFromDB,”utf8”)
>
> LC 7 of course simplifies this process, but you still have to
> textEncode/textDecode the text as you’re outputting/inputting it.
>
>   put textEncode(the text of fld “russStuff”,”utf8”) into tRussTxt # prep
> for DB
>
>   put textDecode(tRussFldFromDB,”utf8”) into fld “russStuff”  # display
> text from DB
>
> HTH
>
> Devin
>
>
> Devin Asay
> Office of Digital Humanities
> Brigham Young University
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Set Script Limits in Standalones

Richard Gaskin
In reply to this post by Ray Horsley-2
Ray wrote:

 > What I'm actually doing is executing something like 'set the
 > script of button myButton to myScript' where myScript is greater
 > than 16 lines.  Historically this has worked in the IDE but
 > fails in the standalone because of the limitation.

That should be possible now, but tread carefully:  self-modifying
scripts are difficult to debug.

Would behaviors provide a simpler and possibly more efficient solution
for what you need?


 > "Raney"  Now there's a name I haven't heard in a long time.  I
 > didn't know Scott had a doctoral degree and I hope he was never
 > offended that I didn't address him with this title.  I wonder
 > what he's doing these days?

For a few years following the acquisition of MetaCard by RunRev he was
sailing the Caribbean.  Last I heard he's stateside again, and beginning
to get back into programming after enjoying his long break.

--
  Richard Gaskin
  LiveCode Community Manager
  [hidden email]


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Set Script Limits in Standalones

Ray Horsley-2
Richard that is really great that Scott took some time to pursue what
sounds like a really cool dream.

Now, back to business :)  I've never used behaviors much which is really
bad on my part.  I think I'll look into them.  Thanks for the suggestion.

On 1/27/2015 4:02 PM, Richard Gaskin wrote:

> Ray wrote:
>
> > What I'm actually doing is executing something like 'set the
> > script of button myButton to myScript' where myScript is greater
> > than 16 lines.  Historically this has worked in the IDE but
> > fails in the standalone because of the limitation.
>
> That should be possible now, but tread carefully:  self-modifying
> scripts are difficult to debug.
>
> Would behaviors provide a simpler and possibly more efficient solution
> for what you need?
>
>
> > "Raney"  Now there's a name I haven't heard in a long time. I
> > didn't know Scott had a doctoral degree and I hope he was never
> > offended that I didn't address him with this title.  I wonder
> > what he's doing these days?
>
> For a few years following the acquisition of MetaCard by RunRev he was
> sailing the Caribbean.  Last I heard he's stateside again, and
> beginning to get back into programming after enjoying his long break.
>


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Unicode

Peter Haworth
In reply to this post by Devin Asay
Another quick question Devin.  Pre 7, you have to address the unicodeText
property of an object to do this.

]If I have a variable/custom property whose contents are unidecoded, how
can I uniencode it into another variable since it has no unicodeText
property?  Seems like I would need a hidden filed to act as an intermediary.

Maybe I just need to bite the bullet and use LC 7 for this project since it
doesn't need to address the unicodeText property.  This for making my
SQLiteAdmin program unicode capable.

Pete
lcSQL Software <http://www.lcsql.com>
Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>

On Tue, Jan 27, 2015 at 7:50 AM, Devin Asay <[hidden email]> wrote:

>
> On Jan 26, 2015, at 5:35 PM, Peter Haworth <[hidden email]> wrote:
>
> > Well I guess I spoke too soon :-)  When I said I had things working, I
> > meant I could successfully get data from a UTF8 database and display it
> > correctly.
> >
> > I'm now trying to get input from field controls and get it into the
> > database.  I found a lorem ipsum generator that would create text in
> > various languages to I got some Russian text from it and pasted it into
> an
> > LC field.
> >
> > In my handler, I need to put the contents of the field into a variable
> and
> > then hand it off from there to an INSERT statement. I've tried every
> > combination of unicodeText, uniencode, unidecode, or none of the above to
> > get the correct value into the variable but it either ends up as question
> > marks or something that looks nothing like the characters in the field.
> >
> > This is all with pre 7.0.  I think I'm beginning to understand why 7.0
> is a
> > lot better to use than pre 7.0 when heavy unicode handling is needed!
> >
> > But in the meantime, how should I be handling the above situation in pre
> > 7.0?
> >
>
> Pete,
>
> I’ve done this a lot pre-7. Here’s the relevant bit of code:
>
>   put unidecode(the unicodeText of line 1 of fld “russStuff","utf8") into
> tRussTxt
>
> At that point, since the text in tRussTxt is expressed in plain ASCII you
> can just INSERT it or UPDATE your database. To get it out again you reverse
> the process:
>
>   set the unicodeText of fld “russStuff” to
> uniencode(tRussFldFromDB,”utf8”)
>
> LC 7 of course simplifies this process, but you still have to
> textEncode/textDecode the text as you’re outputting/inputting it.
>
>   put textEncode(the text of fld “russStuff”,”utf8”) into tRussTxt # prep
> for DB
>
>   put textDecode(tRussFldFromDB,”utf8”) into fld “russStuff”  # display
> text from DB
>
> HTH
>
> Devin
>
>
> Devin Asay
> Office of Digital Humanities
> Brigham Young University
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Unicode

Devin Asay

On Jan 27, 2015, at 2:03 PM, Peter Haworth <[hidden email]> wrote:

> Another quick question Devin.  Pre 7, you have to address the unicodeText
> property of an object to do this.
>
> ]If I have a variable/custom property whose contents are unidecoded, how
> can I uniencode it into another variable since it has no unicodeText
> property?  Seems like I would need a hidden filed to act as an intermediary.
>
> Maybe I just need to bite the bullet and use LC 7 for this project since it
> doesn't need to address the unicodeText property.  This for making my
> SQLiteAdmin program unicode capable.
>

The way I ended up handling this most of the time in pre-7 was to store the unicode text in a custom property of the object, either as UTF-8 encoded text, or as HTML text. Neither of those approaches suffers from problems with endianness. It is true that for these approaches you often need to process the text through an intermediary text field.

LC 7 really is a wonder in terms of how seamless it has made using Unicode in the interface. It came with the slight cost of making text I/O a bit more complicated.

devin


Devin Asay
Office of Digital Humanities
Brigham Young University


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
123