Re: Unicode is not "everywhere"...

[dsc--- via use-livecode]

I tried it.

on mouseUp
   set the shellCommand to "cmd.exe /u"
   put textDecode( shell("dir"), "UTF-16" )
end mouseUp

That does seem to double up the newlines. It looks like it works otherwise.

Dar


> On Aug 22, 2019, at 12:15 PM, dsc--- via use-livecode 
>  wrote:
> 
> The shellCommand property for Windows is "cmd.exe", not "command.com 
> " as described in the dictionary.
> 
> I wonder how setting that to "cmd.exe /u" would affect this behavior.
> 
>> On Aug 22, 2019, at 10:19 AM, Dar Scott Consulting via use-livecode 
>>  wrote:
>> 
>> Concerning 22335...
>> 
>> 1. I wonder if anyone uses shell() to return binary values.
>> 
>> 2. I wonder about whether using the shellCommand property would help.
>> 
>>> On Aug 22, 2019, at 9:37 AM, Paul Dupuis via use-livecode 
>>>  wrote:
>>> 
>>> I have filed two bug reports that are in LC905rc1 and go back to 7.0 where 
>>> LC functions that should deal with Unicode properly do not.
>>> 
>>> These are:
>>> https://quality.livecode.com/show_bug.cgi?id=22213 -- The "detailed files" 
>>> function fails for any files with Unicode in the name, returning the 
>>> filename with %3F (?) instead of the Unicode characters properly URL 
>>> encoded (they should be UFT8 encoded and then URL encoded)
>>> and
>>> https://quality.livecode.com/show_bug.cgi?id=22334 -- the shell command is 
>>> not Unicode aware in returning it's results. On OSX, the results are UTF8 
>>> encoded (discovered by accident) and so an extra step is needed to text 
>>> decode them, but on Windows it is a complete failure and any Unicode 
>>> results of the command line - SHOWN 100% correctly is executed in the 
>>> command line - are returned NATIVE encoded, causing all Unicode characters 
>>> to become question marks.
>>> 
>>> I have written work-around for both of these bugs that can be found in the 
>>> bug reports. My work-around for the "details files" is slow, due to 
>>> repeated calls to shell to fetch file properties one at a time.
>>> 
>>> If anyone else out there has run into these bugs in your own code and 
>>> developed a faster work-around for the "detailed files" and would care to 
>>> share, I would welcome a faster fix.
>>> 
>>> Of course, I'd welcome a fix from LiveCode, Ltd. to these bugs even more!
>>> 
>>> ___
>>> 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 to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Datagrid2 Form view slow down.

[Monte Goulding via use-livecode]

> On 23 Aug 2019, at 11:48 am, Sean Cole (Pi) via use-livecode 
>  wrote:
> 
>> 
>> Did you read this bit of my response? ;-)
>>> The issue is more likely with the properties of the main datagrid group
>> rather than your row template
> 
> 
> Hmm, so this now confuses me further. Are you saying that the properties of
> the main datagrid group also should not have their properties set? So we
> cannot turn on or off the border or scrollbars for these either in the MAIN
> datagrid group?? Is that documented anywhere?  Does this make sense?


Yes so the datagrid group needs to be able to use the container layerMode so 
that means the properties of it and all its owner groups must be checked. With 
acceleratedRendering true for the stack just double-check the effective 
layermode of the main datagrid group and any parent groups.

> 
> Here are the properties of my *main datagrid group*:
> rect 24,151,755,654
> toolTip
> hScroll 0
> vScroll 0
> boundingRect
> bottomColor
> *hScrollbar false*
> visible true
> sharedBehavior false
> topColor
> textStyle
> borderWidth 0
> backPattern
> tabGroupBehavior false
> shadowPattern
> dontSearch false
> *dropShadow*
> topPattern
> label
> selectGroupedControls false
> backColor
> radioBehavior true
> cantSelect false
> lockLoc false
> foreColor
> hilitedButton 0
> hilitePattern
> forePattern
> showFocusBorder true
> layerMode container
> *showName false*
> shadowOffset 4
> backgroundBehavior false
> focusPattern
> shadowColor
> opaque false
> scrollbarWidth 20
> *innerGlow*
> ink srcCopy
> clipsToRect false
> *showBorder false*
> name group "O2AccountsGrid"
> textSize
> cantDelete false
> textFont
> unboundedVScroll false
> disabled false
> unboundedHScroll false
> *colorOverlay*
> altId 0
> hiliteColor
> behavior button id 1005 of stack "revDataGridLibrary"
> borderColor 64,64,64
> *innerShadow*
> bottomPattern
> borderPattern
> *outerGlow*
> id 51592
> blendLevel 0
> traversalOn true
> vScrollbar false
> focusColor
> threeD false
> margins 0
> layer 7
> 
> 
> On Fri, 23 Aug 2019 at 02:23, Monte Goulding via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> 
>> 
>>> On 23 Aug 2019, at 11:14 am, Sean Cole (Pi) via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>>> 
>>> So, the fact that some of those parameters are set to something but that
>> I
>>> did not do this, does that mean there is something wrong in the engine
>> that
>>> is setting them when it should not? Does that make sense? I've not even
>>> attempted changing any parameter on the template group and only gone in
>> to
>>> edit it's contents as usual. I may have had the inspector up and that may
>>> have displayed the settings before I clicked the 'edit group' button but
>>> that is all.
>> 
>> Did you read this bit of my response? ;-)
>>> The issue is more likely with the properties of the main datagrid group
>> rather than your row template
>> 
>>> 
>>> And, to clarify, should things like opaque, which is currently set to
>>> false, really be set to empty and likewise for all the others?
>> 
>> For boolean properties in that list you want them false.
>> 
>> Cheers
>> 
>> Monte
>> 
>> ___
>> 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: Datagrid2 Form view slow down.

