Forums Bug Reports Several miscellaneous bugs (7.17)

(1) /logview windows default to being Desktop windows, and to being Always On Top. I'm assuming that like all other mIRC windows, they should default to neither. (If it matters, I'm experiencing this behavior under XP SP2.)

(1b) The /logview windows' Desktop option is greyed and cannot even be changed to begin with. See http://img141.imageshack.us/img141/5302/mirc2.png

(2) /logview windows show timestamping even if it is disabled in ALT-O > IRC > Messages > [ ] Timestamp events. (I previously reported a similar bug where reloaded log files in regular channel/query windows showed timestamping even when [ ] Timestamp events was unchecked, and you fixed that. So I'm assuming you would consider this to be a bug as well.)

(3) /logview windows do not properly handle lines with alternate default colors (those with 0x03[##[,##]] control codes at their absolute starts, even before the [time:stamps]). Specifically, any instance of CTRL-O on such a line changes all text afterward to color #1, not to the alternate default specified at the start of that line's logfile line. Example: http://img266.imageshack.us/img266/3448/mirc0.png (text file viewer) vs. http://img827.imageshack.us/img827/1289/mirc1.png (mIRC window). This happens to any line with an alternate default color, including part and quit lines, etc. (Note: this incorrect handling does not exist with reloaded log lines in regular channel/query windows. It's only affecting /logview windows.)

(4) Lines long enough to wrap in channel/query windows are displayed with a few hard spaces of left-side indentation following each wrap. This indentation, however, is missing from reloaded logfile lines in channel/query windows. (Note that indentation is NOT missing when logs are loaded into /logview windows.)

(5) The Log File dialogue's screen position is not accurately remembered by mIRC. If you exit it by hitting [ESC], or by tabbing to the [OK] button and hitting [ENTER], then the next time you open it, its horizontal position will be almost where you left it, but its vertical position will be near the top of your maximized mIRC window no matter what. On the other hand, if you exit it by mouse-clicking [OK] or [X], then not only will its vertical position always be moved back up, but even its horizontal position will be very different (it will appear much further to the right than where you left it).

(6) The /logview window can have its font changed, but mIRC doesn't remember that setting when you next open a /logview window. (In fact, its Font dialogue looks like this -- http://img27.imageshack.us/img27/1227/mirc3.png -- shouldn't the greyed checkboxes not be greyed, and shouldn't the top one read "Set as default for log viewer windows"?)

(7) Heh, the /logview window lets you control Logging (see http://img141.imageshack.us/img141/5302/mirc2.png again). Is this a mistake?

(8) Press ALT-Q in a channel window repeatedly (but don't hold it, because the effect won't happen in that case) and you'll see a color flickering effect in the second editbox when it is goes away. (It's almost as if your source code is doing two "clear screen area" commands in a row, once with an unwanted color and then with the correct color.) Anyway, this may seem minor when mIRC windows have white backgrounds, but when they have black backgrounds, it stands out a lot more.

Note: I have also posted a handful of suggestions in a separate thread.

None of these are actually bugs. All of your reports seem to stem from your lack of understanding of what the log viewer is. The log viewer is nothing but a Notepad.exe with control code support. It does not specially handle lines-- it does not understand timestamps, it does not understand wrapping, etc. It is just a custom window that is /loadbuf'd with the contents of a .log file. You should be comparing the behaviour to a custom window, not to the original channel buffer.

(1) A default window behaviour is not a bug. Given the functionality of the log window, a desktop window makes sense-- "on top" might not be a sensible default *to you*, but that does not make it a bug.

(1b) Similar to ^. This is not a bug. The log viewer is a desktop window, period. This is intentional.

(2) This is not a bug. Again, you are loading/viewing a text file, you are not reloading the text into a channel buffer. The log viewer is just a simple "notepad" style log file viewer, it treats everything as regular plain text.

(3) This is how ctrl+o works, it is not a bug. //echo -a <ctrl+k>4hello <ctrl+o> world will get you the same result.

(4) Wrapping behaves as it does in any custom window without using default echo switches: //window @test | echo @test $str(x x, 100)

(5) The log file dialog is not remembered at all here, regardless of how you close it. Open the dialog, drag it over to the right side of your screen and close it any way you want. The next time it opens it will be in its default location again. This seems intentional to me, and not a bug. Most option/setting dialogs are not remembered anyway, so I'd be surprised if this dialog was.

(6) Again, the log viewer is a custom window. It behaves as a custom window, including font selection. You cannot save fonts for any custom window: /window @test, and look at the font dialog. This isn't a bug.

(7) Again, custom window, so it behaves like one and inherits all of the functionality of a custom window, including logging.

(8) I can confirm this, but minor flickering is fairly normal when things open and close

To summarize: all of the log viewer functionality is equivalent to the following script:



Therefore, the viewer is functioning as intended. Perhaps you were intending the viewer to be a more complete recreation of your channel buffer, but this is not the case. In the future, that might happen-- but that is not what it is currently doing. Khaled might take note of this post for improvements to the log viewer, though he probably already knows how basic it is, and I don't think he ever intended it to be a full log viewer implementation (it was only added as a replacement to running notepad.exe as was done in previous versions).

I don't share that opinion. It is a bug for me too as long as there is no possibility to disable this annoying "always on top"-behaviour as default for the logviewer. Am I missing an option for that? I have tried to disable it by removing the checkmark of an open logview-window, but next time it is back. I have "Open windows on top by default" disabled under Display=>Options which does (intentionally?) have no effect. Either way there should be an option to get rid of that "always on top" if desired. I don't mind if it stays the default for new mIRC installations but it needs to be adjustable for the user somehow as this obviously is annoying for more than one person out there.

That's not a BUG, that's either a design flaw (at worst) or a preference choice (which may never be resolved). just because you can't make it not have sole focus doesnt mean it isnt working properly. Furthermore, just because it can't do what you want doesnt mean it's a bug.

*gnarf* I'm not going to discuss if it should to be called a bug or not. For some bug-tracking-systems for instance this would be an "enhancement bug". Call it design-flaw or whatever you like, this doesn't matter at all. It's a deficiency/shortcoming that should be fixed, period. :-|

If you feel it's an "enhancement bug" (which isn't a bug, but those trackers don't have any option to include other things besides bugs), then it is a feature request for that forum.

As to whether or not you feel it should be fixed, that doesn't make it wrong. I'm sure you could find a lot of things that you personally would like to be different in mIRC that have no option to change. And there will be others who disagree with you and feel that it shouldn't be changed. It's all a matter of preference and as such, it's up to Khaled whether or not he thinks there is any reason to change it.

Personally, having an on-top setting for it doesn't sound to me like something worth spending time on. It's extremely minor. And you can easily get around it by using a scripted log viewer and sticking as many features and options into it as you want to. It's not very difficult to script a log viewer and there are likely a few out there already that are good.

That said, the current log viewer is a new addition and new additions are often fleshed out over time. Additional options or features may eventually be added to it. That's what the feature request forum is for. It lets Khaled know what features you'd like added and then he decides from there what he wants to add and when he wants to add them.

The reason there is discussion here about why something isn't a bug is because clogging a bug forum with feature requests has 2 noticeable problems. First, it makes it more difficult to find actual bugs that need to be fixed. Second, when Khaled is looking for features to add, he won't be looking in this forum for those features and they can be missed. Too often, people misuse the term BUG because of a false understanding of what it is. Quite simply, a bug when related to software is something that is not working as intended by the software developer. If it was intended, then it's not a bug regardless of whether or not it's a good thing or a bad thing. If there was an option to disable the on-top setting and it didn't work, *then* it would be a bug. Because it wasn't put in there, that means it's working as intended and any request to change how it works should be in the feature request forum, where it will be seen.

Quoting Riamus but replying to OP:


And given that the current log viewer is represented by the one liner given above, it's extremely easy to get a working script that has the equivalent base functionality and add extra features from there on. Note that the one liner doesn't have the on top setting by default, so that's already a big win for you, apparently.

In addition, given that the the log viewer seems to be going in the direction of a custom window script-- there is basically nothing the log viewer can or will have that you can't script yourself (or a third party script can't provide). Conclusion: until the log viewer is no longer implemented as a custom window script, there's no reason not to write/get a script that does what you want, because that's all the current log viewer is anyway.

A bug is not something that you personally find "annoying". A bug is defined by unintended behaviour. In this case, I see nothing that would suggest this behaviour is unintentional-- actually, the fact that it ignores the default behaviour implies that it is in fact intentionally opening on top. You might not like this (and it might be wise to respect the default behaviour), but I don't see this as a bug.

By the way:



Removes the on top setting of the log viewer, since it really is just a custom window. Unfortunately you can't attach this command to ON OPEN because it does not trigger for custom windows (related feature suggestion here), but you could use a timer, or have a key binding.

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.

(3) is still not a bug. You're misunderstanding how the log viewer works. Again, you have to compare this behaviour to:



put the two colored lines in FILE.log and load it:



You will see that it stops coloring both lines. This is the behaviour you should be expecting.

Again, the window is simply reloading lines of plain text. There is no difference between a control code at column 1 or column N, because they are just colour codes being applied to text. The log viewer has no understanding of the column difference because it has no understanding of a "log format"-- it's just loading plain text that happens to have control codes. In this case, the files it loads happen to be log files, but there's no such requirement. I'm not sure how I can make this any more clear.

(5) I looked at this behaviour again. It's popping up over your mouse (horizontally)-- it's not remembering a specific position. The only reason you're reproducing this is because you aren't moving your mouse. The popping up over your mouse thing is definitely intentional.

Regarding your gripe about expectations: mIRC had no log viewer until ~7.11 (in 6.35 and earlier it was notepad.exe). Most users don't really have any specific expectations about the behaviour of a log viewer in mIRC, since it previously had no such functionality, so it really shouldn't throw anybody off. Regardless, the behaviour of a log viewer should not be compared to the regular channel buffer anyway, which is what you're doing. a "LOG VIEWER" is something that views text (go download any "log viewer" application and you'll see the same thing)-- it is not meant to accurately recreate your buffer. Colours, timestamps, etc., are simply displayed as logged in the file, and have no more special meaning as they did in your session. The log viewer is simply showing you the text that was written to the log-- exactly as it was written to the log. This is what anybody should expect a log viewer to display. I don't see any of this as "broken" even without the custom window script functionality. My expectation of a log viewer is just what Khaled implemented it as: notepad with control code parsing. I would expect this from a log viewer in mIRC just as I would expect this from a log viewer in MSN, or a log viewer in any other program that logs my interactions.

And I'm not sure how I can make it any more clear than this:



1) CTRL-O in both the topic and action lines is broken in /logview but not in the channel window
2) CTRL-O only works properly in both windows on the line that features the red text.

