Re: 9.5 on Windows seems terribly unable to deal with fields full of text?

[J. Landman Gay via use-livecode]

On 9/9/19 9:57 PM, Geoff Canyon via use-livecode wrote:

I’ve now modified my stacks to include a closecard handler to clear the large 
field’s content when exiting.

Stack is now much faster to work with and save — far out of proportion to the 
size savings.



I noticed something similar today on the Mac. I was testing a function 
that returned 1.3MB of data to the message box. I edited the script and 
it was like typing in molasses. When I deleted the text I'd left sitting 
in the message box everything kicked back up to normal speed.



--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Merge and unicode

[dsc--- via use-livecode]

I think I'm doing this wrong. This seems to work, too.

on mouseup
   put empty into field 1
   put numToCodepoint(0x2200) into x 
   put numToCodepoint(0x1040F) & "V-" into y
   put merge(" é{ [[x]] }é [[y]]") into field 1
end mouseup


> On Sep 9, 2019, at 10:25 PM, dsc--- via use-livecode 
>  wrote:
> 
> And this, too, looks OK to me.
> 
> on mouseup
>   put empty into field 1
>   put "A" into field 1
>   get numToCodepoint(0x2200) & numToCodepoint(0x1040F) & "V-"
>   set the metadata of char 1 of field 1 to it
>   put the metadata of char 1 of field 1 after field 1
> end mouseup
> 
> I guess the problem is in the merge as you thought.
> 
> I did notice in the dictionary that setting the metadata of a line is not the 
> same as setting the metadata of all of the characters of the line.
> 
> Dar Scott
> 
> 
>> On Sep 9, 2019, at 8:58 PM, Dar Scott Consulting via use-livecode 
>>  wrote:
>> 
>> This quick check seems to work for me.
>> 
>> on mouseup
>> 
>> put "A" into field 1
>> 
>> set the metadata of char 1 of field 1 to "é"
>> 
>> put the metadata of char 1 of field 1 after field 1
>> 
>> end mouseup
>> 
>> 
>>> On Sep 9, 2019, at 8:32 PM, J. Landman Gay via use-livecode 
>>>  wrote:
>>> 
>>> Well, I've made some changes to the code since I started urlEncoding the 
>>> text before merging so I'll check that again. Paul is right that unicode in 
>>> htmltext needs to be in hex, but the numbers I'm getting back are very high 
>>> (8,000+) and render in the field as strange pictographs. Elsewhere where 
>>> there is no merge, curly quotes translate to the named quote or apostrophe 
>>> entities and are correct.
>>> 
>>> By metadata I mean the LC term (see the dictionary) that allows you to 
>>> attach some text to a field text chunk. The metadata isn't displayed in the 
>>> field but you can use it for anything you want. In my case the field is a 
>>> list of clickable entries in a table of contents, each with its own 
>>> metadata attached that provides a path to the stack and card the entry 
>>> needs to open.
>>> 
>>> When I use normal LC text as metadata, diacriticals aren't rendered 
>>> correctly (curly quotes become question marks,) the path is therefore 
>>> incorrect and the click goes nowhere.
>>> 
>>> Since LC is supposed to be unicode throughout, I'd expect metadata to be 
>>> compatible. The same text appears correctly when not used as metadata.
>>> --
>>> Jacqueline Landman Gay | jac...@hyperactivesw.com
>>> HyperActive Software | http://www.hyperactivesw.com
>>> On September 9, 2019 7:25:28 PM Dar Scott Consulting via use-livecode 
>>>  wrote:
>>> 
 I think you are trying to think too much about the LC implementation of 
 text. Maybe.
 
 Text in LC is an abstraction of a sequence of code points. Whether it is 
 UTF16 or not is hidden to me. (mostly)
 
 So,
 
 get textDecode( binaryFromServer, "UTF-8" )
 
 should put that into the correct form, if it is really UTF-8.
 
 A data (binary bytes) is interpreted as native encoding if one tries to 
 use it as text. I recommend against this. I try to always textDecode() 
 everything coming in, but I make exceptions at times for ASCII.
 
 I'm not sure what you mean by metadata. Are you referring to HTTP 
 content-type?
 
 Sorry, if I am off on a bunny trail...
 
 Dar
 
> On Sep 9, 2019, at 4:38 PM, J. Landman Gay via use-livecode 
>  wrote:
> 
> It's UTF8 text from a server, which I textDecode to UTF16. When I use the 
> UTF16 text in a merge, diacriticals and/or curly quotes get mangled. 
> (Same with setting metadata on field text too.)
> 
> On 9/9/19 4:16 PM, Dar Scott Consulting via use-livecode wrote:
>> I'm not sure I understand.
>> Do you mean "encoded to UTF-16"? In that case you should decode that to 
>> convert it to internal text. And then try merge. (Which still might have 
>> problems, I suppose.)
>>> On Sep 9, 2019, at 12:08 PM, J. Landman Gay via use-livecode 
>>>  wrote:
>>> 
>>> 
>>> It seems that the merge command doesn't respect unicode. Does anyone 
>>> have a workaround? The text I'm inserting is already decoded to UTF16.
>>> 
>>> 
>>> --
>>> Jacqueline Landman Gay | jac...@hyperactivesw.com
>>> HyperActive Software   | http://www.hyperactivesw.com
>>> 
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your 
>> subscription preferences:
>> http://lists.runrev.com/mailman/li

Re: Merge and unicode

[dsc--- via use-livecode]

And this, too, looks OK to me.

on mouseup
   put empty into field 1
   put "A" into field 1
   get numToCodepoint(0x2200) & numToCodepoint(0x1040F) & "V-"
   set the metadata of char 1 of field 1 to it
   put the metadata of char 1 of field 1 after field 1
end mouseup

I guess the problem is in the merge as you thought.

I did notice in the dictionary that setting the metadata of a line is not the 
same as setting the metadata of all of the characters of the line.

Dar Scott