[Sean Cole (Pi) via use-livecode]

>
> Did you read this bit of my response? ;-)
> > The issue is more likely with the properties of the main datagrid group
> rather than your row template


Hmm, so this now confuses me further. Are you saying that the properties of
the main datagrid group also should not have their properties set? So we
cannot turn on or off the border or scrollbars for these either in the MAIN
datagrid group?? Is that documented anywhere?  Does this make sense?

Here are the properties of my *main datagrid group*:
rect 24,151,755,654
toolTip
hScroll 0
vScroll 0
boundingRect
bottomColor
*hScrollbar false*
visible true
sharedBehavior false
topColor
textStyle
borderWidth 0
backPattern
tabGroupBehavior false
shadowPattern
dontSearch false
*dropShadow*
topPattern
label
selectGroupedControls false
backColor
radioBehavior true
cantSelect false
lockLoc false
foreColor
hilitedButton 0
hilitePattern
forePattern
showFocusBorder true
layerMode container
*showName false*
shadowOffset 4
backgroundBehavior false
focusPattern
shadowColor
opaque false
scrollbarWidth 20
*innerGlow*
ink srcCopy
clipsToRect false
*showBorder false*
name group "O2AccountsGrid"
textSize
cantDelete false
textFont
unboundedVScroll false
disabled false
unboundedHScroll false
*colorOverlay*
altId 0
hiliteColor
behavior button id 1005 of stack "revDataGridLibrary"
borderColor 64,64,64
*innerShadow*
bottomPattern
borderPattern
*outerGlow*
id 51592
blendLevel 0
traversalOn true
vScrollbar false
focusColor
threeD false
margins 0
layer 7


On Fri, 23 Aug 2019 at 02:23, Monte Goulding via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
>
> > On 23 Aug 2019, at 11:14 am, Sean Cole (Pi) via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > So, the fact that some of those parameters are set to something but that
> I
> > did not do this, does that mean there is something wrong in the engine
> that
> > is setting them when it should not? Does that make sense? I've not even
> > attempted changing any parameter on the template group and only gone in
> to
> > edit it's contents as usual. I may have had the inspector up and that may
> > have displayed the settings before I clicked the 'edit group' button but
> > that is all.
>
> Did you read this bit of my response? ;-)
> > The issue is more likely with the properties of the main datagrid group
> rather than your row template
>
> >
> > And, to clarify, should things like opaque, which is currently set to
> > false, really be set to empty and likewise for all the others?
>
> For boolean properties in that list you want them false.
>
> Cheers
>
> Monte
>
> ___
> 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: Datagrid2 Form view slow down.

[Monte Goulding via use-livecode]

> On 23 Aug 2019, at 11:14 am, Sean Cole (Pi) via use-livecode 
>  wrote:
> 
> So, the fact that some of those parameters are set to something but that I
> did not do this, does that mean there is something wrong in the engine that
> is setting them when it should not? Does that make sense? I've not even
> attempted changing any parameter on the template group and only gone in to
> edit it's contents as usual. I may have had the inspector up and that may
> have displayed the settings before I clicked the 'edit group' button but
> that is all.

Did you read this bit of my response? ;-)
> The issue is more likely with the properties of the main datagrid group 
> rather than your row template

> 
> And, to clarify, should things like opaque, which is currently set to
> false, really be set to empty and likewise for all the others?

For boolean properties in that list you want them false.

Cheers

Monte

___
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: Unicode is not "everywhere"...

[Monte Goulding via use-livecode]

> On 23 Aug 2019, at 11:07 am, Paul Dupuis via use-livecode 
>  wrote:
> 
> I reported what I thought was 3 bugs in 1 report in 
> https://quality.livecode.com/show_bug.cgi?id=22213 
> . I have edited that 
> report to focus on a single bug - that the detailed files (and probably the 
> detailed folders) is broken for Unicode as every Unicode character in a file 
> name is encoded as %3F or ?. Originally I had though that meant that there 
> was a problem with urlEncode and urlDecode as per bug 
> https://quality.livecode.com/show_bug.cgi?id=14015 
>  that your references 
> Monte. However, I now consider that urlEncode and urlDecode are NOT broken 
> and bug 14015 is really a Documentation bug that the urlEncode and urlDecode 
> Dictionary entries should be updated.
> 
> If you look at the Wikipedia entry for URL (or percent) encoding, it states 
> that the standard practice for non-ASCII character in a URL is to encode them 
> as UTF8 BEFORE percent-encoding. There fore, urlDecode and urlEncode are 
> working correctly by the accepted standards. The Dictionary entries need 
> updating to note that any non-ASCII text should be UTF8 encode before 
> urlEncoding and UTF8 decoded after urlDecoding. See my DOC bugs:
> 
> https://quality.livecode.com/show_bug.cgi?id=22340 
> 
> and
> https://quality.livecode.com/show_bug.cgi?id=22341 
> 
> 
> I believe these replace bug 
> https://quality.livecode.com/show_bug.cgi?id=14015 
> 

Hmm… ok that’s a fair point. We really do need a standards compliant urlEncode 
function though which could resolve this because if it gets a string parameter 
it will know it should convert to UTF8. Again it would need a parameter or 
something.
> 
> Also, the detailed files and detailed folders doesn't need an array returned 
> (although that would be nice). This issue is the percent-encoding is not 
> following the standard convention of UTF8 encoding non-ASCII characters 
> before percent encoding. LC should follow industry conventions in this regard.

