Forums Bug Reports fline wrap bug

ok so i made a script to read my zonealarm firewall logs and put them into a @window .. kinda like tail -f in linux .. it also puts in [resolving] into the echo .. then dnses the ip and uses $fline and /rline to replace the [resolving] with the resolved host

since the hostname could be big i wrap the echo with -i2

ok so if the whole echo and the [resolving] part fits onto one line and not wrapped it works fine

but if [resolving] is wraped to the next line, indented and i do $fline(@bleh,*217.184.100.255:* *[resolving]*,0) it returns null because the [resolving] is wraped to the next line.. but if i maximize the window and make the line fit on one line itll work

heres what the line looks like
[05:29:00pm 05/10/03] IN/Block UDP 217.184.100.255:1025 -> 165.247.33.255:137 [resolving] netbios-ns


you can test for youself by making a window ..

//window @bleh | echo -i3 @bleh [test1] [test2] [test3] [test3] [test4] [test5] [test6] [test7] [test8] [test9] [test10] [test11] [test12] [test13] [test14] [test15] [test16] [test17] [test18]


then resize mirc or the window so [test12] gets wrapped to the next line then do //echo -a fline: $fline(@bleh,* [test12] *,0)

now maximize mirc or the window so [test12] fits on the first line and do //echo -a fline: $fline(@bleh,* [test12] *,0)

Reproduced here..

Also, when testing it like you did, I've noticed that if you don't focus the window (ie. using the -n switch on /window) before using $fline, it works.. but if you focus the window before using it, it won't work unless "[test12]" isn't on the wrapped portion of the line.

I thought that maybe this happened because you used /echo instead of /aline, but it happens using /aline too.

Quick Question, did u use /echo -i3 becuase /aline -i doesnt seem to work (well not for me)?

Anyway, i came up with a solution for ya
/fline.fix {
$iif($window([ $1 $+ .fline.fix.unwrapped ]) == $null,window -hn [ $1 $+ .fline.fix.unwrapped ])
filter -cww $1 [ $1 $+ .fline.fix.unwrapped ] *
var %temp = $fline([ $1 $+ .fline.fix.unwrapped ],$2,$3 $+ $iif($4 != $null,$chr(44) $+ $4))
close -@ [ $1 $+ .fline.fix.unwrapped ]
return %temp
}

Just replace any of the problem $fline with $fline.fix, its not a perfect solution as its prone to falling over if u send it junk.

It simply sends your window text out to another window (not wrapped) and then does the $fline on that.

I did some tests on a 2500 line window using 100 $fline's on that, the $fline took 5.5 seconds (0.055 secs each) the $fline.Fix took 19.5 seconds (0.195 secs each), not to bad considering what its doing.

I well say you might want to look at rewriting your script to use a hidden window to initially process the lines then output them to a wrapped window, becuase that well work on its own,
BUT also becuase when i created the same 2500 line window with no wraping text (/aline @bleh) and did 100 $fline's it only took 0.2 seconds (0.002 each), which is CONSIDERABLY faster than either my fix idea or the original $fline on wrapped text

PS: wrapped indented text copies (/filter's) out to a new window funny, theres the extra spaces of the indents in there still.

The same thing happens with /findtext (and the Ctrl+F dialog)

(This is an addition, not a comment on the what you reported)

/aline -i works, but you have to include the -p switch so it will wrap.

oh well at least i have something for breakfast now.
I can eat the egg on my face for missing the -p