> On Sep 9, 2019, at 8:58 PM, Dar Scott Consulting via use-livecode 
>  wrote:
> 
> This quick check seems to work for me.
> 
> on mouseup
> 
> put "A" into field 1
> 
> set the metadata of char 1 of field 1 to "é"
> 
> put the metadata of char 1 of field 1 after field 1
> 
> end mouseup
> 
> 
>> On Sep 9, 2019, at 8:32 PM, J. Landman Gay via use-livecode 
>>  wrote:
>> 
>> Well, I've made some changes to the code since I started urlEncoding the 
>> text before merging so I'll check that again. Paul is right that unicode in 
>> htmltext needs to be in hex, but the numbers I'm getting back are very high 
>> (8,000+) and render in the field as strange pictographs. Elsewhere where 
>> there is no merge, curly quotes translate to the named quote or apostrophe 
>> entities and are correct.
>> 
>> By metadata I mean the LC term (see the dictionary) that allows you to 
>> attach some text to a field text chunk. The metadata isn't displayed in the 
>> field but you can use it for anything you want. In my case the field is a 
>> list of clickable entries in a table of contents, each with its own metadata 
>> attached that provides a path to the stack and card the entry needs to open.
>> 
>> When I use normal LC text as metadata, diacriticals aren't rendered 
>> correctly (curly quotes become question marks,) the path is therefore 
>> incorrect and the click goes nowhere.
>> 
>> Since LC is supposed to be unicode throughout, I'd expect metadata to be 
>> compatible. The same text appears correctly when not used as metadata.
>> --
>> Jacqueline Landman Gay | jac...@hyperactivesw.com
>> HyperActive Software | http://www.hyperactivesw.com
>> On September 9, 2019 7:25:28 PM Dar Scott Consulting via use-livecode 
>>  wrote:
>> 
>>> I think you are trying to think too much about the LC implementation of 
>>> text. Maybe.
>>> 
>>> Text in LC is an abstraction of a sequence of code points. Whether it is 
>>> UTF16 or not is hidden to me. (mostly)
>>> 
>>> So,
>>> 
>>> get textDecode( binaryFromServer, "UTF-8" )
>>> 
>>> should put that into the correct form, if it is really UTF-8.
>>> 
>>> A data (binary bytes) is interpreted as native encoding if one tries to use 
>>> it as text. I recommend against this. I try to always textDecode() 
>>> everything coming in, but I make exceptions at times for ASCII.
>>> 
>>> I'm not sure what you mean by metadata. Are you referring to HTTP 
>>> content-type?
>>> 
>>> Sorry, if I am off on a bunny trail...
>>> 
>>> Dar
>>> 
 On Sep 9, 2019, at 4:38 PM, J. Landman Gay via use-livecode 
  wrote:
 
 It's UTF8 text from a server, which I textDecode to UTF16. When I use the 
 UTF16 text in a merge, diacriticals and/or curly quotes get mangled. (Same 
 with setting metadata on field text too.)
 
 On 9/9/19 4:16 PM, Dar Scott Consulting via use-livecode wrote:
> I'm not sure I understand.
> Do you mean "encoded to UTF-16"? In that case you should decode that to 
> convert it to internal text. And then try merge. (Which still might have 
> problems, I suppose.)
>> On Sep 9, 2019, at 12:08 PM, J. Landman Gay via use-livecode 
>>  wrote:
>> 
>> 
>> It seems that the merge command doesn't respect unicode. Does anyone 
>> have a workaround? The text I'm inserting is already decoded to UTF16.
>> 
>> 
>> --
>> Jacqueline Landman Gay | jac...@hyperactivesw.com
>> HyperActive Software   | http://www.hyperactivesw.com
>> 
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your 
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
 
 
 --
 Jacqueline Landman Gay | jac...@hyperactivesw.com
 HyperActive Software   | http://www.hyperactivesw.com
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your 
 subscription preferences:
 http://lists.runrev.com/mailman/listin

Re: Merge and unicode

[Dar Scott Consulting via use-livecode]

This quick check seems to work for me.

on mouseup

put "A" into field 1

set the metadata of char 1 of field 1 to "é"

put the metadata of char 1 of field 1 after field 1

end mouseup


> On Sep 9, 2019, at 8:32 PM, J. Landman Gay via use-livecode 
>  wrote:
> 
> Well, I've made some changes to the code since I started urlEncoding the text 
> before merging so I'll check that again. Paul is right that unicode in 
> htmltext needs to be in hex, but the numbers I'm getting back are very high 
> (8,000+) and render in the field as strange pictographs. Elsewhere where 
> there is no merge, curly quotes translate to the named quote or apostrophe 
> entities and are correct.
> 
> By metadata I mean the LC term (see the dictionary) that allows you to attach 
> some text to a field text chunk. The metadata isn't displayed in the field 
> but you can use it for anything you want. In my case the field is a list of 
> clickable entries in a table of contents, each with its own metadata attached 
> that provides a path to the stack and card the entry needs to open.
> 
> When I use normal LC text as metadata, diacriticals aren't rendered correctly 
> (curly quotes become question marks,) the path is therefore incorrect and the 
> click goes nowhere.
> 
> Since LC is supposed to be unicode throughout, I'd expect metadata to be 
> compatible. The same text appears correctly when not used as metadata.
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com
> On September 9, 2019 7:25:28 PM Dar Scott Consulting via use-livecode 
>  wrote:
> 
>> I think you are trying to think too much about the LC implementation of 
>> text. Maybe.
>> 
>> Text in LC is an abstraction of a sequence of code points. Whether it is 
>> UTF16 or not is hidden to me. (mostly)
>> 
>> So,
>> 
>> get textDecode( binaryFromServer, "UTF-8" )
>> 
>> should put that into the correct form, if it is really UTF-8.
>> 
>> A data (binary bytes) is interpreted as native encoding if one tries to use 
>> it as text. I recommend against this. I try to always textDecode() 
>> everything coming in, but I make exceptions at times for ASCII.
>> 
>> I'm not sure what you mean by metadata. Are you referring to HTTP 
>> content-type?
>> 
>> Sorry, if I am off on a bunny trail...
>> 
>> Dar
>> 
>>> On Sep 9, 2019, at 4:38 PM, J. Landman Gay via use-livecode 
>>>  wrote:
>>> 
>>> It's UTF8 text from a server, which I textDecode to UTF16. When I use the 
>>> UTF16 text in a merge, diacriticals and/or curly quotes get mangled. (Same 
>>> with setting metadata on field text too.)
>>> 
>>> On 9/9/19 4:16 PM, Dar Scott Consulting via use-livecode wrote:
 I'm not sure I understand.
 Do you mean "encoded to UTF-16"? In that case you should decode that to 
 convert it to internal text. And then try merge. (Which still might have 
 problems, I suppose.)
> On Sep 9, 2019, at 12:08 PM, J. Landman Gay via use-livecode 
>  wrote:
> 
> 
> It seems that the merge command doesn't respect unicode. Does anyone have 
> a workaround? The text I'm inserting is already decoded to UTF16.
> 
> 
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your 
 subscription preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode
>>> 
>>> 
>>> --
>>> Jacqueline Landman Gay | jac...@hyperactivesw.com
>>> HyperActive Software   | http://www.hyperactivesw.com
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url 

Re: 9.5 on Windows seems terribly unable to deal with fields full of text?

[Geoff Canyon via use-livecode]

I’ve now modified my stacks to include a closecard handler to clear the large 
field’s content when exiting. 

Stack is now much faster to work with and save — far out of proportion to the 
size savings. 
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Merge and unicode

[J. Landman Gay via use-livecode]

Well, I've made some changes to the code since I started urlEncoding the 
text before merging so I'll check that again. Paul is right that unicode in 
htmltext needs to be in hex, but the numbers I'm getting back are very high 
(8,000+) and render in the field as strange pictographs. Elsewhere where 
there is no merge, curly quotes translate to the named quote or apostrophe 
entities and are correct.


By metadata I mean the LC term (see the dictionary) that allows you to 
attach some text to a field text chunk. The metadata isn't displayed in the 
field but you can use it for anything you want. In my case the field is a 
list of clickable entries in a table of contents, each with its own 
metadata attached that provides a path to the stack and card the entry 
needs to open.


