Forums Bug Reports Several miscellaneous bugs (7.17)

I think you're missing the point by virtue of looking at these issues from a programmatic "how mIRC works under the hood" standpoint rather than from the average user's perspective. Unless mIRC's only audience today is script developers who've become as familiar with mIRC's inner workings as you and Khaled are, the average user won't take anything remotely like your POV into consideration. And while that POV may be completely correct from a programmatic standpoint (i.e. that none of my /logview-related items are bugs in the sense that /logview is just an alias for //window -dk0 @logviewer | loadbuf @logviewer FILE.LOG), the average user certainly isn't going to know that, or even consider it. The average user is instead simply going to see A Window which he interprets as nothing more than "The Log Viewer Window Thingy", yet which:

(1) forces itself as a desktop window
(2) won't obey his timestamp visibility setting
(3) breaks CTRL-O on specially-colored lines
(6) doesn't remember his Log Viewer font setting
(7) boasts a logging on/off control in a window where such a function is inherently non-sensical

I personally have written my share of elaborate mIRC scripts yet even I'm only now learning that /logview is only a Custom Window -- from you. So if I as an intermediate scripter didn't realize this, imagine how unlikely the gazillions of average users out there are to realize it themselves.

That said:


I wasn't claiming that default behaviors were bugs, and I definitely don't consider default behaviors which don't personally suit me to be bugs either. (?!) The reason I interpreted the log viewer's "desktop window + always on top" behavior as a bug is because the log viewer window resembles all of mIRC's other text-bearing window types (query, status, DCC chat, channel, even custom windows without the optional -d switch), yet its default behavior differs from theirs. In other words, the /logview window's default behavior didn't strike me as a bug because of what it is; it struck me as a bug because it deviated from the expected standard in default behavior for all other text-bearing mIRC windows just like it. And while that could have been the author's intent, it just as easily could have been his oversight. Which is why I brought it up. Bugs aren't only things that result in GPFs.


From the perspective that /logfile is an alias for //window -dk0 @logviewer | loadbuf @logviewer FILE.LOG, then I completely agree with you.

But that's only because I know this now. The other 99% of average users don't, and are going to ask themselves why The Log Viewer won't honor their timestamp visibility setting.


Nope, it definitely is a bug. According to my understanding of mIRC's log file format, there are two ways a log file line can bear color:

[00:00] <^K>4* One of those ways is like this, where the first color code which exists is NOT at the very start of the string
<^K>4[00:00] * And the other way is like this, where the first color code which exists IS at the very start of the string

Of the above two methods, yes, the first is equivalent to the example you gave (/echo -a <ctrl+k>4hello <ctrl+o>world). But the second is not equivalent to your example. The second is instead equivalent to /echo 4 -a hello <ctrl+o>world. In that case, the word "there" would appear in red, because with this kind of echo statement (/echo [color]), you are defining an alternate default color for the line (essentially, you are not only defining the line's starting color but what color CTRL-O will result in).

That said, in my original description for (3), I was very careful to point out that I was specifically talking about the second case (alternate default line colors). I even provided two screen captures (http://img266.imageshack.us/img266/3448/mirc0.png vs. http://img827.imageshack.us/img827/1289/mirc1.png) to show the problem visually. Anyway, since a color code at the very beginning of a logfile line not only tells mIRC that it has an alternate default color, but what that color is, then it's definitely a bug when that line's alternate default color is not brought back by CTRL-O in /logview.


I wasn't reporting a /logview window bug here. I was reporting a channel window bug. Read it again.


Well, it is remembering the log file dialogue's position for me. It's just not remembering it "well." I can hit the keystroke sequence ALT-T + E + ESC five times in a row, and the log file dialogue will re-appear in the same place each time; but then, if I move it with my mouse to the other side of my screen and then do ALT-T + E + ESC five more times, it remembers that new location (roughly) all five of those times. The problem is simply that it doesn't remember that new location exactly (and it doesn't remember it at all in the vertical domain).

So this is a bug in the sense that there appears to be some kind of window location memorization attempt happening ... but the attempt is failing. Either the memorization should be fixed, or the "broken" memorization code should just be removed so that it does what you suggest (so that it opens in the same location each time, no matter where you left it the last time).


Fine, understood -- but again, only now that I understand that /logfile is an "alias" for //window -dk0 @logviewer | loadbuf @logviewer FILE.LOG. Again, to the average person who sees these behaviors happening in The Log Viewer (not in Something That's An Alias For A Custom Window And All The Behaviors Associated Therewith), I think these will appear to be bugs. They certainly did to me.


Maybe if you still use a CGA monitor and don't run FlickerFree? Otherwise, flicker only happens if there are source code statements to generate it. That said, Khaled is a damned meticulous programmer --> damned meticulous programmers usually like squashing "incosmetic" glitches like this --> I took the time to bring attention to it.

Anyway, just one last thought here. Now that I understand that /logview is just a Custom Window, yes, I can see how (1-2) and (6-7) are not bugs in the technical sense after all. And that's fine enough. But it's still a bit concerning when every response I see here to those items is overwhelmingly from people "so deep into the minutia" of mIRC internals that, while technically correct in their analyses of them, they're evidently not appreciating how such things can be seen as "broken software behavior" by outsiders/average users. mIRC's viability as a product depends on its interface intuitively clicking for and thus appealing to and impressing everyone, not just its guru userbase. While I take back my reports of (1-2) and (6-7) as "bugs," I still would have brought them up in the Suggestions area had I known earlier about the /logfile=alias angle.

(3-5) are still bugs, though, and (8) is there just in case the author wants to squash it in the meantime.