Yes, although I think we can’t do that in a backwards compatible way which is 
why I suggested an array option.

Cheers

Monte
___
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: Datagrid2 Form view slow down.

[Sean Cole (Pi) via use-livecode]

Thanks, Monte, for responding.

So, the fact that some of those parameters are set to something but that I
did not do this, does that mean there is something wrong in the engine that
is setting them when it should not? Does that make sense? I've not even
attempted changing any parameter on the template group and only gone in to
edit it's contents as usual. I may have had the inspector up and that may
have displayed the settings before I clicked the 'edit group' button but
that is all.

And, to clarify, should things like opaque, which is currently set to
false, really be set to empty and likewise for all the others?

All the best, as always.

Sean Cole
*Pi Digital *


On Fri, 23 Aug 2019 at 01:58, Monte Goulding via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
>
> > On 23 Aug 2019, at 12:27 am, Sean Cole (Pi) via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Hi Monte,
> >
> > Many thanks for your response. I don't know how I had inferred that I was
> > using mobile as this is ONLY for PC Desktop and HTML5 emscripten running
> in
> > Chrome on a PC Desktop (which will be the final intended platform). I'm
> > confused about what I said that caused Herman and yourself to assume I
> was
> > talking about mobile. I thought the HTML5 forum was for Desktop Web only.
>
>
> Sorry, my mistake so skip that bit ;-)
>
> >
> > I checked in dglist for the effective layermode of the Row Templates in
> my
> > form and they are coming up as 'static' (set layermode is 'dynamic'). So
> > there must be some incompatible adornment. But, as Henry asked, what
> > adornments would cause this? I don't even know what is meant by the term
> > 'adornments’.
>
> The following must not be set on the group for it to work as a container
> or scrolling layermode:
>
> - opaque
> - showBorder
> - showname
> - hScrollbar
> - vScrollbar
> - dropShadow
> - innerShadow
> - outerGlow
> - innerGlow
> - colorOverlay
>
> Yes these should be listed in the docs for layerMode instead of just `(no
> borders, no scrollbars)`. If someone would like to create a docs bug report
> about that and even better submit a patch that would he helpful for
> everyone I think.
>
> >
> > All I have in my template is 3 standard text fields with no adjustments
>
> The issue is more likely with the properties of the main datagrid group
> rather than your row template
>
> Cheers
>
> Monte
> ___
> 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: Unicode is not "everywhere"...

[Dar Scott Consulting via use-livecode]

All encoding is binary, but not all binary is valid Unicode encoding. 

> On Aug 22, 2019, at 6:53 PM, Paul Dupuis via use-livecode 
>  wrote:
> 
> Currently, OSX shell returns UTF8 which may mean that it is returning binary 
> as it is returning 8-bit bytes where Unicode text has been encoded as UTF8

___
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: Datagrid2 Form view slow down.

[Monte Goulding via use-livecode]

> The following must not be set on the group for it to work as a container or 
> scrolling layermode:
> 
> - opaque 
> - showBorder 
> - showname 
> - hScrollbar
> - vScrollbar 
> - dropShadow
> - innerShadow
> - outerGlow
> - innerGlow
> - colorOverlay
> 
> Yes these should be listed in the docs for layerMode instead of just `(no 
> borders, no scrollbars)`. If someone would like to create a docs bug report 
> about that and even better submit a patch that would he helpful for everyone 
> I think.

FWIW I think it would also be pretty handy to have an indicator on the property 
inspector about whether there’s an issue with these properties in the object 
hierarchy.  It wouldn’t be that complicated, just recurse through the owner 
groups and check these properties.

Cheers

Monte
___
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: Unicode is not "everywhere"...

[Dar Scott Consulting via use-livecode]

But that isn't the issue. Well, not what I thought the issue was.

If shell() only returns binary, as suggested by the mention of textDecode(), 
then binary data must always have an interpretation as a string to keep from 
breaking legacy code. Currently, that is interpreted as an 8-bit character of a 
character set of which ASCII is a subset. So, I'm OK with shell() being 
clarified to return binary data, which might be pure byte stream, some Unicode 
encoded data, or other character encoded data.  That is, unless one is using 
ASCII, then textDecode should be used, and even with ASCII, it may be used.

I'm also OK with shell() returning a string with no loss intermediate 
conversions.  I can use "open process" for binary data, if fixed.



> On Aug 22, 2019, at 2:17 PM, Paul Dupuis via use-livecode 
>  wrote:
> 
> On 8/22/2019 4:08 PM, Richard Gaskin via use-livecode wrote:
>> Dar Scott wrote:
>> 
>> > If the result of shell() is run through textDecode, should then
>> > shell() return binary data? This puts it outside the scope of
>> > "everywhere". I like the idea, as long as simple ASCII characters
>> > work transparently.
>> 
>> Isn't that the goal of UTF-8, which is why so many programming languages 
>> uses it as the default?
>> 
> 
> Richard is correct. UTF8 encoding does not change readability of ASCII 
> characters.
> Encoding the results from shell as UTF8 does mean that ASCII characters can 
> be used in a return values without text decoding. shell() under OSX, at least 
> tested under LC905rc1, actually returns UTF8 and probably no one using shell 
> on OSX has noticed if you've just been working with ASCII characters as the 
> output of your shell comamnd.
> 
> 
> ___
> 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: Unicode is not "everywhere"...

[Paul Dupuis via use-livecode]

On 8/22/2019 8:46 PM, Monte Goulding via use-livecode wrote:

