Windows 7 : bug with replace CR and tab

[bangkok]

It's insane.

Try the stack. On Windows XP, or Vista... it's working well : you can replace CR, and then replace TAB in the text in a field (or replacetext).

But on Windows 7 (with LiveCode 4.6.4 or LC 4.6.3 or RunRev 3.5), the field becomes.... blank (eventhough a "put the number of chars in field"... gives a proper number) !

It's okay with a short string, but not a long one.

[Mark]

Hi,

Why do you have

Code: Select all

   set the lineDelimiter to numToChar(13)

in your script? This doesn't make any sense. CR is ASCII 10 not 13.

Kind regards,

Mark

[bangkok]

[quote="Mark"
in your script? This doesn't make any sense. CR is ASCII 10 not 13.
[/quote]

My mystake (I was making a lot of tests, so I left this instruction in the script).

But it doesn't affect the script.

Furthermore this wrong instruction is not in the script of the "replacetext" function (right button). Result is identical.

So have you tried on a Windows 7 PC ? Am I crazy of is my Windows 7 PC infected by a strange virus ?

[WaltBrown]

Hi Bangkok. Works fine for me - LC 4.6.4 on Win7. I just end up with a single long line. I tried every order of replacement on short and long lists.

[bangkok]

Hi Bangkok. Works fine for me - LC 4.6.4 on Win7. I just end up with a single long line. I tried every order of replacement on short and long lists.

Damned !

Thanks. I'm going to check my laptop and reinstall a fresh Windows 7.

[bn]

Hi bangkok,

maybe you run into this problem:

from the documentation:

Maximum length of a line in a field 65,536 characters storage No more than 32,786 pixels wide for display

section 2.2.9 LiveCode Memory Limits

if your text is too long and you take out cr you effectively create a one-line field. LiveCode cuts off the length of a line at 65533. There also used to be display problems with lines exceeding that limit. Don't rely on the display for lines longer than max. You can do all this stuff in variables.

Kind regards

Bernd

[WaltBrown]

Hi Bernd. I used his stack as is and did not run into the line length problem. But I have a GeForce 9200 GPU in my laptop, maybe that affects the display problem you mention? I imagine the line is already cut off before it is sent to the GPU? Or does LC send all the original objects to the GPU and lets the GPU do the trimming visually? I can't see that LC would send the field window and the field contents separately to the GPU (although I have seen stranger things in SW )

[sturgis]

bn is right, this is the issue. Not sure why it works for some and not others though. I've run into the issue on all platforms in the past and just try to avoid really long lines.

To test, after you remove the tab and cr, if you "put the number of chars in field "letest" it will be 7k using the long list, despite it appearing blank.

If you then start deleting chars 100 at a time when you get down to 4600 it will magically re-appear. Then if you "put the formattedwidth of field "letest" the response will be 32194, just short of the stated limit for display.

This can be a problem with copy and paste too. Grab a bunch of crap from a browser and paste it in, losing cr's and funky strange things happen.

Hi bangkok,

maybe you run into this problem:

from the documentation:

Maximum length of a line in a field 65,536 characters storage No more than 32,786 pixels wide for display

section 2.2.9 LiveCode Memory Limits

if your text is too long and you take out cr you effectively create a one-line field. LiveCode cuts off the length of a line at 65533. There also used to be display problems with lines exceeding that limit. Don't rely on the display for lines longer than max. You can do all this stuff in variables.

Kind regards

Bernd

[WaltBrown]

I changed the Generate long list in the TEST BUG stack from 500 to 50000.

I got a length of the field of about 600,000, then after replacing CR I got 65533, which supports the specs (-3).

After replacing CR, the line wrapped in the field and displayed properly.

If I selected "dontWrap" the line (of 65533 chars) displayed but was garbled and overwritten. The contents though were still valid, not garbled. I started deleting chars from the field (by copying into a local variable, shortening the line from the beginning by 1000 chars, and replacing the field contents) and around 4000 or so it stopped being garbled.

I tried a new test. I got the field contents (starting at empty), added 1000 chars to the beginning (and end in a second test) of it, then wrote that back to the field. The field started displaying blank rather than the string at around 42,000 characters. It acted the same with and without "dontWrap". Interestingly, when adding chars it never displayed garbled.

After the text disappeared, I opened the field property inspector and made a minor change (I set it to all caps). The text reappeared when I closed the property inspector. I added text (in 1000 char chunks) to it until it reached a length of 65533. Sometimes it disappeared, sometimes it reappeared, but stayed at a length of 65533. Interestingly, even with all caps set for the field, my added strings of lower case stayed lower case. Note the scroll bar got confused during this, with the thumb changing size radically during the process (in one addition of 1000 chars it went from a sliver to 2/3 of the scroll bar).

Moral of the story? Even though the spec says 65536, and my experience matches Klaus at 65533 for field line contents, I'm going to keep it below 4000 per line because of the field display issues I had (if I even find a need to have that long a line). I can see where that can be a problem if you are dealing with a text file without CR, say from a DOC or DOCX document with really long paragraphs.