Forums Bug Reports Display bug

I have an IBM Thinkpad R51, with a touchpad that has a slightly strange (but default for my model) behaviour where-by the very right hand side of the touchpad acts as a scroll bar. Touching the touchpad on this side and moving it up/down scrolls the buffer up and down. Nothing unordinary about this. It's sensitive to speed and touch, so if I press hard and drag fast, it's bound to go faster than if I barely touch and barely drag... in fact, there's a threshold where it'll continue scrolling down/up if a certain amount of pressure is put on it. One thing I love about touchpads

The bug is movement related, so I haven't been able to pin it down until recently. Scrolling up, then moving my finger slightly to the left and scrolling down and back towards the corner again. It's very easy to reproduce, and I'm currently uploading a video that displays both the position of my finger on the touchpad and the scrollbar portion of mIRC. It seems to only apply when the cursor is over the nicklist. As a result of this bug, the frame that the mIRC buffer and scrollbar is in completely disappears (a la minimise all). I'll post the link once it's finished uploading.

edit: link to screencap

The video is quite useless.
What make you think it's a mIRC bug ?

Yes, I do think it's a mIRC bug.
1. The behaviour -only- occurs in mIRC (so I can't reproduce it by say, hovering my mouse near the right hand side of Firefox and doing the same thing).
2. The behaviour -only- occurs when my cursor is within the nicklist zone (so I can't reproduce it by say, hovering my mouse over the buffer and doing the same thing).
3. The behaviour -only- occurs when the nicklist scrollbar isn't present (so it can't scroll).

The video shows where my finger is on the touchpad. It is necessary to prove my point. Your comment was quite useless. What makes you think it -isn't- a mIRC bug?

You know you always answer with an aggressive tone ?
Anyway, you already explained clearly what you're doing with your fingers and what is happening
The video shows a little part of the mIRC's main window where we can see the grey background when your bug occurs and the fingers positions. We already knew we'll see -something like- this, same goes for the fingers positions.
So yes, the video is quite useless for me because it doesn't brings new information, but at least this post is useful :
The first one states it's only related to mIRC and the second one gave an information about how to reproduce the bug that is much much more important than the video
Again, it's not because I said that the video is useless that you have to say my post is too, or at least tell me why eh.
You didn't talk about the others programs, that's why I've asked you about why do you think it's a mirc's bug, and now we know.

I decided to record the video because it proves that I'm not a crackhead. If I hadn't recorded that video, I wouldn't know you if you'd respond with something like "are you sure you aren't accidentally clicking the minimize button?". By recording the video, and showing 3 slightly different positions, I avoided this question. If this behaviour were consistent for other programs, I would have likely reported a bug pertaining to how it doesn't work in the mIRC buffer, or anywhere else within mIRC for that matter, as I mentioned in my original post. My point was simple, though perhaps slightly subtle: one behaviour or the other, please. I would prefer the nicklist scrolls properly rather than minimizes due to a slightly off movement, because the minimize button is generally used to minimize where-as the nicklist generally scrolls up and down when told to do so.

It's not clear from the video whether the mIRC channel window is being minimized or if the window inside it, ie. the listbox, is being minimized. Either way, I cannot think of any reason why this would happen. A window in mIRC should only be hidden/minimized if it is sent a hide/minimize message by another application. The fact that it does not affect other applications does not indicate an issue with mIRC, it just means that the driver has not been designed to handle the combination of Windows that mIRC has. I've heard of similar issues with mouse/pad drivers over the years and the solution was usually to update the latest driver or to report the issue to the manufacturer.

I can reproduce another issue where, using the similar scrolling mechanism along the bottom of my touchpad (for horizontal scrolling) above the input textbox, I can cause the entire channel buffer/nicklist frame to move horizontally (while the mIRC window stays where it is). This was a bug reported a while back without steps to reproduce. I suspect the frame is -actually moving-, not minimizing. <sarcasm>Hmm strange I'm not having any problems with other software... This must be the fault of buggy touchpad drivers</sarcasm>

I am 99.99% sure it has nothing to do with mIRC :-) It sounds like the driver is confused about the types of windows that exist in the mIRC channel window and is sending scroll messages to the wrong window. That said, I tried to simulate sending a variety of scroll messages to a channel window and couldn't reproduce this issue, so whatever the driver is doing, it's pretty odd.