Both of these are anomalies we could only resolve with new syntax I think… at 
lease the urlEncode one is. I’m not sure if the expectation of shell is it 
returns text or binary data… The workaround there would be to open process for 
UTF8 text read instead of using shell... not sure if UTF8 would be right on 
windows… possibly UTF16 there.

Regarding url encoding the anomaly bug is 
https://quality.livecode.com/show_bug.cgi?id=14015 
 so your report should be 
closed as a duplicate of it I suspect.

Probably the simplest way to resolve the detailed files/folders issue is to 
have a new parameter for the files and folders function to return an array. 
Anyone want to suggest a name for the parameter?

Cheers

Monte


I reported what I thought was 3 bugs in 1 report in 
https://quality.livecode.com/show_bug.cgi?id=22213. I have edited that 
report to focus on a single bug - that the detailed files (and probably 
the detailed folders) is broken for Unicode as every Unicode character 
in a file name is encoded as %3F or ?. Originally I had though that 
meant that there was a problem with urlEncode and urlDecode as per bug 
https://quality.livecode.com/show_bug.cgi?id=14015 that your references 
Monte. However, I now consider that urlEncode and urlDecode are NOT 
broken and bug 14015 is really a Documentation bug that the urlEncode 
and urlDecode Dictionary entries should be updated.


If you look at the Wikipedia entry for URL (or percent) encoding, it 
states that the standard practice for non-ASCII character in a URL is to 
encode them as UTF8 BEFORE percent-encoding. There fore, urlDecode and 
urlEncode are working correctly by the accepted standards. The 
Dictionary entries need updating to note that any non-ASCII text should 
be UTF8 encode before urlEncoding and UTF8 decoded after urlDecoding. 
See my DOC bugs:


https://quality.livecode.com/show_bug.cgi?id=22340
and
https://quality.livecode.com/show_bug.cgi?id=22341

I believe these replace bug 
https://quality.livecode.com/show_bug.cgi?id=14015


Also, the detailed files and detailed folders doesn't need an array 
returned (although that would be nice). This issue is the 
percent-encoding is not following the standard convention of UTF8 
encoding non-ASCII characters before percent encoding. LC should follow 
industry conventions in this regard.


___
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: Datagrid2 Form view slow down.

[Monte Goulding via use-livecode]

> On 23 Aug 2019, at 12:27 am, Sean Cole (Pi) via use-livecode 
>  wrote:
> 
> Hi Monte,
> 
> Many thanks for your response. I don't know how I had inferred that I was
> using mobile as this is ONLY for PC Desktop and HTML5 emscripten running in
> Chrome on a PC Desktop (which will be the final intended platform). I'm
> confused about what I said that caused Herman and yourself to assume I was
> talking about mobile. I thought the HTML5 forum was for Desktop Web only.


Sorry, my mistake so skip that bit ;-)

> 
> I checked in dglist for the effective layermode of the Row Templates in my
> form and they are coming up as 'static' (set layermode is 'dynamic'). So
> there must be some incompatible adornment. But, as Henry asked, what
> adornments would cause this? I don't even know what is meant by the term
> 'adornments’.

The following must not be set on the group for it to work as a container or 
scrolling layermode:

- opaque 
- showBorder 
- showname 
- hScrollbar
- vScrollbar 
- dropShadow
- innerShadow
- outerGlow
- innerGlow
- colorOverlay

Yes these should be listed in the docs for layerMode instead of just `(no 
borders, no scrollbars)`. If someone would like to create a docs bug report 
about that and even better submit a patch that would he helpful for everyone I 
think.

> 
> All I have in my template is 3 standard text fields with no adjustments

The issue is more likely with the properties of the main datagrid group rather 
than your row template

Cheers

Monte
___
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: Unicode is not "everywhere"...

[Paul Dupuis via use-livecode]

I just want it consistent and documented and able to return more than 
just ASCII data


Currently, OSX shell returns UTF8 which may mean that it is returning 
binary as it is returning 8-bit bytes where Unicode text has been 
encoded as UTF8


Windows returns CP1252 text, not binary and any Unicode results, which 
DOS displays as Unicode just fine, can be returned without elaborate 
work-arounds.


That by definition is a bug.

I would advocate that shell should return binary data. Text being 
returned should be UTF8 encoded, that way people expecting ASCII do nto 
need to o anything, they can just work with teh returned text. People 
expecting Unicode can use textDecode to get the UTF8 converted to LC 
native 16-bit Unicode, and people extcting binary can use the byte chunk 
to process what comes back however they want.


The current missing part is the UTF8 encoding of text being returned 
under Windows.


Also, as my platforms of concern are Windows and OSX, I have not tested 
shell() under Linux. I assume it behaves like OSX but that is an assumption.



On 8/22/2019 8:36 PM, Dar Scott Consulting via use-livecode wrote:

You can't have it both ways.

Either shell() only characters of the broadest character set, Unicode, or it 
returns binary. If it returns characters, then it will not work for binary 
responses; that will have to be documented as excluded.

If Unicode is returned then textDecode is not needed and even should not be 
used.




On Aug 22, 2019, at 2:08 PM, Richard Gaskin via use-livecode 
 wrote:

Dar Scott wrote:


If the result of shell() is run through textDecode, should then
shell() return binary data? This puts it outside the scope of
"everywhere". I like the idea, as long as simple ASCII characters
work transparently.

Isn't that the goal of UTF-8, which is why so many programming languages uses 
it as the default?

--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web

ambassa...@fourthworld.comhttp://www.FourthWorld.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: Unicode is not "everywhere"...

[Monte Goulding via use-livecode]