When I use normal LC text as metadata, diacriticals aren't rendered 
correctly (curly quotes become question marks,) the path is therefore 
incorrect and the click goes nowhere.


Since LC is supposed to be unicode throughout, I'd expect metadata to be 
compatible. The same text appears correctly when not used as metadata.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On September 9, 2019 7:25:28 PM Dar Scott Consulting via use-livecode 
 wrote:


I think you are trying to think too much about the LC implementation of 
text. Maybe.


Text in LC is an abstraction of a sequence of code points. Whether it is 
UTF16 or not is hidden to me. (mostly)


So,

get textDecode( binaryFromServer, "UTF-8" )

should put that into the correct form, if it is really UTF-8.

A data (binary bytes) is interpreted as native encoding if one tries to use 
it as text. I recommend against this. I try to always textDecode() 
everything coming in, but I make exceptions at times for ASCII.


I'm not sure what you mean by metadata. Are you referring to HTTP content-type?

Sorry, if I am off on a bunny trail...

Dar

On Sep 9, 2019, at 4:38 PM, J. Landman Gay via use-livecode 
 wrote:


It's UTF8 text from a server, which I textDecode to UTF16. When I use the 
UTF16 text in a merge, diacriticals and/or curly quotes get mangled. (Same 
with setting metadata on field text too.)


On 9/9/19 4:16 PM, Dar Scott Consulting via use-livecode wrote:

I'm not sure I understand.
Do you mean "encoded to UTF-16"? In that case you should decode that to 
convert it to internal text. And then try merge. (Which still might have 
problems, I suppose.)
On Sep 9, 2019, at 12:08 PM, J. Landman Gay via use-livecode 
 wrote:



It seems that the merge command doesn't respect unicode. Does anyone have a 
workaround? The text I'm inserting is already decoded to UTF16.



--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode



--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode





___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Merge and unicode

[Dar Scott Consulting via use-livecode]

I think you are trying to think too much about the LC implementation of text. 
Maybe.

Text in LC is an abstraction of a sequence of code points. Whether it is UTF16 
or not is hidden to me. (mostly) 

So,

get textDecode( binaryFromServer, "UTF-8" )

should put that into the correct form, if it is really UTF-8.

A data (binary bytes) is interpreted as native encoding if one tries to use it 
as text. I recommend against this. I try to always textDecode() everything 
coming in, but I make exceptions at times for ASCII. 

I'm not sure what you mean by metadata. Are you referring to HTTP content-type?

Sorry, if I am off on a bunny trail...

Dar

> On Sep 9, 2019, at 4:38 PM, J. Landman Gay via use-livecode 
>  wrote:
> 
> It's UTF8 text from a server, which I textDecode to UTF16. When I use the 
> UTF16 text in a merge, diacriticals and/or curly quotes get mangled. (Same 
> with setting metadata on field text too.)
> 
> On 9/9/19 4:16 PM, Dar Scott Consulting via use-livecode wrote:
>> I'm not sure I understand.
>> Do you mean "encoded to UTF-16"? In that case you should decode that to 
>> convert it to internal text. And then try merge. (Which still might have 
>> problems, I suppose.)
>>> On Sep 9, 2019, at 12:08 PM, J. Landman Gay via use-livecode 
>>>  wrote:
>>> 
>>> It seems that the merge command doesn't respect unicode. Does anyone have a 
>>> workaround? The text I'm inserting is already decoded to UTF16.
>>> 
>>> -- 
>>> Jacqueline Landman Gay | jac...@hyperactivesw.com
>>> HyperActive Software   | http://www.hyperactivesw.com
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> -- 
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Merge and unicode

[Paul Dupuis via use-livecode]

Doesn't any Unicode in htmlText of a field need to be in HTML form (i.e. 
#;?


I thought htmlText turns any non ASCII into either hex encoded html or, 
where html entity names exists, uses html entity names.



On 9/9/2019 6:35 PM, J. Landman Gay via use-livecode wrote:

On 9/9/19 2:39 PM, Paul Dupuis via use-livecode wrote:

On 9/9/2019 2:13 PM, J. Landman Gay via use-livecode wrote:

On 9/9/19 1:08 PM, J. Landman Gay via use-livecode wrote:
It seems that the merge command doesn't respect unicode. Does 
anyone have a workaround? The text I'm inserting is already decoded 
to UTF16.




I misspoke, sorry. It's the metadata that doesn't respect unicode.



Can you clarify what you mean when you say the "metadata" doesn't 
respect Unicode?


I'm in the middle of a big Unicode problem and have found and 
reported a ton of bugs where Unicode is not yet everywhere. I'm 
keenly interested in any I don't know about.


Actually I just double-checked and both merge and metadata may be wrong.

I get UTF8 text from a server that is then textDecoded to UTF16, and 
an html template that I merge with parts of the UTF16 text. In the 
variable watcher, the merged template looks correct but when a field 
is set to the htmltext the result is wrong, diacriticals and curly 
quotes are question marks. My solution for that was to urlEncode the 
content before merging, and urlDecoding when extracting it for 
display. That works.


In another part of the app I use the same (UTF16) text to set the 
metadata of a line in a field. When the script gets the metadata 
later, diacriticals and curly quotes are strange characters with very 
high UTF numbers.





___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Merge and unicode

[J. Landman Gay via use-livecode]

It's UTF8 text from a server, which I textDecode to UTF16. When I use 
the UTF16 text in a merge, diacriticals and/or curly quotes get mangled. 
(Same with setting metadata on field text too.)


On 9/9/19 4:16 PM, Dar Scott Consulting via use-livecode wrote:

I'm not sure I understand.

Do you mean "encoded to UTF-16"? In that case you should decode that to convert 
it to internal text. And then try merge. (Which still might have problems, I suppose.)



On Sep 9, 2019, at 12:08 PM, J. Landman Gay via use-livecode 
 wrote:

It seems that the merge command doesn't respect unicode. Does anyone have a 
workaround? The text I'm inserting is already decoded to UTF16.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode




--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Merge and unicode

[J. Landman Gay via use-livecode]

On 9/9/19 2:39 PM, Paul Dupuis via use-livecode wrote:

On 9/9/2019 2:13 PM, J. Landman Gay via use-livecode wrote:

On 9/9/19 1:08 PM, J. Landman Gay via use-livecode wrote:
It seems that the merge command doesn't respect unicode. Does anyone 
have a workaround? The text I'm inserting is already decoded to UTF16.




I misspoke, sorry. It's the metadata that doesn't respect unicode.



Can you clarify what you mean when you say the "metadata" doesn't 
respect Unicode?


I'm in the middle of a big Unicode problem and have found and reported a 
ton of bugs where Unicode is not yet everywhere. I'm keenly interested 
in any I don't know about.


Actually I just double-checked and both merge and metadata may be wrong.

I get UTF8 text from a server that is then textDecoded to UTF16, and an 
html template that I merge with parts of the UTF16 text. In the variable 
watcher, the merged template looks correct but when a field is set to 
the htmltext the result is wrong, diacriticals and curly quotes are 
question marks. My solution for that was to urlEncode the content before 
merging, and urlDecoding when extracting it for display. That works.