Here is another video. I've learnt that horizontal scrolling on the nicklist also causes the buffer/nicklist/input section to disappear (instantaneously).

Under what circumstance is it correct for mIRC to move these controls?

Thanks, that's much clearer - the driver appears to be sending scroll messages to the MDI client window (the window that contains all other windows). There is no reason why it should be sending scroll messages to the MDI client window. There are no circumstances under which mIRC will scroll the MDI client window (the MDI window has that feature by design but mIRC does not use it). My guess is that the driver either does not know how to handle MDI windows or is just confused and is sending the scroll messages to the wrong window.

The very fact that my video is a record of mIRC doing strange things with the MDI client window contradicts this:



mIRC will scroll the MDI client window when it recieves a horizontal scroll message. Under what circumstance is it appropriate for mIRC to be handling horizontal scroll messages sent to an MDI client window incorrectly?

mIRC does not process scroll messages for the MDI client window. All Window controls process standard messages by default, including scroll messages. What is happening is that the driver is sending scroll messages to the MDI client window and the MDI client window is then doing what it should be doing - if it receives a scroll message then it should scroll the MDI client area and all windows in it. This is correct behaviour and I would expect it to do that.

The question is, why is the driver sending scroll messages to the MDI Client window and not the active window with the focus. That can only be answered by the developer of the mouse/pad driver I'm afraid.

Ahh, so this IS supposed to happen. One behaviour or the other, please? In that case why did you say the following earlier?



It seems to me you have not been answering my questions, but instead making statements that contradict eachother when put into their perspective: mIRC

My questions were:
1. Under what circumstance is it appropriate for the windows to be moving around this way within mIRC?
2. Under what circumstance is it appropriate for mIRC to be handling window messages incorrectly, or not at all?

Here's my next ones:
1. Does mIRC overrides default behaviour here: the MDI window has that feature by design but mIRC does not use it? If so, then why isn't it doing a complete job of overriding the default behaviour?
2. Are there any other areas where mIRC should (and does) override a controls' default behaviour? If so, why?

mIRC overrides lots of controls default behaviour to prove features specifically for its purpose: an IRC client.

For example, pressing ctrl+b in an edit box would usually do nothing, but in mIRC it inserts a bold control code.

You seem to be trying to challenge him over nothing. You've got your answer, no?

Who are you responding to? Please modify your post to indicate this.

What Khaled meant in your second quote is that mIRC itself never sends scroll messages to the MDI client window, not that such messages are ignored if they are received. This is a distinction Khaled is making that you are failing to understand.

"Scrolling the client area" and "allowing the client area to be scrolled" are two different things.

I didn't ask for a response from you, I asked for a response from Khaled. If you are uncertain as to why a response from you is unsatisfactory, consult google for information regarding "socratic questions".

I was responding to you.

It says "[Re: s00p]" at the top of my post.

Please read the entire thread two or three times before posting, as it is clear you have no understanding of my intent behind asking Khaled that series of questions. I asked Khaled, not you. Your answer on behalf of Khaled was a contradiction and agreed entirely with my point.



Exactly, so why not override default behaviour for MDI client windows, and ensure that the behaviour will be ideal?

Because mIRC itself never sends scroll messages to the MDI client window. It's not up to Khaled to modify mIRC to fix bugs in other software. It's up to your touchpad manufacturer to fix their software to send messages to the right window.

Besides, if K disabled scrolling of the MDI child window, then people would just complain if they actually want to scroll that and it doesn't work.

The issue is with your touchpad drivers, not mIRC.

Under the circumstance of scrolling, it is appropriate for windows to be scrolled. The question should be "under what circumstance is it appropriate for the trackpad to scroll the MDI client window", and the answer, as Khaled said, is when the MDI client has focus, not when a child does. It seems that your trackpad is incorrectly sending WM_SCROLL events.. it's not mIRC's job to clean up after your crappy driver's mess, since it would break the ability to actually scroll the MDI client when you *really wanted to*.


None. mIRC handles window messages correctly (you might want to repeat that to yourself a few times before you outright ignore this fact in your reply).


mIRC doesn't override MDI client window scrolling behaviour at all, so there's nothing incomplete about what it's doing. It seems you're misinterpreting what Khaled is saying. His use of "mIRC" in "There are no circumstances under which mIRC will scroll" refers to mIRC's codebase. There is no code in mIRC which will scroll the MDI client window. However, the MDI client in mIRC *can* be scrolled by sending WM_SCROLL messages to the wrong window. This is Windows behaviour. As Khaled succinctly stated, the question you should be asking is "why is my driver sending WM_SCROLL to my MDI client window?"-- and mIRC's forums cannot answer that.