All you seem to have made apparent in your response to me is that the origin of this bug lies in how loadbuf reads log files. That's fine, but even then, it's still a bug by virtue of the fact that loadbuf, then, isn't taking account of the rules of mIRC's logfile coloring system -- where if the first thing (excluding a timecode) mIRC sees on a line is a color code, then that color code shall not only affect any text following it but become the line's default color (the color CTRL-O produces on that line).

Which technically means this bug goes beyond /logview and affects any custom window /loadbuf loads color-coded logfiles into.

Please understand: I understand what your point technically is -- that loadbuf has no awareness of the "alternate default line color" signaling method mIRC's logfiles employ. My point however is that mIRC's author gave loadbuf the obligation to understand that signaling by virtue of choosing it to be what fills /logview windows with logfile text. (Because presumably he wouldn't waste time making a log viewer for showing logs in color yet which couldn't show them in color correctly, right?) And the very fact he overlooked modding /loadbuf to understand that signaling ... that oversight itself ... is a bug.


Ah, very well. I would never have noticed that. (5) is in deed obviously no bug then.


You're making this an issue of users' "expectations about the behaviour of a log viewer in mIRC", when I brought up (1), (1b), (2), and (6) in the context of their expectations of text windows in mIRC. And as for (3), I would think the expectation would be that colors not appear broken in /logview compared to how they originally appeared while chatting live. If logs reloaded in channel windows can appear exactly as they were colored while chatting live, there's no reason they shouldn't in /logview. If they are colored differently in /logview windows than they were colored while chatting live, that's what your average person (me) would submit as a "bug report" ... regardless of any the hair-splitting semantics pertaining to the ultimate cause and nature of it.

