Forums Bug Reports Display bug

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.