Sure. Scrolling is not one of them though, since, if done correctly, there are perfectly valid reasons to allow the MDI client to be scrolled.

mIRC never sends messages for CTRL+B, either. Nor does it send scroll messages to the input textbox window, yet it seems to have overridden that behaviour nicely. Please read the entire thread before you make another post, because you are asking silly questions.



Take a look at the video I posted. Do you think people would complain if they couldn't do that?

If the issue is with my touchpad drivers, then I should have problems reproducing this with a mouse that has mechanisms for sideways scrolling I'll find one on Monday.

In the mean time, please read the entire thread and watch the videos and consider that I'm asking for an answer from Khaled, not for dribble from you which resembles crap that I've already responded to previously within this thread.

Again, please guys. I've already responded to dribble that resembles this crap previously in the thread. When is it appropriate for windows to be moving around in such a way that they are in the videos?

I disagree. I don't think this is a driver issue at all. And I intend to prove this. Please at least keep your crap out of the thread long enough for me to do so without losing my point. You're being disrespectful.

OK, I don't need to prove it by getting new hardware. It seems I can't reproduce this error in other software that uses MDI-style windows. That is, I can't move maximised client windows around.

Right.. but mIRC interprets those messages for a purpose and places control codes into the box.

What possible reason is there for mIRC to intercept messages telling the MDI client to scroll? If something tells the MDI client to scroll then it is because that is what the software wants it to do. There's no reason for Khaled to block functionality in mIRC just to fix other peoples' buggy software.

Last post on this topic because you're clearly not understanding what we're trying to tell you.

mIRC is the buggy software here. I've tried MSVC++ 6.0 and PICAXE, both MDI applications, and I can't get maximized windows to move around like this. Under what circumstance is it appropriate for maximized MDI client windows to be moving around within their base?

You were already answered. It is appropriate for the MDI client to be scrolled if that is the user's intention.

It is inappropriate if it is not the user's intention, but this is not mIRC's fault.

Rather than blindly disagreeing or ignoring responses, why not suggest what mIRC should do to fix this. Is it your opinion that mIRC should completly disable scrolling the MDI client window? If so, that will never happen, since your "fix" will be breaking the ability for others to do exactly that: scroll the MDI client window.

I'm not blindly disagreeing or ignoring responses, you babbling lunatic. I've responded to them previously. You seem to be the one ignoring my response: None of the other applications I've tried that use MDI have this strange behaviour of being able to move maximized windows around.

You've also ignored my question: When is it (EVER) acceptable to be able to move maximized windows around within their base?

What would my fix break, the ability to scroll maximized windows around within their base? I repeat: When is it (EVER) acceptable to be able to move maximized windows around within their base?

I did answer that question. You should learn to read, it was the response to the very first quote in the previous message. I wonder how many times you expect us to answer the same question over and over?



Answer: Under the circumstance where the user wants it to happen. Clearly Microsoft thinks it should be possible, since your bug is caused by WINDOWS (not mIRC) handling the WM_SCROLL events. Unless you're going with "Windows behaviour is wrong", this is all the justification that is needed. If you're actually saying Windows is wrong, you should take it up with them.

If you don't like the answer, fine. But stop asking it over and over like a damn broken record, the answer isn't going to change.

Hixxy, what possible reason is there for a driver sending scroll messages to a textbox (eg. the input textbox)? Yet, drivers still do it, hence being able to scroll the buffer while the textbox is the active control. I'm sorry, but this isn't a touchpad bug. It's perfectly acceptable for the touchpad driver to be sending these messages.

argv, Hixxy, THINK ABOUT VERTICAL SCROLLING! IS IT APPROPRIATE TO SEND VERTICLE SCROLLING MESSAGES TO A TEXTBOX? IF NOT, WHY CAN WE STILL SCROLL THE BUFFER WHEN THE MOUSE IS OVER THE INPUT TEXTBOX?

It's perfectly fine for it to send it to the active window. It is not fine to send it to the parent window of an active window. Simply put, your trackpad is sending the messages to the wrong window.

Not sure why you're not getting that.