Sigh. 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.

The problem here is not that "loadbuf has no awareness of the "alternate default line color" signaling method mIRC's logfiles employ" (I never stated that), it's that there is no such thing as an "alternate default line color". You're making this concept up.

As I've pointed out a few times now, mIRC is displaying the text in the file as it should display if it were a plaintext file. Like if it were your grandma's muffin recipes, or a text file or Yo Mama jokes. The "log file" viewed by the log file viewer doesn't even *need* to be a log file-- it could just as easily be your 3rd grade book report. There's no concept of "parsing as log file" here- it's just text. You claim to understand this, but you don't really.

The color code you're seeing at the starting column of some lines is not some magical "alternate line color" marker.. it's simply written by mIRC when running /savebuf on a window. Once it is written to the text file is becomes nothing more than a regular control code. mIRC does not have a "log file format", and does not write out enough information to .log files to be able to recreate them exactly as they were displayed in your window.

Specifically, mIRC can't differentiate between the following scripts:



And:



(<ctrl+k> and <ctrl+o> are the control codes)

Both of these scripts will log as the following:



However, the second script will show up in the log viewer exactly as it looks in the channel buffer-- that is, the ctrl+o WILL override the "line colour" in the case of script #2. mIRC, however, will still log them both the same, because there is no way to log it any other way. The only way to preserve information of a "default line color" (as passed in by /echo N ...) would be to create some alternate log format using XML or something more involved than a simple line-by-line text file. Until that is done, the only way to properly parse the text in the file is to not parse any codes as "default line colours".