In another part of the app I use the same (UTF16) text to set the 
metadata of a line in a field. When the script gets the metadata later, 
diacriticals and curly quotes are strange characters with very high UTF 
numbers.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: OT: Catalina - the end of ad hoc & in-house development?

[kee nethery via use-livecode]

I wrote an article on this process for MacOS and it took some time for me to 
figure out all the steps. Once documented, doesn’t really take that long to do. 
Apple doesn’t judge the contents of personally signed apps and the $99 per year 
is not a burden for me. 

I know a bunch of users who click on everything and download stuff and agree to 
all sorts of silly stuff and then claim that they have been hacked (and perhaps 
they have been hacked). I’m OK with extra steps if the OS becomes safer for 
folks who really do not understand security.

Just my two cents.

Kee nethery

> On Sep 9, 2019, at 2:07 PM, Dar Scott Consulting via use-livecode 
>  wrote:
> 
> Thank you for your work in this. 
> 
> I like the idea of identity signing of files, documents, programs, messages 
> and links. I was all PGP at one time. I am making a shortlist of Electronic 
> Lab Notebooks, and automated time-stamping and easy page/paragraph signing 
> are important features. I encourage customers to sign documents and I am 
> pleased to. In principle, I like codesigning. I like the idea of customers 
> far away and great grandchildren knowing that I wrote something and they can 
> be assured. However, I dream of an ideal world in which I can establish an 
> identity once and then check a box in the preferences in my IDE. 
> 
> For every person there is a cost, both in the learning curve and in money 
> ($100 per year for Apple IIRC and about the same for Windows). The yearly 
> vetting is a racket; I can assure folks I rarely turn into somebody else. And 
> the Apple patronizing is a high cost psychologically. But it is like taxes 
> and typhoons, it is the adventure I am handed in life and I address that.
> 
> So, I'm ready to renew my Apple Developer membership (cheaper than MSDN) and 
> jump into the fray. I will take heart and enter the next decade.
> 
> I skimmed over the lesson. I'm going to go rest.
> 
> Dar Scott
> Mad Scientist
> 
> 
> PS: Wasn't Stuxnet codesigned? 
> 
> 
>> On Sep 9, 2019, at 12:07 PM, Matthias Rebbe via use-livecode 
>>  wrote:
>> 
>> Although i understand anyone´s concern about Apple new requirement for 
>> notarization, i welcome Apple´s effort to make Mac OS X apps more secure for 
>> the users. I was also not very happy when i first heard that  10.14.6 will 
>> not start unnotarized apps right away. 
>> 
>> But what are our options here?
>> Either we stop developing for Apple or we fulfill Apple´s requirements. 
>> Everyone has to decide for her/himself, if the extra work for this 
>> Notarization is worth it.
>> 
>> Even if there is a way to run unnotarized apps under Mojave by going to 
>> security control panel and allow the app to be opened, i think this is not 
>> very user friendly and also not not very trustworthy, regardless if it is a 
>> free or a commercial app.
>> 
>> 
>> Under  Windows developers have to purchase a CodeSigining Certificate which 
>> costs from 79,- to 300,- USD, depending on where you buy from and depending 
>> on the type of the certificate, to be able to codesign.  And if i remember 
>> right, also under future Windows versions it will be more difficult to run 
>> unsigned Apps. At least there will be a popup with a warning message, this 
>> is currently in Win10 the case. That is also not very trustworthy, isn´t it?
>> 
>> 
>> 
>> Anyway, some weeks ago i´ve posted a link to a Livecode lesson which not 
>> only describes the required manual steps to notarize and staple an app for 
>> distribution outside the Mac Appstore , but also includes an helper stack 
>> which does all the needed steps.
>> 
>> You´ll find the lesson here: 
>> 
>> 
>> 
>> Regards,
>> Matthias
>> 
>> Matthias Rebbe
>> 
>> free tools for Livecoders:
>> InstaMaker 
>> WinSignMaker Mac 
>>> Am 07.09.2019 um 13:18 schrieb Peter Reid via use-livecode 
>>> mailto:use-livecode@lists.runrev.com>>:
>>> 
>>> I've been using LiveCode as my development platform since 1999. Practically 
>>> all the apps I've developed have been for in-house use by my family, 
>>> friends and customers - all very low numbers of copies distributed in an 
>>> informal manner. I've no interest in App Store distribution and the users 
>>> of my apps trust me such that they do not need my apps to be "approved" by 
>>> Apple. What's more important to them is how quickly I can release new apps 
>>> and new versions of existing apps.
>>> 
>>> Up to and including macOS Mojave my users can run my apps with the minor 
>>> inconvenience of having to right-click an app and approve its use, just 
>>> once. With macOS Catalina, if I understand things, it's not so simple, 
>>> instead these are the options:
>>> 
>>> 1. Code-sign and notarise my apps – I'm not interested in this for my kind 
>>> of apps which are essentially in-house/at ho

Re: Merge and unicode

[Dar Scott Consulting via use-livecode]

I'm not sure I understand. 

Do you mean "encoded to UTF-16"? In that case you should decode that to convert 
it to internal text. And then try merge. (Which still might have problems, I 
suppose.)


> On Sep 9, 2019, at 12:08 PM, J. Landman Gay via use-livecode 
>  wrote:
> 
> It seems that the merge command doesn't respect unicode. Does anyone have a 
> workaround? The text I'm inserting is already decoded to UTF16.
> 
> -- 
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: OT: Catalina - the end of ad hoc & in-house development?

[Dar Scott Consulting via use-livecode]

Thank you for your work in this. 

I like the idea of identity signing of files, documents, programs, messages and 
links. I was all PGP at one time. I am making a shortlist of Electronic Lab 
Notebooks, and automated time-stamping and easy page/paragraph signing are 
important features. I encourage customers to sign documents and I am pleased 
to. In principle, I like codesigning. I like the idea of customers far away and 
great grandchildren knowing that I wrote something and they can be assured. 
However, I dream of an ideal world in which I can establish an identity once 
and then check a box in the preferences in my IDE. 

For every person there is a cost, both in the learning curve and in money ($100 
per year for Apple IIRC and about the same for Windows). The yearly vetting is 
a racket; I can assure folks I rarely turn into somebody else. And the Apple 
patronizing is a high cost psychologically. But it is like taxes and typhoons, 
it is the adventure I am handed in life and I address that.

So, I'm ready to renew my Apple Developer membership (cheaper than MSDN) and 
jump into the fray. I will take heart and enter the next decade.

I skimmed over the lesson. I'm going to go rest.

Dar Scott
Mad Scientist


PS: Wasn't Stuxnet codesigned? 