Both of these are anomalies we could only resolve with new syntax I think… at 
lease the urlEncode one is. I’m not sure if the expectation of shell is it 
returns text or binary data… The workaround there would be to open process for 
UTF8 text read instead of using shell... not sure if UTF8 would be right on 
windows… possibly UTF16 there.

Regarding url encoding the anomaly bug is 
https://quality.livecode.com/show_bug.cgi?id=14015 
 so your report should be 
closed as a duplicate of it I suspect.

Probably the simplest way to resolve the detailed files/folders issue is to 
have a new parameter for the files and folders function to return an array. 
Anyone want to suggest a name for the parameter?

Cheers

Monte


> On 23 Aug 2019, at 1:37 am, Paul Dupuis via use-livecode 
>  wrote:
> 
> I have filed two bug reports that are in LC905rc1 and go back to 7.0 where LC 
> functions that should deal with Unicode properly do not.
> 
> These are:
> https://quality.livecode.com/show_bug.cgi?id=22213 -- The "detailed files" 
> function fails for any files with Unicode in the name, returning the filename 
> with %3F (?) instead of the Unicode characters properly URL encoded (they 
> should be UFT8 encoded and then URL encoded)
> and
> https://quality.livecode.com/show_bug.cgi?id=22334 -- the shell command is 
> not Unicode aware in returning it's results. On OSX, the results are UTF8 
> encoded (discovered by accident) and so an extra step is needed to text 
> decode them, but on Windows it is a complete failure and any Unicode results 
> of the command line - SHOWN 100% correctly is executed in the command line - 
> are returned NATIVE encoded, causing all Unicode characters to become 
> question marks.
> 
> I have written work-around for both of these bugs that can be found in the 
> bug reports. My work-around for the "details files" is slow, due to repeated 
> calls to shell to fetch file properties one at a time.
> 
> If anyone else out there has run into these bugs in your own code and 
> developed a faster work-around for the "detailed files" and would care to 
> share, I would welcome a faster fix.
> 
> Of course, I'd welcome a fix from LiveCode, Ltd. to these bugs even more!
> 
> ___
> 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: Unicode is not "everywhere"...

[Dar Scott Consulting via use-livecode]

You can't have it both ways.

Either shell() only characters of the broadest character set, Unicode, or it 
returns binary. If it returns characters, then it will not work for binary 
responses; that will have to be documented as excluded.

If Unicode is returned then textDecode is not needed and even should not be 
used.



> On Aug 22, 2019, at 2:08 PM, Richard Gaskin via use-livecode 
>  wrote:
> 
> Dar Scott wrote:
> 
> > If the result of shell() is run through textDecode, should then
> > shell() return binary data? This puts it outside the scope of
> > "everywhere". I like the idea, as long as simple ASCII characters
> > work transparently.
> 
> Isn't that the goal of UTF-8, which is why so many programming languages uses 
> it as the default?
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.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: Unicode is not "everywhere"...

[Paul Dupuis via use-livecode]

On 8/22/2019 4:08 PM, Richard Gaskin via use-livecode wrote:

Dar Scott wrote:

> If the result of shell() is run through textDecode, should then
> shell() return binary data? This puts it outside the scope of
> "everywhere". I like the idea, as long as simple ASCII characters
> work transparently.

Isn't that the goal of UTF-8, which is why so many programming 
languages uses it as the default?




Richard is correct. UTF8 encoding does not change readability of ASCII 
characters.
Encoding the results from shell as UTF8 does mean that ASCII characters 
can be used in a return values without text decoding. shell() under OSX, 
at least tested under LC905rc1, actually returns UTF8 and probably no 
one using shell on OSX has noticed if you've just been working with 
ASCII characters as the output of your shell comamnd.



___
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: Unicode is not "everywhere"...

[Richard Gaskin via use-livecode]

Dar Scott wrote:

> If the result of shell() is run through textDecode, should then
> shell() return binary data? This puts it outside the scope of
> "everywhere". I like the idea, as long as simple ASCII characters
> work transparently.

Isn't that the goal of UTF-8, which is why so many programming languages 
uses it as the default?


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.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: Unicode is not "everywhere"...

[Dar Scott Consulting via use-livecode]

If the result of shell() is run through textDecode, should then shell() return 
binary data? This puts it outside the scope of "everywhere". I like the idea, 
as long as simple ASCII characters work transparently. 

Currently, "is strictly" says it is a string, not a binary string.

As far as the question, perhaps a rhetorical question, there are some binary 
streams that are not UTF-16 or UTF-8. 

> On Aug 22, 2019, at 1:24 PM, Richard Gaskin via use-livecode 
>  wrote:
> 
> Dar Scott wrote:
> 
> > Concerning 22335...
> >
> > 1. I wonder if anyone uses shell() to return binary values.
> 
> In the modern Unicode world, what is "text" and what is "binary"?
> 
> I believe MacOS' HFS+ and Win's NFS use UTF-16 natively, Linux  EXT4 uses 
> UTF-8.
> 
> It might seem simple to have a habit of running file names through 
> textDecode, but since fopen uses ANSI I'm not sure what the implications are.
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.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: Unicode is not "everywhere"...

[Richard Gaskin via use-livecode]

Dar Scott wrote:

> Concerning 22335...
>
> 1. I wonder if anyone uses shell() to return binary values.

In the modern Unicode world, what is "text" and what is "binary"?

I believe MacOS' HFS+ and Win's NFS use UTF-16 natively, Linux  EXT4 
uses UTF-8.


It might seem simple to have a habit of running file names through 
textDecode, but since fopen uses ANSI I'm not sure what the implications 
are.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.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: Datagrid2 Form view slow down.

