mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Jan 2004
Posts: 2,127
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
For lines in a script beneath very long wrapped lines, the lower right corner shows the wrong line number. When one of those lower lines generates a status window error message which reports the line number of the error, the line number is correct according to a text editor which does not use line wrapping, or using $read(scriptname.mrc,nt,N). But when using the lower right corner to navigate to the line having the error, it reports a number that's too high by the number of line wrappings, which in some cases can be more than once.

The wrapping is also inconsistent, depending on the Font+Fontsize. At Fixedsys-9, the Remotes Editor wraps around column 2700, but changing the Font and/or Fontsize also changes the column where the line wraps. At Consolas-18, it wraps around column 1430.

If you press Ctrl+G to go to the line reported in the error message, it also goes to the line as reported by the lower right corner, instead of the true line where the error is actually located.

Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
Do you get the same thing from lines wrapped with $& ? (I'm curious but too lazy to check wink


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Jan 2004
Posts: 2,127
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
Not the same thing. When this is the 1st 5 lines of a script, A displays line 2, and both B and C report the $scriptline is 4 as if line 3 doesn't exist. But D shows in editor as line 5, and that's what $scriptline says.

Code:
alias linetest {
  echo -a A $scriptline
  echo -a B $scriptline $&
    echo -a C $scriptline test
  echo -a D $scriptline
}

Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Thanks for your bug report. When you say long lines, what line lengths are you talking about? I have tested this up to the maximum line length that mIRC can handle, which is 8192 characters, and it looks fine so far. I haven't been able to induce line-wrapping in the richedit control unless I go far beyond 8192 characters.

If you are talking about line lengths beyond that, I expect that the richedit editbox has its own limits. Once you reach those, it will probably start chopping/wrapping/displaying text erratically.

That said, line-wrapping in the editbox is actually performed by the richedit control itself. mIRC has no control over that.

Joined: Jan 2004
Posts: 2,127
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
Are the line numbers along the left margin and the line:column in the lower corner also coming from richedit?

I'm talking about the line length numbers in my post above. And to be clear, I'm talking about wrapped lines, not lines being physically split into two lines with a $crlf. If I create testscript.mrc containing the contents of this clipboard:

Code:
//clipboard -n alias wrapped_line $({) $crlf echo 3 -s line $!scriptline $str(long line $chr(32),400) line $!scriptline $crlf echo 4 -s line $!scriptline $crlf echo -a error $!scriptline $!len $crlf $(})



... the long line can wrap at various positions, depending on the combination of fontname/fontsize used in the alt+R editor. After pressing Ctrl+H to format the indents, if the editor font is Tahoma fontsize 10, the entirety of the long echo command fits on 1 line, and the lower-right corner reports the cursor position beyond the final 'e' is column 4046 of line 2. The sequential numbers to the left, the indicator in the lower corner, and Ctrl+G all agree that the error echo is line 4 of the script.

If I increase the fontsize to Tahoma 12, the display of the long line wraps to a 2nd row, and the 3 indicators report the error echo is now line 5.

If I increase the fontsize to Tahoma 24, the long line is wrapped to a 3rd line, and the 3 indicators all agree the error echo is now line 6.

Regardless of how the script is wrapped, the display in status window correctly reports both $scriptline's for the green line are 2, the red line is 3, and the identifier warning is caused by line 4.

When at least 1 long line gets wrapped in the editor, line numbers for everything below that point are reported as the wrong line, differing by the number of wrappings. Using Ctrl+G to jump to the line number reported by an error message causes the cursor to jump to the wrong scriptline, and the distance can depend on the font used by each user. To obtain the true script line causing an error message, the reported line N would need to be used in $read(path\scriptname,nt,N), assuming the file was not saved in .ini format.

Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Quote:
Are the line numbers along the left margin and the line:column in the lower corner also coming from richedit?

No, no they are not. Microsoft chose to make us jump through a hoop of fire to extract this information ourselves from richedit. Implementing support for this required code of mind-boggling and convoluted complexity. I have to wear goggles when approaching it and even then there is a minimum safe distance of about five metres.

Quote:
... the long line can wrap at various positions

Right. That was exasperating. This took several hours to track down. Initially, I was not able to reproduce this as I was testing it in the aliases section. I then noticed that it reproduced in all the other sections. So I reviewed all of the script editor code to see if the aliases section was doing something different. Two hours later, after not finding anything, I concluded it must have something to do with the contents of the text in the aliases section. I eventually whittled it down to one line that contained a combination of unicode charcters. Apparently, these were enough to disable wrapping.

It also turns out that on Windows Vista and onwards it is now possible to extended the wrapping length by using EM_SETTARGETDEVICE with a large value. However, in my tests this still wrapped text at just over 8192 characters. I was also able to do the same thing by initially inserting the same set of unicode characters into the editbox.

Unfortunately, once the editbox does start wrapping, none of the Windows APIs will return the correct indexes for the lines. An application literally has to retrieve and scan each line in the editbox up to the currently visible line for soft returns and perform calculations that way, which is impractical if the editbox has a large amount of text. I did find a convoluted solution in the MASM forums but it will not be practical for the maximum amount of text that the script editor editbox allows, ie. one megabyte, and would slow down line calculations to a crawl with each typed character.

I have applied the increased wrap length setting to the script editor in the next beta, so it should allow longer lines without wrapping. However, until the APIs are improved, if the lines do wrap, we will have to live with the line numbers being incorrect.

Joined: Jan 2004
Posts: 2,127
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
You didn't mention which unicodes were causing that, but I guessed it had something to do with RTL, and sure enough it did.

It didn't seem to be a combination of characters, but the mere presence of adding any 1 of these to my test script immediately caused the wrapping to go away. It didn't matter whether I added it above or below the wrapped line, even if added to a line below the visible area.

And the wrapping stayed away, even when the character was deleted or removed with Ctrl+Z, and even after switching to view a different script or going to the aliases tab. This added-then-removed RTL character also prevented wrapping in any other Alt+R or Alt+D script which was viewed after viewing the script containing that RTL character while the editor remained open.

So far I've seen this happens with any 1 of codepoints 8207 and 8234 through 8238.

Another way to block the wrapping could be adding another kind of formatting when the script window opens. It looks like alt+R already adds indent formatting to non-indented lines and adds a $crlf to the final line if it's not there already, yet these changes don't trigger a save-on-exit in the absence of other script changes. As long as it didn't have any unintended consequences, perhaps another formatting change could be adding one of these RTL characters to the script as the window opens, then immediately removing it.

Since it seems to affect all script windows after viewing the one containing the RTL, it wouldn't need to be done with any loaded scripts except the active file when the editor opens.

Joined: Jan 2004
Posts: 2,127
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
Looks like the new beta handles really long limes correctly. Fixedsys Excelsior is a fairly wide font, and even using size 28 of that isn't wrapping, in the absence of the special unicode symbols.

The 7.52 no-beta adds a hard $crlf to script lines longer than 4150, and the beta doesn't do it until longer than 8292 including indenting.

The only way I can make the script lose text with these long lines is when additional indenting pushes the line shortly past the 8292 limit. Steps:

(1) Edit the above "wrapped_line" alias to duplicate the 4000-char line 3 times, then remove the $crlf between them so you have a line that's 12k in length.

(2) If you close the editor and save changes, when you reopen the editor, the long line has been split at column 8292, putting the rest of the data on the next line.

(3) Now edit the last few visible characters of that 8292 line to be identifiable, such as being the numbers 1-5. Close/reopen shows they're still preserved.

(4) Now add a pair of { } surrounding brackets to the lines above and below that line. Using Ctrl+H, the line indents a couple more columns and appears to allow a line length of 8294.

(5) If you close+reopen the editor without doing anything else after the Ctrl+H, the longer line still is preserved. But if you then add a blank row which forces the editor to save the script again, saving+reopening the script shows the last characters of that long line are chopped off and not added to the next row.

But as long as someone says away from the 8292 limit and doesn't add additional indenting to that line, they shouldn't have problems.


Link Copied to Clipboard