> On Sep 9, 2019, at 12:07 PM, Matthias Rebbe via use-livecode 
>  wrote:
> 
> Although i understand anyone´s concern about Apple new requirement for 
> notarization, i welcome Apple´s effort to make Mac OS X apps more secure for 
> the users. I was also not very happy when i first heard that  10.14.6 will 
> not start unnotarized apps right away. 
> 
> But what are our options here?
> Either we stop developing for Apple or we fulfill Apple´s requirements. 
> Everyone has to decide for her/himself, if the extra work for this 
> Notarization is worth it.
> 
> Even if there is a way to run unnotarized apps under Mojave by going to 
> security control panel and allow the app to be opened, i think this is not 
> very user friendly and also not not very trustworthy, regardless if it is a 
> free or a commercial app.
> 
> 
> Under  Windows developers have to purchase a CodeSigining Certificate which 
> costs from 79,- to 300,- USD, depending on where you buy from and depending 
> on the type of the certificate, to be able to codesign.  And if i remember 
> right, also under future Windows versions it will be more difficult to run 
> unsigned Apps. At least there will be a popup with a warning message, this is 
> currently in Win10 the case. That is also not very trustworthy, isn´t it?
> 
> 
> 
> Anyway, some weeks ago i´ve posted a link to a Livecode lesson which not only 
> describes the required manual steps to notarize and staple an app for 
> distribution outside the Mac Appstore , but also includes an helper stack 
> which does all the needed steps.
> 
> You´ll find the lesson here: 
> 
> 
> 
> Regards,
> Matthias
> 
> Matthias Rebbe
> 
> free tools for Livecoders:
> InstaMaker 
> WinSignMaker Mac 
>> Am 07.09.2019 um 13:18 schrieb Peter Reid via use-livecode 
>> mailto:use-livecode@lists.runrev.com>>:
>> 
>> I've been using LiveCode as my development platform since 1999. Practically 
>> all the apps I've developed have been for in-house use by my family, friends 
>> and customers - all very low numbers of copies distributed in an informal 
>> manner. I've no interest in App Store distribution and the users of my apps 
>> trust me such that they do not need my apps to be "approved" by Apple. 
>> What's more important to them is how quickly I can release new apps and new 
>> versions of existing apps.
>> 
>> Up to and including macOS Mojave my users can run my apps with the minor 
>> inconvenience of having to right-click an app and approve its use, just 
>> once. With macOS Catalina, if I understand things, it's not so simple, 
>> instead these are the options:
>> 
>> 1. Code-sign and notarise my apps – I'm not interested in this for my kind 
>> of apps which are essentially in-house/at home developments.
>> 
>> 2. Using an active Internet connection, go through the right-click technique 
>> as now not just once, but EVERY time the app is opened.
>> 
>> In the past the 'Security & Privacy' General tab had a 3rd option for the 
>> setting 'Allow apps downloaded from:' which allowed you to install and use 
>> apps from any source. It seems that this is not possible with Catalina.
>> 
>> So with Catalina my users will need an Internet connection and will have to 
>> go through the right-click authorisation process every time they open one of 
>> my apps.
>> 
>> More seriously, it is becoming increasingly difficult to recommend the 
>> combination of the Mac plus LiveCode for app development. Up to now I've 
>> done all my app development on Mac+LC, even where the 

Re: OT: Catalina - the end of ad hoc & in-house development?

[Bob Sneidar via use-livecode]

I'm on your side on this one. OS developers are not getting sued by end users 
because they get malware. What is the impetus for all this?? Apple long ago had 
a policy tthat if they introduced a new way of doing something, the user could 
revert to the way it used to work. This ought to be a feature we can turn on or 
off at will. Apple has no standing to prevent anything we want to install on 
our computers INCLUDING MALWARE if we so desire. It's absolutely none of their 
business. 

Bob S


> On Sep 9, 2019, at 12:44 , Paul Dupuis via use-livecode 
>  wrote:
> 
> If I want to develop an small OSX (or Windows) app for my wife to help her 
> keep track of some hobby related items, I should not have to code sign or 
> notarize it for OSX or Windows or, honestly, any platform.
> 
> Every OS should provide a way that the USER is still in control of their OS 
> and can tell the OS, I trust this application. Period.
> 
> Attempting to idiot proof the OS only leads to the creation of more idiots.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: OT: Catalina - the end of ad hoc & in-house development?

[Paul Dupuis via use-livecode]

If I want to develop an small OSX (or Windows) app for my wife to help 
her keep track of some hobby related items, I should not have to code 
sign or notarize it for OSX or Windows or, honestly, any platform.


Every OS should provide a way that the USER is still in control of their 
OS and can tell the OS, I trust this application. Period.


Attempting to idiot proof the OS only leads to the creation of more idiots.



On 9/9/2019 2:07 PM, Matthias Rebbe via use-livecode wrote:

Although i understand anyone´s concern about Apple new requirement for 
notarization, i welcome Apple´s effort to make Mac OS X apps more secure for 
the users. I was also not very happy when i first heard that  10.14.6 will not 
start unnotarized apps right away.

But what are our options here?
Either we stop developing for Apple or we fulfill Apple´s requirements. 
Everyone has to decide for her/himself, if the extra work for this Notarization 
is worth it.

Even if there is a way to run unnotarized apps under Mojave by going to 
security control panel and allow the app to be opened, i think this is not very 
user friendly and also not not very trustworthy, regardless if it is a free or 
a commercial app.


Under  Windows developers have to purchase a CodeSigining Certificate which 
costs from 79,- to 300,- USD, depending on where you buy from and depending on 
the type of the certificate, to be able to codesign.  And if i remember right, 
also under future Windows versions it will be more difficult to run unsigned 
Apps. At least there will be a popup with a warning message, this is currently 
in Win10 the case. That is also not very trustworthy, isn´t it?



Anyway, some weeks ago i´ve posted a link to a Livecode lesson which not only 
describes the required manual steps to notarize and staple an app for 
distribution outside the Mac Appstore , but also includes an helper stack which 
does all the needed steps.

You´ll find the lesson here: 

  


Regards,
Matthias

Matthias Rebbe

free tools for Livecoders:
InstaMaker 
WinSignMaker Mac 

Am 07.09.2019 um 13:18 schrieb Peter Reid via use-livecode 
mailto:use-livecode@lists.runrev.com>>:

I've been using LiveCode as my development platform since 1999. Practically all the apps 
I've developed have been for in-house use by my family, friends and customers - all very 
low numbers of copies distributed in an informal manner. I've no interest in App Store 
distribution and the users of my apps trust me such that they do not need my apps to be 
"approved" by Apple. What's more important to them is how quickly I can release 
new apps and new versions of existing apps.

Up to and including macOS Mojave my users can run my apps with the minor 
inconvenience of having to right-click an app and approve its use, just once. 
With macOS Catalina, if I understand things, it's not so simple, instead these 
are the options:

1. Code-sign and notarise my apps – I'm not interested in this for my kind of 
apps which are essentially in-house/at home developments.

2. Using an active Internet connection, go through the right-click technique as 
now not just once, but EVERY time the app is opened.

In the past the 'Security & Privacy' General tab had a 3rd option for the 
setting 'Allow apps downloaded from:' which allowed you to install and use apps 
from any source. It seems that this is not possible with Catalina.

So with Catalina my users will need an Internet connection and will have to go 
through the right-click authorisation process every time they open one of my 
apps.