I request that this thread be locked and preserved as evidence of this scenario's occurence, as I'll be blogging about it today. I've said all I need to say to establish my point. You guys seem to be jumping to the conclusion that it's a "driver bug" and that drivers should not be sending scroll messages to windows that don't support them. In that case, vertical scrolling should only be allowed when the mouse is above the buffer textbox, and the fact that this isn't the case is also "a driver bug".

If my trackpad is sending the messages to the wrong window, and mIRC is failing to handle those messages correctly, then it would still appear that it's not a driver bug. This is because it only affects mIRC, and not other MDI software.

I request that this thread be locked and preserved as evidence of this scenario's occurence, as I'll be blogging about it today. I've said all I need to say to establish my point. You guys seem to be jumping to the conclusion that it's a "driver bug" and that drivers should not be sending scroll messages to windows that don't support them. In that case, vertical scrolling should only be allowed when the mouse is above the buffer textbox, and the fact that this isn't the case is also "a driver bug".

Frankly, you're the one jumping to conclusions here based on completely anecdotal evidence. Your "proof" is: "it happened in program X, therefore it's not my trackpad's fault" ... the logical flaw is obvious.

On the other hand, you feel it okay to ignore an authoritative claim from the actual developer of mIRC stating that mIRC has nothing to do with handling those messages. I'm not quite sure how "mIRC is letting Windows do what it was designed to" makes it a bug....

At what point in this thread did your claims become more than a wild deluded opinion?

Actually, I'm not. My other point agaist your argument that it's a "driver bug" is that vertical scrolling messages appear to be handled correctly. It is the horizontal scrolling messages that aren't. This is probably because of the way message parsing works: The most appropriate window is selected for the message to be sent to. In this case, this is the textbox, or the listbox. Since neither of those windows handle the message correctly, it is passed on down the chain until it is handled correctly. This is where I left off with Khaled most recently: Why doesn't mIRC be sure that scrolling messages -do not- make it to the MDI base when the client is maximized? That seems to be what's causing the issue to me. Of course, you so rudely wish to interrupt and as a result I am unable to portray this message to him efficiently. Do you really believe you're doing any favours for mIRC's user base when you allow bugs to go unpatched just because -you- don't have the resources to reproduce them?

Why must I continue repeating myself?

I request that this thread be locked and preserved as evidence of this scenario's occurence, as I'll be blogging about it today. I've said all I need to say to establish my point. You guys seem to be jumping to the conclusion that it's a "driver bug" and that drivers should not be sending scroll messages to windows that don't support them. In that case, vertical scrolling should only be allowed when the mouse is above the buffer textbox, and the fact that this isn't the case is also "a driver bug".

Did you ever think about the possibility that those programs could block those message on purpose ? Usually, User Interface software don't want you to be able to change anything about the UI, mIRC is kind of an exception, there are many dlls that let you modify the mIRC's UI and some of them even let you send messages to mIRC's windows.
If mIRC was sending this message, as you seems to think, why this problem only happen to you ? How do you explain that others never seen this ? I think you agree that every mIRC's users are using the same software, you are obviously not the only guy that has a bugged mIRC's version

In fact no, Khaled jumped to this conclusion, because he probably know better than you that mIRC isn't sending anything.

I'm sorry, but an argument that this should be allowed in case users actually want it has been stated, and I've already answered it, so I'm repeating myself again (please read the entire thread before you post). Under what circumstance do you believe it's appropriate for a maximized MDI client window to be moving around within it's base?


mIRC isn't sending this message, I never said that. The drivers are, just as the drivers send scroll vertical messages in exactly the same way. This is completely appropriate. mIRC is in charge of handling the messages correctly. If mIRC doesn't handle these messages, then Windows will. I am able to reproduce this problem because I have a touchpad/mouse that has some mechanism for sideways scrolling. Do you have such a device? Can you understand why you may never see this problem if you don't have such a device?


Read the rest of the thread, please. Khaled was clearly not the only one to jump to this conclusion.

If there is anything you guys don't understand, feel free to ask, but don't ask it in such a way that implies that I am incorrect and Khaled is correct. I find that most disrespectful.

I request that this thread be locked and preserved as evidence of this scenario's occurence, as I'll be blogging about it today. I've said all I need to say to establish my point. You guys seem to be jumping to the conclusion that it's a "driver bug" and that drivers should not be sending scroll messages to windows that don't support them. In that case, vertical scrolling should only be allowed when the mouse is above the buffer textbox, and the fact that this isn't the case is also "a driver bug".

