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.