More seriously, it is becoming increasingly difficult to recommend the 
combination of the Mac plus LiveCode for app development. Up to now I've done 
all my app development on Mac+LC, even where the target platform is Windows or 
Android or Linux – I find it's simply faster, less error-prone and more 
pleasant with the Mac. However, from Catalina onwards even simple little 
utility apps, created for short-term use, will be tedious when opening or you 
have to learn about the complexity of code-signing and notarising and accept 
slower development cycles due to the need for Apple's approval!

This is quite depressing, especially since I abandoned iOS development due to 
Apple's distribution restrictions.

Back when the iPad 2 had just been released I developed for one of my customers an app 
to support health & safety audits for a national UK retail chain. The app took me 
15 days to develop in total. As a result of being able to field a team of 10-20 staff 
with iPads running my app, my customer was able to carry out 350 half-day H&S 
audits for 3 years. However I was unable to roll-out this app to other customers as the 
ad hoc distribution method I was using was limited to 100 iPads per year and the App 
Store was not a

Re: Merge and unicode

[Paul Dupuis via use-livecode]

On 9/9/2019 2:13 PM, J. Landman Gay via use-livecode wrote:

On 9/9/19 1:08 PM, J. Landman Gay via use-livecode wrote:
It seems that the merge command doesn't respect unicode. Does anyone 
have a workaround? The text I'm inserting is already decoded to UTF16.




I misspoke, sorry. It's the metadata that doesn't respect unicode.



Can you clarify what you mean when you say the "metadata" doesn't 
respect Unicode?


I'm in the middle of a big Unicode problem and have found and reported a 
ton of bugs where Unicode is not yet everywhere. I'm keenly interested 
in any I don't know about.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Merge and unicode

[J. Landman Gay via use-livecode]

On 9/9/19 1:08 PM, J. Landman Gay via use-livecode wrote:
It seems that the merge command doesn't respect unicode. Does anyone 
have a workaround? The text I'm inserting is already decoded to UTF16.




I misspoke, sorry. It's the metadata that doesn't respect unicode.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Merge and unicode

[J. Landman Gay via use-livecode]

It seems that the merge command doesn't respect unicode. Does anyone 
have a workaround? The text I'm inserting is already decoded to UTF16.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: OT: Catalina - the end of ad hoc & in-house development?

[Matthias Rebbe via use-livecode]

Although i understand anyone´s concern about Apple new requirement for 
notarization, i welcome Apple´s effort to make Mac OS X apps more secure for 
the users. I was also not very happy when i first heard that  10.14.6 will not 
start unnotarized apps right away. 

But what are our options here?
Either we stop developing for Apple or we fulfill Apple´s requirements. 
Everyone has to decide for her/himself, if the extra work for this Notarization 
is worth it.

Even if there is a way to run unnotarized apps under Mojave by going to 
security control panel and allow the app to be opened, i think this is not very 
user friendly and also not not very trustworthy, regardless if it is a free or 
a commercial app.


Under  Windows developers have to purchase a CodeSigining Certificate which 
costs from 79,- to 300,- USD, depending on where you buy from and depending on 
the type of the certificate, to be able to codesign.  And if i remember right, 
also under future Windows versions it will be more difficult to run unsigned 
Apps. At least there will be a popup with a warning message, this is currently 
in Win10 the case. That is also not very trustworthy, isn´t it?



Anyway, some weeks ago i´ve posted a link to a Livecode lesson which not only 
describes the required manual steps to notarize and staple an app for 
distribution outside the Mac Appstore , but also includes an helper stack which 
does all the needed steps.

You´ll find the lesson here: 

 

Regards,
Matthias

Matthias Rebbe