[JJS via use-livecode]

(i saw you also talked about iOs, so there was some confusion)

From this bug https://quality.livecode.com/show_bug.cgi?id=22231 i know 
that for from it has to be container mode.


For table it has to be dynamic. That's on mobile and runs smooth on 
Android. Indeed no fancy glow or anything.


But may we not assume  that it would be the same for html5 ? (just asking)


Op 22-8-2019 om 20:18 schreef Sean Cole (Pi) via use-livecode:

Ah yes, that's well hidden. Thanks for that, Jaqueline.

I would assume, based on Marks old post, that anything that needs to be
rendered on the container itself (not it's contents) would be classified an
adornment.

As you can see from my parameters though, the template does not have any
borders or scrollbars but still has an effective layerMode of 'Static'
while having a setting of 'dynamic'. So there is an anomaly with this I
think.

Thanks
Sean Cole


On Thu, 22 Aug 2019 at 18:28, J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:


On 8/22/19 10:58 AM, Sean Cole (Pi) via use-livecode wrote:

   This
is about the ONLY description I can find for this ANYWHERE on the web!

The dictionary has a partial (or full?) explanation in the layerMode
entry: no borders, no scrollbars.

But that's all it says. I assume graphic effects are also a no-no.

--
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: Datagrid2 Form view slow down.

[Sean Cole (Pi) via use-livecode]

Ah yes, that's well hidden. Thanks for that, Jaqueline.

I would assume, based on Marks old post, that anything that needs to be
rendered on the container itself (not it's contents) would be classified an
adornment.

As you can see from my parameters though, the template does not have any
borders or scrollbars but still has an effective layerMode of 'Static'
while having a setting of 'dynamic'. So there is an anomaly with this I
think.

Thanks
Sean Cole


On Thu, 22 Aug 2019 at 18:28, J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 8/22/19 10:58 AM, Sean Cole (Pi) via use-livecode wrote:
> >   This
> > is about the ONLY description I can find for this ANYWHERE on the web!
>
> The dictionary has a partial (or full?) explanation in the layerMode
> entry: no borders, no scrollbars.
>
> But that's all it says. I assume graphic effects are also a no-no.
>
> --
> 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: Unicode is not "everywhere"...

[dsc--- via use-livecode]

The shellCommand property for Windows is "cmd.exe", not "command.com 
" as described in the dictionary.

I wonder how setting that to "cmd.exe /u" would affect this behavior.

> On Aug 22, 2019, at 10:19 AM, Dar Scott Consulting via use-livecode 
>  wrote:
> 
> Concerning 22335...
> 
> 1. I wonder if anyone uses shell() to return binary values.
> 
> 2. I wonder about whether using the shellCommand property would help.
> 
>> On Aug 22, 2019, at 9:37 AM, Paul Dupuis via use-livecode 
>>  wrote:
>> 
>> I have filed two bug reports that are in LC905rc1 and go back to 7.0 where 
>> LC functions that should deal with Unicode properly do not.
>> 
>> These are:
>> https://quality.livecode.com/show_bug.cgi?id=22213 -- The "detailed files" 
>> function fails for any files with Unicode in the name, returning the 
>> filename with %3F (?) instead of the Unicode characters properly URL encoded 
>> (they should be UFT8 encoded and then URL encoded)
>> and
>> https://quality.livecode.com/show_bug.cgi?id=22334 -- the shell command is 
>> not Unicode aware in returning it's results. On OSX, the results are UTF8 
>> encoded (discovered by accident) and so an extra step is needed to text 
>> decode them, but on Windows it is a complete failure and any Unicode results 
>> of the command line - SHOWN 100% correctly is executed in the command line - 
>> are returned NATIVE encoded, causing all Unicode characters to become 
>> question marks.
>> 
>> I have written work-around for both of these bugs that can be found in the 
>> bug reports. My work-around for the "details files" is slow, due to repeated 
>> calls to shell to fetch file properties one at a time.
>> 
>> If anyone else out there has run into these bugs in your own code and 
>> developed a faster work-around for the "detailed files" and would care to 
>> share, I would welcome a faster fix.
>> 
>> Of course, I'd welcome a fix from LiveCode, Ltd. to these bugs even more!
>> 
>> ___
>> 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: Datagrid2 Form view slow down.

[J. Landman Gay via use-livecode]

On 8/22/19 10:58 AM, Sean Cole (Pi) via use-livecode wrote:

  This
is about the ONLY description I can find for this ANYWHERE on the web!


The dictionary has a partial (or full?) explanation in the layerMode 
entry: no borders, no scrollbars.


But that's all it says. I assume graphic effects are also a no-no.

--
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: Unicode is not "everywhere"...

[Dar Scott Consulting via use-livecode]

Concerning 22335...

1. I wonder if anyone uses shell() to return binary values.

2. I wonder about whether using the shellCommand property would help.

> On Aug 22, 2019, at 9:37 AM, Paul Dupuis via use-livecode 
>  wrote:
> 
> I have filed two bug reports that are in LC905rc1 and go back to 7.0 where LC 
> functions that should deal with Unicode properly do not.
> 
> These are:
> https://quality.livecode.com/show_bug.cgi?id=22213 -- The "detailed files" 
> function fails for any files with Unicode in the name, returning the filename 
> with %3F (?) instead of the Unicode characters properly URL encoded (they 
> should be UFT8 encoded and then URL encoded)
> and
> https://quality.livecode.com/show_bug.cgi?id=22334 -- the shell command is 
> not Unicode aware in returning it's results. On OSX, the results are UTF8 
> encoded (discovered by accident) and so an extra step is needed to text 
> decode them, but on Windows it is a complete failure and any Unicode results 
> of the command line - SHOWN 100% correctly is executed in the command line - 
> are returned NATIVE encoded, causing all Unicode characters to become 
> question marks.
> 
> I have written work-around for both of these bugs that can be found in the 
> bug reports. My work-around for the "details files" is slow, due to repeated 
> calls to shell to fetch file properties one at a time.
> 
> If anyone else out there has run into these bugs in your own code and 
> developed a faster work-around for the "detailed files" and would care to 
> share, I would welcome a faster fix.
> 
> Of course, I'd welcome a fix from LiveCode, Ltd. to these bugs even more!
> 
> ___
> 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: Datagrid2 Form view slow down.

[Sean Cole (Pi) via use-livecode]

Monte,

Here's a list of the properties of the Row Template 0001 from my grid. Bear
in mind I have not manually adjusted anything other that the rect of the
group.

rect 24,151,755,180
toolTip
hScroll 0
vScroll 0
boundingRect
bottomColor
hScrollbar false
visible true
sharedBehavior false
topColor
textStyle
borderWidth 0
backPattern
tabGroupBehavior false
shadowPattern
dontSearch false
dropShadow
topPattern
label
selectGroupedControls true
backColor
radioBehavior true
cantSelect false
lockLoc true
foreColor
hilitedButton 0
hilitePattern
forePattern
showFocusBorder true
layerMode dynamic
showName false
shadowOffset 4
backgroundBehavior false
focusPattern
shadowColor
opaque false
scrollbarWidth 20
innerGlow
ink srcCopy
clipsToRect false
showBorder false
name group "Row Template 0001"
textSize
cantDelete false
textFont
unboundedVScroll false
disabled false
unboundedHScroll false
colorOverlay
altId 0
hiliteColor
behavior button id  of stack "Data Grid Templates 1563330294005"
borderColor
innerShadow
bottomPattern
borderPattern
outerGlow
id 83861
blendLevel 0
traversalOn true
vScrollbar false
focusColor
threeD true
margins 0
layer 17

Are you able to spot anything there that flags up as an adornment?

I've taken my understanding of adornment from a post by Mark Waddingham
back in June 2017 (!) during the proposition of DG2 where he states:

You can already use acceleratedRendering to do this but it currently
> only works for top-level groups and your groups have to be 'unadorned' -
> meaning that you have turned off all properties of the group which mean
> the group itself renders something (e.g. borders, scrollbars).
>

Mark there was referring to what acceleratedRendering could already do back
then, so it is only the concept of 'unadorned' that I am referencing. This
is about the ONLY description I can find for this ANYWHERE on the web!

Thanks again
Sean.
___
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: Datagrid2 Form view slow down.

[Sean Cole (Pi) via use-livecode]

Thanks Bob,

You don't need to invoke DG2. All old DGs are 'converted' (for want of a
better word) to v2. The engine handles this.

Faster DataGrid Performance: As stated, that was a quote from the original
kickstarter (or whatever) campaign just as background to show that it was
intended to improve performance for HTML5 as well as mobile and desktop (as
html5 is my main area of concern at the moment), not mobile alone (although
it was mainly requested for mobile). So, by default, performance for DG
should go up for ALL platforms because of bringing up the efficiency of
"the way it creates, removes and caches objects". This stands to reason.

Note: None of the new features are included in the Guide as yet so you need
to refer to the release notes for 9.0, 9.0.5 and 9.5 to get an
understanding of these. Although the notes do not make it completely clear
about all of the features as yet. Hopefully soon they will employ a
dedicated copywriter who loves making dictionaries and guides to bring it
all up to date.

Still, hopefully an understanding of 'adornments' (as the dictionary seems
to shed no light on this) will help answer this.

Sean


On Thu, 22 Aug 2019 at 15:35, Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I think it was this part:
>
> Faster DataGrid Performance
> The number one feature we get asked for is to improve performance of
> complex DataGrids on mobile. We will improve performance in two ways.
> First, we will rework the DataGrid code to be more efficient in the way
> that it creates, removes and caches objects.
>
> The datagrid performance is for Mobile, not all platforms.
>
> BTW do I have to invoke DG2 when creating one? Or all DGs now v2?
>
> Bob S
>
> > On Aug 22, 2019, at 07:27 , Sean Cole (Pi) via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Hi Monte,
> >
> > Many thanks for your response. I don't know how I had inferred that I was
> > using mobile as this is ONLY for PC Desktop and HTML5 emscripten running
> in
> > Chrome on a PC Desktop (which will be the final intended platform). I'm
> > confused about what I said that caused Herman and yourself to assume I
> was
> > talking about mobile. I thought the HTML5 forum was for Desktop Web only.
> >
> > I checked in dglist for the effective layermode of the Row Templates in
> my
> > form and they are coming up as 'static' (set layermode is 'dynamic'). So
> > there must be some incompatible adornment. But, as Henry asked, what
> > adornments would cause this? I don't even know what is meant by the term
> > 'adornments'.
> >
> > All I have in my template is 3 standard text fields with no adjustments,
> > the standard background graphic (no adjustment) and a single rounded
> > rectangle graphic that sits underneath one of the fields (the only
> > adjustment I have tried on this is turning off antialiasing just to see
> if
> > it made a difference). Is a rounded rectangle classed as an 'adornment'?
> > But even without this added it still shows as being effective 'static'.
> If
> > we can't use simple text fields and a simple rect graphic without
> affecting
> > the effective layerMode then Form view is near useless.
> >
> > I look forward to being educated about adornments? Thanks again.
> >
> > Henry,
> >
> > you need to use...
> >
> > put the effective layermode of grp "Row Template 0001" of grp "dglist"
> > of grp "DG_Browse"
> >
> >
> > Sean
> >
> >
> >>
> > ___
> > 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

Unicode is not "everywhere"...

[Paul Dupuis via use-livecode]

I have filed two bug reports that are in LC905rc1 and go back to 7.0 
where LC functions that should deal with Unicode properly do not.


These are:
https://quality.livecode.com/show_bug.cgi?id=22213 -- The "detailed 
files" function fails for any files with Unicode in the name, returning 
the filename with %3F (?) instead of the Unicode characters properly URL 
encoded (they should be UFT8 encoded and then URL encoded)

and
https://quality.livecode.com/show_bug.cgi?id=22334 -- the shell command 
is not Unicode aware in returning it's results. On OSX, the results are 
UTF8 encoded (discovered by accident) and so an extra step is needed to 
text decode them, but on Windows it is a complete failure and any 
Unicode results of the command line - SHOWN 100% correctly is executed 
in the command line - are returned NATIVE encoded, causing all Unicode 
characters to become question marks.


I have written work-around for both of these bugs that can be found in 
the bug reports. My work-around for the "details files" is slow, due to 
repeated calls to shell to fetch file properties one at a time.


If anyone else out there has run into these bugs in your own code and 
developed a faster work-around for the "detailed files" and would care 
to share, I would welcome a faster fix.


Of course, I'd welcome a fix from LiveCode, Ltd. to these bugs even more!

___
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: Datagrid2 Form view slow down.

[Bob Sneidar via use-livecode]

I think it was this part: 

Faster DataGrid Performance
The number one feature we get asked for is to improve performance of
complex DataGrids on mobile. We will improve performance in two ways.
First, we will rework the DataGrid code to be more efficient in the way
that it creates, removes and caches objects.

The datagrid performance is for Mobile, not all platforms. 

BTW do I have to invoke DG2 when creating one? Or all DGs now v2?

Bob S

> On Aug 22, 2019, at 07:27 , Sean Cole (Pi) via use-livecode 
>  wrote:
> 
> Hi Monte,
> 
> Many thanks for your response. I don't know how I had inferred that I was
> using mobile as this is ONLY for PC Desktop and HTML5 emscripten running in
> Chrome on a PC Desktop (which will be the final intended platform). I'm
> confused about what I said that caused Herman and yourself to assume I was
> talking about mobile. I thought the HTML5 forum was for Desktop Web only.
> 
> I checked in dglist for the effective layermode of the Row Templates in my
> form and they are coming up as 'static' (set layermode is 'dynamic'). So
> there must be some incompatible adornment. But, as Henry asked, what
> adornments would cause this? I don't even know what is meant by the term
> 'adornments'.
> 
> All I have in my template is 3 standard text fields with no adjustments,
> the standard background graphic (no adjustment) and a single rounded
> rectangle graphic that sits underneath one of the fields (the only
> adjustment I have tried on this is turning off antialiasing just to see if
> it made a difference). Is a rounded rectangle classed as an 'adornment'?
> But even without this added it still shows as being effective 'static'. If
> we can't use simple text fields and a simple rect graphic without affecting
> the effective layerMode then Form view is near useless.
> 
> I look forward to being educated about adornments? Thanks again.
> 
> Henry,
> 
> you need to use...
> 
> put the effective layermode of grp "Row Template 0001" of grp "dglist"
> of grp "DG_Browse"
> 
> 
> Sean
> 
> 
>> 
> ___
> 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: Datagrid2 Form view slow down.

[Sean Cole (Pi) via use-livecode]

Hi Monte,

Many thanks for your response. I don't know how I had inferred that I was
using mobile as this is ONLY for PC Desktop and HTML5 emscripten running in
Chrome on a PC Desktop (which will be the final intended platform). I'm
confused about what I said that caused Herman and yourself to assume I was
talking about mobile. I thought the HTML5 forum was for Desktop Web only.

I checked in dglist for the effective layermode of the Row Templates in my
form and they are coming up as 'static' (set layermode is 'dynamic'). So
there must be some incompatible adornment. But, as Henry asked, what
adornments would cause this? I don't even know what is meant by the term
'adornments'.

All I have in my template is 3 standard text fields with no adjustments,
the standard background graphic (no adjustment) and a single rounded
rectangle graphic that sits underneath one of the fields (the only
adjustment I have tried on this is turning off antialiasing just to see if
it made a difference). Is a rounded rectangle classed as an 'adornment'?
But even without this added it still shows as being effective 'static'. If
we can't use simple text fields and a simple rect graphic without affecting
the effective layerMode then Form view is near useless.

I look forward to being educated about adornments? Thanks again.

Henry,

you need to use...

put the effective layermode of grp "Row Template 0001" of grp "dglist"
of grp "DG_Browse"


Sean


>
___
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: Re:

[hlowe via use-livecode]

Monte,

I am experiencing a similar issue under LC 9.5.0 (Stable). An iOS app that
has exhibited slow, stuttering, scrolling of a DataGrid form under prior
versions of LC has not shown much improvement since upgrading to LC 9.5.0.

I have acceleratedRendering set to true for the stack. The datagrid has its
Layer Mode set to "container". There are no adornments that I can see (could
we get a list of relevant adornments to avoid?).

Given a datagrid named "DG_Browse" what code would I use to determine "the
effective layerMode of the groups in group dgList of your datagrid", as you
requested"

 I tried:

Answer the effective layerMode of group "dgList" of group "DG_Browse"

but that generated an error.

Henry



--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
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