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