free tools for Livecoders:
InstaMaker 
WinSignMaker Mac 
> Am 07.09.2019 um 13:18 schrieb Peter Reid via use-livecode 
> mailto:use-livecode@lists.runrev.com>>:
> 
> I've been using LiveCode as my development platform since 1999. Practically 
> all the apps I've developed have been for in-house use by my family, friends 
> and customers - all very low numbers of copies distributed in an informal 
> manner. I've no interest in App Store distribution and the users of my apps 
> trust me such that they do not need my apps to be "approved" by Apple. What's 
> more important to them is how quickly I can release new apps and new versions 
> of existing apps.
> 
> Up to and including macOS Mojave my users can run my apps with the minor 
> inconvenience of having to right-click an app and approve its use, just once. 
> With macOS Catalina, if I understand things, it's not so simple, instead 
> these are the options:
> 
> 1. Code-sign and notarise my apps – I'm not interested in this for my kind of 
> apps which are essentially in-house/at home developments.
> 
> 2. Using an active Internet connection, go through the right-click technique 
> as now not just once, but EVERY time the app is opened.
> 
> In the past the 'Security & Privacy' General tab had a 3rd option for the 
> setting 'Allow apps downloaded from:' which allowed you to install and use 
> apps from any source. It seems that this is not possible with Catalina.
> 
> So with Catalina my users will need an Internet connection and will have to 
> go through the right-click authorisation process every time they open one of 
> my apps.
> 
> More seriously, it is becoming increasingly difficult to recommend the 
> combination of the Mac plus LiveCode for app development. Up to now I've done 
> all my app development on Mac+LC, even where the target platform is Windows 
> or Android or Linux – I find it's simply faster, less error-prone and more 
> pleasant with the Mac. However, from Catalina onwards even simple little 
> utility apps, created for short-term use, will be tedious when opening or you 
> have to learn about the complexity of code-signing and notarising and accept 
> slower development cycles due to the need for Apple's approval!
> 
> This is quite depressing, especially since I abandoned iOS development due to 
> Apple's distribution restrictions.
> 
> Back when the iPad 2 had just been released I developed for one of my 
> customers an app to support health & safety audits for a national UK retail 
> chain. The app took me 15 days to develop in total. As a result of being able 
> to field a team of 10-20 staff with iPads running my app, my customer was 
> able to carry out 350 half-day H&S audits for 3 years. However I was unable 
> to roll-out this app to other customers as the ad hoc distribution method I 
> was using was limited to 100 iPads per year and the App Store was not 
> appropriate for this type of app.
> 
> As a result of the limitations Apple impose on tablet app distribution, 
> recently I developed a speech-aid app just for small Android tablets and 
> larger phones. I have not made an iOS app. This app is low volume (in terms 
> of number of users) and requires significant personalising in order to be 
> effective for its users (typically they a

Re: Weird behavior for modal stacks and answer dialogs

[Mark Waddingham via use-livecode]

On 2019-09-09 16:16, Giovanni via use-livecode wrote:

Hi everybody,
thanks for feedback.
I think that the ones suggested cannot be considered as a solutions
nor a workarounds.
If I am working on an application with thousands (literally) of
answer/ask dialogs and modal called windows I cannot review all my
code to find a way to do something that the engine is called to do on
its own, don’t you think?
Anyway the “lock messages” can be used with answer/ask dialog but not
with modal windows that are intended to be used by the user.
Moreover as the modal stack behavior is correct on Windows and seems
to be correct on latest MacOS versions I found really strange to
garbage my code to workaround an issue that, in my opinion, can be
classified as a bug.


This sounds like  - 
the
bug appears to be triggered when certain other apps are running but we 
have
yet to be able to find out *why* these other apps have an effect on LC 
:(



During my investigation I found an interesting thing: starting
QuickTime to produce a screencast the app starts working properly even
without closing/restarting it. Closing QuickTime immediately
reintroduce the problem. This sounds like QuickTime uses a system
library that LC should use but doesn’t. Can someone give an hint about
this?!


That is intriguing - the fact that QT makes LC's modal windows work 
correctly
again is potentially quite a useful discovery. Do the machines which 
exhibit
the bug have any 'always running' software (e.g. like Spotify as 
suggested

in the above bug).

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Weird behavior for modal stacks and answer dialogs

[Giovanni via use-livecode]

Hi everybody, 
thanks for feedback.
I think that the ones suggested cannot be considered as a solutions nor a 
workarounds.
If I am working on an application with thousands (literally) of answer/ask 
dialogs and modal called windows I cannot review all my code to find a way to 
do something that the engine is called to do on its own, don’t you think?
Anyway the “lock messages” can be used with answer/ask dialog but not with 
modal windows that are intended to be used by the user.
Moreover as the modal stack behavior is correct on Windows and seems to be 
correct on latest MacOS versions I found really strange to garbage my code to 
workaround an issue that, in my opinion, can be classified as a bug.

During my investigation I found an interesting thing: starting QuickTime to 
produce a screencast the app starts working properly even without 
closing/restarting it. Closing QuickTime immediately reintroduce the problem. 
This sounds like QuickTime uses a system library that LC should use but 
doesn’t. Can someone give an hint about this?!


> Il giorno 09/set/2019, alle ore 13:30, Paul Dupuis via use-livecode 
>  ha scritto:
> 
> On 9/9/2019 6:50 AM, Giovanni via use-livecode wrote:
>> Hi everybody,
>> I’m writing here to report a very strange behavior of modal stacks and 
>> answer dialogs on MacOS Yosemite and Sierra.
>> Basically the modal windows or dialogs, in these OSes simply does not work 
>> and this seems to happen since LC 6.7.x!
>> When you open a modal stack the expected behavior is that the script 
>> execution is interrupted and you cannot interact with the calling or other 
>> opened windows. While the first thing seems to happen, the second one 
>> doesn’t work: you can click on buttons, fields or any other control in the 
>> calling stack or any other stack opened.
>> I think that this is a very big problem mainly in porting applications from 
>> older versions of LC to the newest one and it’s quite strange that nobody 
>> else noticed this before or consider this a problem.
>> 
>> I already filed a bug report at 
>> https://quality.livecode.com/show_bug.cgi?id=22368 
>>  in which you can also 
>> find a demo stack to easily reproduce the behavior.
>> 
>> Anyone can comment on this? Are you experiencing this as a problem? Is there 
>> a workaround or a solution for this?
>> 
>> The problem seems not to be present on Mojave but I was not able to try on 
>> other versions on MacOS and it’s not present on Windows.
>> 
>> 
> 
> This one has been around for a while, and I thought it had been previously 
> reports (but still not fixed). I seem to recall there was a lengthy 
> discussion of it on the list a long time ago.
> 
> The work-around seems to be locking things down before calling an ask or 
> answer dialog (lock messages, lock your menus and so on) so that no other 
> user actions can start any other script.
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Weird behavior for modal stacks and answer dialogs

[Bob Sneidar via use-livecode]

In more recent versions of MacOS the ability to interact with an application 
that was not the foreground application was added as a feature. For instance I 
can scroll a web page using the mouse wheel even though the web browser is not 
the frontmost app. I'm not sure how this could be disabled for modal windows 
only. 

I have seen other apps that do NOT allow interaction with a window if it is in 
the background. Perhaps what we need is a new command to turn off background 
interaction?

Bob S


> On Sep 9, 2019, at 04:30 , Paul Dupuis via use-livecode 
>  wrote:
> 
> On 9/9/2019 6:50 AM, Giovanni via use-livecode wrote:
>> Hi everybody,
>> I’m writing here to report a very strange behavior of modal stacks and 
>> answer dialogs on MacOS Yosemite and Sierra.
>> Basically the modal windows or dialogs, in these OSes simply does not work 
>> and this seems to happen since LC 6.7.x!
>> When you open a modal stack the expected behavior is that the script 
>> execution is interrupted and you cannot interact with the calling or other 
>> opened windows. While the first thing seems to happen, the second one 
>> doesn’t work: you can click on buttons, fields or any other control in the 
>> calling stack or any other stack opened.
>> I think that this is a very big problem mainly in porting applications from 
>> older versions of LC to the newest one and it’s quite strange that nobody 
>> else noticed this before or consider this a problem.
>> 
>> I already filed a bug report at 
>> https://quality.livecode.com/show_bug.cgi?id=22368 
>>  in which you can also 
>> find a demo stack to easily reproduce the behavior.
>> 
>> Anyone can comment on this? Are you experiencing this as a problem? Is there 
>> a workaround or a solution for this?
>> 
>> The problem seems not to be present on Mojave but I was not able to try on 
>> other versions on MacOS and it’s not present on Windows.
>> 
>> 
> 
> This one has been around for a while, and I thought it had been previously 
> reports (but still not fixed). I seem to recall there was a lengthy 
> discussion of it on the list a long time ago.
> 
> The work-around seems to be locking things down before calling an ask or 
> answer dialog (lock messages, lock your menus and so on) so that no other 
> user actions can start any other script.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

[ANN] This Week in LiveCode 193

[panagiotis merakos via use-livecode]

Hi all,

Read about new developments in LiveCode open source and the open source
community in today's edition of the "This Week in LiveCode" newsletter!

Read issue #193 here: http://bit.ly/2m0NTr5

This is a weekly newsletter about LiveCode, focussing on what's been
going on in and around the open source project. New issues will be
released weekly on Mondays. We have a dedicated mailing list that will
deliver each issue directly to you e-mail, so you don't miss any!

If you have anything you'd like mentioned (a project, a discussion
somewhere, an upcoming event) then please get in touch.



-- 
Panagiotis Merakos 
LiveCode Software Developer

Everyone Can Create Apps 
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Regression iOS: unlock screen for visual effect

[Sannyasin Brahmanathaswami via use-livecode]

I am getting a "flicker" instead of a "dissolve"  in LC9.5 + latest iOS on 
iPhone 12.4.1

command loadNewImage pPath
lock screen for visual effect
set the filename of sMainImage to pPath
setImageToFullCardLoc sMainImage, "portrait", 0,0
centerMe sMainImage,0,0
show sMainImage --with visual effect "dissolve" 
unlock screen with visual effect "dissolve" 
end loadNewImage

same code, an Android: I get a smooth "dissolve"

I know Apple keeps changing things.
I don't know how far back this goes, where it was OK on an earlier version of 
LC or whether it was working on an earlier version of iOS... 

can anyone confirm?

BR


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Weird behavior for modal stacks and answer dialogs

[Tom Glod via use-livecode]

Yeah i remember getting really heated when this behaviior was
introduced. drove me nuts.

I think I just used a "wait while stack is open" kind of command (with
messages) and it works fine.


On Mon, Sep 9, 2019 at 7:31 AM Paul Dupuis via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 9/9/2019 6:50 AM, Giovanni via use-livecode wrote:
> > Hi everybody,
> > I’m writing here to report a very strange behavior of modal stacks and
> answer dialogs on MacOS Yosemite and Sierra.
> > Basically the modal windows or dialogs, in these OSes simply does not
> work and this seems to happen since LC 6.7.x!
> > When you open a modal stack the expected behavior is that the script
> execution is interrupted and you cannot interact with the calling or other
> opened windows. While the first thing seems to happen, the second one
> doesn’t work: you can click on buttons, fields or any other control in the
> calling stack or any other stack opened.
> > I think that this is a very big problem mainly in porting applications
> from older versions of LC to the newest one and it’s quite strange that
> nobody else noticed this before or consider this a problem.
> >
> > I already filed a bug report at
> https://quality.livecode.com/show_bug.cgi?id=22368 <
> https://quality.livecode.com/show_bug.cgi?id=22368> in which you can also
> find a demo stack to easily reproduce the behavior.
> >
> > Anyone can comment on this? Are you experiencing this as a problem? Is
> there a workaround or a solution for this?
> >
> > The problem seems not to be present on Mojave but I was not able to try
> on other versions on MacOS and it’s not present on Windows.
> >
> >
>
> This one has been around for a while, and I thought it had been
> previously reports (but still not fixed). I seem to recall there was a
> lengthy discussion of it on the list a long time ago.
>
> The work-around seems to be locking things down before calling an ask or
> answer dialog (lock messages, lock your menus and so on) so that no
> other user actions can start any other script.
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Weird behavior for modal stacks and answer dialogs

[Paul Dupuis via use-livecode]

On 9/9/2019 6:50 AM, Giovanni via use-livecode wrote:

Hi everybody,
I’m writing here to report a very strange behavior of modal stacks and answer 
dialogs on MacOS Yosemite and Sierra.
Basically the modal windows or dialogs, in these OSes simply does not work and 
this seems to happen since LC 6.7.x!
When you open a modal stack the expected behavior is that the script execution 
is interrupted and you cannot interact with the calling or other opened 
windows. While the first thing seems to happen, the second one doesn’t work: 
you can click on buttons, fields or any other control in the calling stack or 
any other stack opened.
I think that this is a very big problem mainly in porting applications from 
older versions of LC to the newest one and it’s quite strange that nobody else 
noticed this before or consider this a problem.

I already filed a bug report at https://quality.livecode.com/show_bug.cgi?id=22368 
 in which you can also find 
a demo stack to easily reproduce the behavior.

Anyone can comment on this? Are you experiencing this as a problem? Is there a 
workaround or a solution for this?

The problem seems not to be present on Mojave but I was not able to try on 
other versions on MacOS and it’s not present on Windows.




This one has been around for a while, and I thought it had been 
previously reports (but still not fixed). I seem to recall there was a 
lengthy discussion of it on the list a long time ago.


The work-around seems to be locking things down before calling an ask or 
answer dialog (lock messages, lock your menus and so on) so that no 
other user actions can start any other script.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: 9.5 on Windows seems terribly unable to deal with fields full of text?

[Giovanni via use-livecode]

Hi Geoff,
I can confirm this and I reported this several times.
The whole IDE (the script editor mainly) is quite unusable on Windows 
workstations, no matter how many RAM or CPU is installed.
Tried all the suggestions on a lot of different Windows workstations without 
any success.
Hope that the LC developers will have the time to investigate on this issue 
that has also been reported on the QA center in different formats and confirmed 
by a lot of people.

> Il giorno 08/set/2019, alle ore 16:29, Geoff Canyon via use-livecode 
>  ha scritto:
> 
> Just running a script with large variables, no viewers open, and setting a 
> breakpoint took 20 seconds. 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Weird behavior for modal stacks and answer dialogs

[Giovanni via use-livecode]

Hi everybody,
I’m writing here to report a very strange behavior of modal stacks and answer 
dialogs on MacOS Yosemite and Sierra.
Basically the modal windows or dialogs, in these OSes simply does not work and 
this seems to happen since LC 6.7.x!
When you open a modal stack the expected behavior is that the script execution 
is interrupted and you cannot interact with the calling or other opened 
windows. While the first thing seems to happen, the second one doesn’t work: 
you can click on buttons, fields or any other control in the calling stack or 
any other stack opened.
I think that this is a very big problem mainly in porting applications from 
older versions of LC to the newest one and it’s quite strange that nobody else 
noticed this before or consider this a problem.

I already filed a bug report at 
https://quality.livecode.com/show_bug.cgi?id=22368 
 in which you can also find 
a demo stack to easily reproduce the behavior.

Anyone can comment on this? Are you experiencing this as a problem? Is there a 
workaround or a solution for this?

The problem seems not to be present on Mojave but I was not able to try on 
other versions on MacOS and it’s not present on Windows.

Regards!

--
Giovanni
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: livecode in terminal ; path in linux as alternative to bash?

[Mark Wieder via use-livecode]

On 9/8/19 7:32 PM, Eric A. Engle via use-livecode wrote:

  I am learning bash (bourne again shell) on linux; i would like to know if it 
is possible to 1) invoke livecode from the command line 2) how to install 
livcode into my path 3) whether livecode can be used as an alternative to bash?




