Originally Posted By: argv0
The colours are displaying correctly. What you see in the window of your screenshot is the expected output for that line of text. Again, comparing what you see to your channel buffer is completely invalid and useless, because the log viewer is NOT a replacement for your channel buffer.

You keep returning to the fact that loadbuf-populated custom windows and channel windows aren't the same thing. As I have repeatedly said, I now understand that.

The issue I have been trying to explain is unrelated to their being different. It is that one of them interprets mIRC's CTRL-O control code differently than the other, thereby breaking the correct behavior of mIRC's CTRL-O control code, that breakage itself being the bug.

The correct behavior of CTRL-O is to undo bold/italics/underline/reverse and to restore the color of all text proceeding it to the natural, "default" color of the line that it is a part of.

In mIRC, a line's default color is the color that is assigned to its event type in ALT-K.

All that being said:

When writing a non-"Normal text" event line to a log file, mIRC makes a record of its event color in the log file itself. It does this by recording its color at the absolute start of its line, in the form of a conventional ^K control code.

Later, when reloading that line from that log file, the mere presence of that ^K control code at its absolute start will of course cause that line to begin with exactly the same event color that it originally bore. And no, there is nothing "magical" about this itself, I agree.

But in a simultaneous yet separate and unrelated "magical" action while reloading that line from that log file, mIRC will also parse that line to determine whether (timestamp aside) the first thing on it is a ^K control code. If a ^K control code is the first thing on it (timestamp aside), then mIRC will additionally interpret that ^K control code's color as the particular color to make CTRL-O spew whenever it is used on that line.

Meaning that when a logfile line begins with a ^K control code, that ^K code is not only simultaneously a dumb color change instruction, but also an intelligent "trigger" to mIRC (by virtue of it being the first thing on the line): a "trigger" telling mIRC that CTRL-O needs to equal its color value for the rest of the line's duration.

I am not "making up" the existence of that. I may have made up the phrase "alternate default line color," but only because I don't know the phenomenon's official name -- if it even has one. The phenomenon itself, however, is real, and I have already demonstrated its existence twice with comparative screen captures. Both of those demonstrations illustrated how the correct behavior of mIRC's CTRL-O control code is upheld when logs are reloaded into channel/query windows, but not when they are reloaded into custom windows via loadbuf via /logview.

That said, I do understand that loadbuf itself is a generic file loading function, and I am not calling its ignorance of the logfile "ADLC phenomenon" a bug. (Furthermore, I would not even suggest loadbuf be made to always treat leading ^K codes as triggers to populate CTRL-O with their values. That would screw things up for people when using loadbuf to load files other than logs.)

What I am labeling a bug is that /logview does not uphold the correct behavior of mIRC's CTRL-O control code. I.e., when Khaled chose to use loadbuf to "power" /logview, he failed to properly enhance loadbuf with the capability of dealing with the "ADLC phenomenon"; and to make the /logview command, and the Tools > Log Files > [View] button, invoke loadbuf with that capability requested of it.

The phenomenon again demonstrated: http://img197.imageshack.us/img197/4233/colorbug.png. This time I've gone even further than in my last two examples, by showing here not only that the "alternate default line color"-sensing phenomenon exists, but by showing when it occurs during the course of mIRC's logfile line reading, parsing, and window-echoing process. Specifically, based upon "1-B" vs. "2-B", it becomes apparent to us that mIRC:

(a) loads a line from a logfile into a String;
(b) strips any timecode found in String if [ ] Timestamp Events is unchecked by the user;
(c) looks at String to see if it begins with a ^K control code, and if so, sets CTRL-O's color output value to that of the ^K code's color value
(d) echos String to the window.

... in that order.

Bottom line, in an analogy sense, mIRC is currently doing this:

Code:
loadbuf {
  ; Khaled's code here
}

logview {
  /window -dk0 @logviewer | loadbuf @logviewer $1-
}

But, again in an analogy sense, it needs to be doing this:

Code:
loadbuf {
  ; Khaled's code here
  if ($1 == LogFileMode) {
    ; decide what color CTRL-O will produce based on whether (and which) ^K control code exists at the start of String
  }
  ; Khaled's code continues here
}

logview {
  /window -dk0 @logviewer | loadbuf LogFileMode @logviewer $1-
}

Yes, you could say that Khaled intended the first method, making this not a bug. But if you say that, then you're thereby implying he intended to break the CTRL-O control code in /logivew -- a function inherently designed to support control codes. smile