First off, you don't really have the right to request that a "discussion be locked" just because you're too childish to back up your arguments. It seems like you're interested in making sure you get the last word, regardless if you're right or wrong. Grow up.



Because the user might WANT those messages to make it to the MDI base. Their reasoning might be invalid in your opinion, but there is no reason to deny a user functionality because your driver is broken. Instead, tell your manufacturer to fix the driver. Simple as that.

I'm requiesting that the discussion be locked because there are alot of people now crowding my attempts at proving my point directly to Khaled without reading. This is a bug report. What do you believe qualifies you to participate this conversation?
You probably shouldn't be involved in this conversation if you don't match one of these criteria:

• Do you have a touchpad and/or mouse with sideways-scrolling mechanism? If so, post a comment informing us as to whether you were able to reproduce the symptoms.
  
• Are you a mIRC developer? If not, you should be one of the above.

... and so I repeat myself again:

Under what (SPECIFIC) circumstance would it be appropriate for a maximized MDI client window to be moving within it's MDI parent? I haven't yet recieved an answer to this, and this is the question you need to answer. Can you click on a maximized window and drag it around? What happens when you attempt to use your scrollwheel in other MDI applications? If you can't think of any reasons for this behaviour, then how can you justify your statement "Because the user might WANT those messages to make it to the MDI base"? Under what circumstances might the user want a maximized MDI client window to be moving around within it's MDI parent? What user functionality depends on this behaviour? What makes you think my driver is broken? It appears to be working for every other MDI application.

You guys seem to be arguing with each other more than with me. I'm all for making mIRC a more stable product. The solution is really fairly simple: simply handle the message appropriately. All the other MDI/non-MDI applications I have tested seem to be doing a good job. I've consulted outside opinions and they all agree that, even if a driver is sending messages in error (according to mIRC), mIRC should be handling those messages correctly.

Let us analyse the progress of this thread, starting from my first socratic question:

• I asked "Under what circumstance is it correct for mIRC to move these controls?"
  
• Khaled responded "There are no circumstances under which mIRC will scroll the MDI client window (the MDI window has that feature by design but mIRC does not use it)."
  
• I stated that the video contradicts Khaled's response and asked another question: "Under what circumstance is it appropriate for mIRC to be handling horizontal scroll messages sent to an MDI client window incorrectly?"
  
• Khaled responded: "mIRC does not process scroll messages for the MDI client window." (I believe he meant horizontal scroll messages, because it does seem to process vertical scroll messages).
  
• I noted that his previous two responses contradicted each other when put into the perspective of the application in question. I recapped on my questions which I still believe haven't been answered correctly. At this point in time I would have expected these answers from a sane developer:
  1. There are no circumstances where it is appropriate for the windows to be moving around this way within mIRC. (which you guys are still debating)
  2. There are no circumstances where it is appropriate for mIRC to be handling messages incorrectly. (even if they are passed incorrectly)
  
• hixxy attempted to answer one of the questions I posed on Khaled's behalf. His statements at this stage had little impact on the progress (either for or against) of the discussion. I noted this in my next response.
  
• Collective responded to one of my questions with an answer that would have been far more useful if it were to come from the person the question was posed to. Thankyou.
  
• I noted the contradiction hixxy's response provided. On one hand his response appeared to be aimed directly to me. On the other hand the substance he provided actually supported my view.
  
• hixxy stated that mIRC isn't in charge of sending the messages and brought up the initial "but people might want this behaviour" argument (first time). I later responded that mIRC overrides several other default behaviours by handling the messages correctly, and attempted to point out how silly the behaviour observed in my second video is silly and that nobody in their right mind would want that to happen. If you notice in the video, I actually tried scrolling to the right also, and the maximized window moved left.
  
• It would seem argv0 posed a rhetorical question, with an incorrect (due to being incomplete) answer. The window message will also be passed on to the MDI client window if it isn't handled. It's not my touchpad driver's responsibility to clean up for unhandled messages. He also stated that mIRC doesn't override MDI scrolling, which is also incorrect. If this were the case, when using a scrollwheel above a textbox that doesn't have a scrollbar the MDI client should also move up and down. It is because mIRC handles the vertical scrolling for the input textbox that something different happens. Work out what happens for yourself. He posed a question which I've just answered. He attempted to answer question 2, but answered incorrectly due as he overlooked the case of vertical scrolling that is clearly overridden. I might even post a video displaying why, since I actually needed to address this just now for you imbeciles.
  