1. (if installed for all users) /opt/livecode//
where  is the product you want to launch and  is 
whether it's 32-bit or 64-bit (you'll only have one installed.

For instance with 64-bit engines installed:
/opt/livecode/livecodecommunity-9.5.0.x86_64/LiveCode Community.x86_64
/opt/livecode/livecodeindy-9.0.4.x86_64/LiveCode Indy.x86_64

But if you're asking this in connection with #2 and #3, ignore this and 
read on.


2. That depends on your linux distribution. Assuming you're asking this 
in connection with #3, you can temporarily put LiveCode server in your 
path from the commandline (here I've got the server in my Downloads folder)

PATH=$PATH:~/Downloads/servertest/

If you want it to be more permanent, you'll have to edit one of your 
configuration files. Depending on your linux distro it might be .bashrc 
or .bash_profile or /etc/environment, etc.


3. I use the LiveCode server as an alternate bash shell. Set the path as 
in #2, then write .lc script files (and chmod +x them before running)


Here's a test.lc:

#!livecode-community-server
include "test1.lc"
local x, y
put 3 into x
put x into y
put "-- environment --" & cr
put "libraries=" && the libraries & cr
put "frontscripts=" && the frontscripts & cr
put "backscripts=" && the backscripts & cr
put "stacks=" && the stacks & cr
put "stacksinuse=" && the stacksinuse & cr

put "the version=" && the version & cr
put "the environment=" && the environment & cr
put "the editionType=" && the editionType & cr
put "the defaultFolder=" && the defaultFolder & cr
put "the defaultStack=" && the defaultStack & cr

put "-- dateItem test --" & cr
put 1489755600 into tVar
convert tVar to dateitems
put "fixed time (dateItems)=" & tVar & cr
get the time
convert it to dateitems
put "current time (dateItems)=" & it & cr
put the screenrect & cr


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode