Re: Unicode is not "everywhere"...

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

Re: Datagrid2 Form view slow down.

> 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

Re: Datagrid2 Form view slow down.

> > 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?

Re: Datagrid2 Form view slow down.

> 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?

Re: Unicode is not "everywhere"...

> 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 -

Re: Datagrid2 Form view slow down.

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

Re: Unicode is not "everywhere"...

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

Re: Datagrid2 Form view slow down.

> 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

Re: Unicode is not "everywhere"...

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

Re: Unicode is not "everywhere"...

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

Re: Datagrid2 Form view slow down.

> 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

Re: Unicode is not "everywhere"...

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

Re: Unicode is not "everywhere"...

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

Re: Unicode is not "everywhere"...

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

Re: Unicode is not "everywhere"...

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

Re: Unicode is not "everywhere"...

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

Re: Unicode is not "everywhere"...

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

Re: Unicode is not "everywhere"...

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

Re: Datagrid2 Form view slow down.

(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.

Re: Datagrid2 Form view slow down.

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

Re: Unicode is not "everywhere"...

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

Re: Datagrid2 Form view slow down.

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

Re: Unicode is not "everywhere"...

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

Re: Datagrid2 Form view slow down.

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

Re: Datagrid2 Form view slow down.

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

Unicode is not "everywhere"...

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

Re: Datagrid2 Form view slow down.

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

Re: Datagrid2 Form view slow down.

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

Re: Re:

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