• I stated that I had tested a couple of other old MDI applications and have not yet noticed any of these problems.
  
• Hixxy posed the question: What possible reason is there for mIRC to intercept messages telling the MDI client to scroll?
  
• I answered Hixxy with the question "Under what circumstance is it appropriate for maximized MDI client windows to be moving around within their base?". Another question comes to mind: What possible reason is there for mIRC to ALLOW the messages to be passed back to the MDI client/base?
  
• argv0 attempted to answer this in an unspecific way: "You were already answered. It is appropriate for the MDI client to be scrolled if that is the user's intention." If you could come up with an actual scenario where this behaviour is appropriate, argv0, it should have been stated now. The mere fact that you're repeating yourself is a flaw in your argument. When would it be the user's intention? Would you like to be able to scroll an MDI region when the MDI clients are maximized? How would that work?
  
• argv0 attempted to answer my question: "Under the circumstance where the user wants it to happen." When would the user want this to happen? Can you provide a specific scenario that is relevant to mIRC? If not, back the fuck off and keep your jibberish in your head where it belongs. "Clearly Microsoft thinks it should be possible, since your bug is caused by WINDOWS (not mIRC) handling the WM_SCROLL events." And this is caused by mIRC passing the message on to Windows, which is a case of handling the message incorrectly, since Khaled previously stated that mIRC doesn't support scrolling. What sense does it make to be telling Windows "YES, SCROLL THIS WINDOW" when you're saying "NO, WE DON'T SUPPORT SCROLLING!"?
  
• I stated that mIRC does in fact handle scrolling (vertical scrolling).
  
• more babbling, no actual progress, does this seem repetitive to you?
  
• argv0 accused me of jumping to conclusions. Thankyou. He stated that 'my "proof" is: "it happened in program X, therefore it's not my trackpad's fault"', which not the same as: "it ONLY happened in program X, so it MUST be my trackpad's fault!" And he says the logical flaw is obvious.
  
• I attempted to point out for the zillionth time that mIRC should be handling horizontal scrolling over the input textbox in a similar way to it's handling of vertical scrolling over the input textbox.
  
• Wims attempted to raise the "but there could be a reason!" argument. THEN GIVE ME A SPECIFIC REASON! Jesus! What behaviour would you like to see, when attempting to scroll an MDI region which contains maximized MDI clients? He also displayed the inability or unwillingness to read accurately.

You're wrong. I do have the right to request that a discussion be locked, and others have the right to grant or deny it. What makes you think I don't have that right, and why are you attempting to bring this off-topic nonsense into the discussion? I'm not trying to get the last word -- I'm trying to get my point across. What right do you believe you have to be posting here in the first place? This is a bug report. You probably shouldn't be involved in this conversation if you don't match one of these criteria:

• Do you have a touchpad and/or mouse with sideways-scrolling mechanism? If so, post a comment informing us as to whether you were able to reproduce the symptoms.
  
• Are you a mIRC developer? If not, you should be one of the above.

Give me a specific example, please. I don't believe the driver is broken, as there could be other causes for this behaviour, and other programs that implement MDI seem to behave fine.

Let me summarize the issue and I will then lock the thread since it has gotten somewhat out of control.

Situation: a mouse/pad driver is sending scroll messages to mIRC and, for some reason, it is sending them to the MDI client window. The MDI client window then reacts to the scroll messages and scrolls the windows in the MDI client window. This behaviour has been reported as a potential bug.

As far as I can tell, the MDI client window is behaving correctly. It should scroll if it receives a scroll message, in the same way that the nickname list or text display should scroll if they receive a scroll message.

There are hundreds of standard messages that can be sent to the MDI client window, as well as all other controls, that could manipulate it in many other ways. An application like the mouse/pad driver could choose to reposition or resize windows, change their colors, or even hide them completely, using standard windows messages. While mIRC could choose to actively ignore and block hundreds of messages from other applications/drivers, that just would not make sense. It is up to the external applications/drivers to know what they are doing to other applications on your system.

That said, I am still open to the possibility that this is a bug in mIRC, however based on what I have read it seems very unlikely. Thanks for the feedback everyone.