Another way to solve this problem would be if mIRC did more than just put a <ctrl+k>N at the start of a line that had a specific line colour attached to it. It would have to also look for any ctrl+o or ctrl+k's in the line and insert a <ctrl+k>N to restart the colour if it was ever stopped midline. For instance, with the above script #1, the above text would have to be saved as:



Note that this still means the viewer would not need to change, because it is doing the right thing already (ie. the viewer is not buggy)-- the log writing would have to be improved. You can feel free to suggest that this be improved. Of course, this adds plenty of parsing complexities that don't really make it worth it and would probably slow down logging performance a fair bit. It would also bring in the issue of messing with the integrity of the original message, since you could no longer tell if the user added those control codes, or if they were added by mIRC. That might in fact be important for debugging. And it would of course not apply retroactively-- the logs mIRC already wrote with this old format would still display as you see it now (and that's how they should display).

While this is true, I believe it'd be preferable in general to have lines of the first type replicated correctly in the log file viewer and lines of the second type replicated incorrectly -- instead of the current behavior (the other way around). My argument for this is that lines of the first type are much more commonly found in a typical log file. The second type generally only appears as the result of a user's (poorly) scripted output.

The scripts are there to illustrate the principle, not to be judged. It doesn't really matter which script is better, the fact is this:

The log viewer, as currently implemented, is meant to display what is in the log file as if it were plain text. I see nothing wrong with this principle, since it is equivalent to what mIRC used to do when it delegated to notepad.exe.

If users want the log viewer to be a more accurate representation of the original channel buffer, so be it-- request that. The current implementation, however, is not buggy, broken, or flawed. It does exactly what it is supposed to do, and that is: it shows you what is in your text files (text files that happen to have IRC logs in them).

Personally, I'd rather it behave in its current form than try to accurately represent the original buffer. That way, when a line has control codes in specific places or is coloured in a certain way, I know that these control codes are located in the file, and mIRC didn't just magically recreate them. Ultimately, I use a log viewer to look at a raw archived file for the contents of the file, not for the purpose of recreating an IRC experience. I have channel windows for that.

^o or $chr(15) resets the text to the default color and style based on the event. That is you choose to color an event blue, then it has some red bold text, $chr(15) reset's it back to plain blue.

This has been standard for a long time.

Also, mIRC should display logs accurately. To not do so defeats the purpose of providing a log viewer.

That is true, but when it's saved to a log file, it is no longer an event. At that point, it's treated as Normal Text and Ctrl-O will convert it to Normal Text color because it doesn't have any idea if it's part of an event, an echo, an error message, etc. Just because a line starts with a color code followed by * doesn't mean it's Action Text. It could very easily be a custom error message or other description and a Ctrl-O in that line may very well be meant to change back to the Normal Text color and not back to the color at the beginning of the line.

To accurately display the log, the logs would need to have some kind of "header" on each line that tells the log viewer what kind of event it is. That or mIRC would have to "fake" the codes by changing a Ctrl-O on the line to Ctrl-O followed by the correct Ctrl-K to match the event. That would mean the log files are incorrectly saved (they are saving information that was never there in the first place). I'd rather not have log files faked like that just to make them display "correctly" in the log viewer.

Actually, I just tested the two example scripts that argv0 gave in this thread. They don't generate identical lines in the log file. The second one will get a real timestamp added in-front of the text. Interestingly, as long as timestamps are enabled for log files, there is no collision and it is always possible to determine what the original line color was (because user colors won't appear in front of the timestamp added to the log file). It is still true that there is some collision if timestamps are disabled, although again, I doubt many people turn them off (they are on by default). So again it becomes a matter of making it appear right for the majority of cases instead of being overly concerned about the possibility that collision can occur.

I also think it's important to emphasize that, with the exclusion of scripts, mIRC always uses line color to display messages. So with a default installation, there won't be any collision even if you turn logging timestamps off.

Consider that there is essentially only one reason to display the log file in mIRC instead of opening it with Notepad -- to allow mIRC to parse control codes. So, the fact that mIRC moved AWAY from using Notepad, to me, is an indication that Khaled does not want to treat log files as simple plain text anymore. (Control codes would not be parsed at all if it was treated as plain text.)

I don't think this is the case. Remember that in 7.0x, log viewing was removed completely and the behaviour was delegated to Windows explorer. It was Khaled's original intention to remove log viewing completely. I think upon multiple requests, he added the viewer back, specifically because Windows search is inefficient and bad. So his intention of adding it back was specifically for the search functionality, not viewing. I think that viewing was hacked together after the fact, I'm not sure there was any rhyme or reason to not just using notepad.exe. I doubt colour support was "the reason" this change was made-- IMO it seems more like a side effect of using @windows.

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:


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


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.

I am tempted to bring up Ircle's original color specification that used unique characters to identify events, rather than colors. Hence this problem was not an issue.

Codes 16-98 are unused. This would be a smart way to use them. That or log events "raw" like colloquy.

That could work, but the problem with using 16-98 is that it prevents those from potentially being used in the future for additional colors. Of course, Khaled may decide to use some other method for additional colors or may decide never to add any more colors. In either of those cases, 16-98 would be fine to use for anything else we need.