[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Bug reports
. . -> [Subject]  unintended consequences from (I believe) 4.76 change #10
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
unintended consequences from (I believe) 4.76 change #10

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Posted by Fiendish   USA  (848 posts)  [Biography] bio   Global Moderator
Date Mon 18 Jul 2011 08:32 PM (UTC)  [ quote  ]
Message
Change 10 in MUSHclient 4.76 says
Quote:
If the mouse is over a hotspot after it was created then a mouse-move event is generated. Previously a newly-created hotspot was only noticed when you moved the mouse.


This was done because of http://www.gammon.com.au/forum/?id=11197

Except now there are far worse problems because it's not just the mouseover callback firing, but rather an entire mouse-move event happening any time a hotspot gets created. It looks like every time a trigger fires in any plugin the mouse position gets reset, which manifests in the following way:

I have a simple resizable miniwindow, like in this picture https://aardwolfclientpackage.googlecode.com/svn/trunk/wiki_images/ascii_map1.png

/While/ I am dragging the resizing tab, if any window updates its contents it does terrible things.

First, if as a result of the mouse-move the current miniwindow recreates hotspots (which then calls mouse-move again) then this obviously causes an infinite loop in the window (this happens in my chat capture window plugin, for example). But it also appears that if any /other/ miniwindow creates hotspots then the stored mouse position can get messed up which makes the window that is currently being resized jump around each time.

I originally was looking for /only/ mouseover callbacks to fire, which I think would solve these problems.
http://aardwolfclientpackage.googlecode.com/
[Go to top] top
Posted by Nick Gammon   Australia  (18,769 posts)  [Biography] bio   Forum Administrator
Date Reply #1 on Mon 18 Jul 2011 08:42 PM (UTC)  [ quote  ]
Message
Yes, but...

The mouseover callbacks are supposed to be paired, that is you get a mouseover followed by a cancel_mouseover. The function that I called (which happens on a mouse move) should have kept the original integrity, that is it cancels any previous mouseover, and starts a new one, etc.

Let's say for example you created a hotspot in response to a mouse-down, then the mouseover should not be generated because we are currently mousing-down.

Quote:

First, if as a result of the mouse-move the current miniwindow recreates hotspots (which then calls mouse-move again) then this obviously causes an infinite loop in the window (this happens in my chat capture window plugin, for example).


Well you wanted a mouse-move generated when you created a hotspot so I supposed you might expect that.

Quote:

I originally was looking for /only/ mouseover callbacks to fire, which I think would solve these problems.


I don't see how that fixes the problem of the loop.

Would it help if there was an extra test? That the extra code is only executed if the mouse is (thought to be) over the newly created hotspot (rather than unconditionally)?
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Nick Gammon   Australia  (18,769 posts)  [Biography] bio   Forum Administrator
Date Reply #2 on Mon 18 Jul 2011 08:43 PM (UTC)  [ quote  ]
Message
I think it is a bit of a design flaw, to make it so that if the mouse moves, you create a hotspot, the hotspot being one that detects mouse moves and recreates itself.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Nick Gammon   Australia  (18,769 posts)  [Biography] bio   Forum Administrator
Date Reply #3 on Mon 18 Jul 2011 09:14 PM (UTC)  [ quote  ]
Message
Would it help if I made it impossible to create hotspots in a mouse-move event?

One problem is the issue of "which mouse position?".

If the mouse is moving fast we have at least 3 positions:


  1. Where the mouse was when the mouse move event was generated by Windows.

  2. Where the mouse is when the mouse-move plugin callback is called.

  3. Where the mouse is when you call WindowAddHotspot.


They could all be different positions.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Fiendish   USA  (848 posts)  [Biography] bio   Global Moderator
Date Reply #4 on Tue 19 Jul 2011 12:24 AM (UTC)  [ quote  ]

Amended on Tue 19 Jul 2011 01:35 AM (UTC) by Fiendish

Message
Nick Gammon said:
Well you wanted a mouse-move generated when you created a hotspot so I supposed you might expect that.

I don't want a mouse-move generated when a hotspot is created. I don't actually think that generating a mouse-move is correct or appropriate, because the mouse may not in fact be moving. It is the hotspot that is moving rather than the mouse, which is why I think that /only/ onmouseover should be called (if appropriate).

Quote:
Would it help if there was an extra test? That the extra code is only executed if the mouse is (thought to be) over the newly created hotspot (rather than unconditionally)?
I don't know, maybe, but see above.

Quote:
I think it is a bit of a design flaw, to make it so that if the mouse moves, you create a hotspot, the hotspot being one that detects mouse moves and recreates itself.
My understanding of the current problem is that this is not actually what is happening. In fact, I don't think that that's even possible, since hotspot creation tends to delete callbacks. It looks like the mouse-move event is happening even if an entirely different miniwindow creates hotspots.

Quote:
One problem is the issue of "which mouse position?".
All I know is that with 4.75 all of my resizing works great. And in 4.76 if any miniwindow other than the one I'm trying to resize updates its hotspots because of a trigger firing the resizing gets screwed up.
http://aardwolfclientpackage.googlecode.com/
[Go to top] top
Posted by Nick Gammon   Australia  (18,769 posts)  [Biography] bio   Forum Administrator
Date Reply #5 on Tue 19 Jul 2011 06:37 AM (UTC)  [ quote  ]
Message
I seem to have done a couple of things wrong there.

The code for generating the mouse-move was using the wrong mouse coordinates which would tend to explain what was happening to you. That is fixed in version 4.77

Also code to detect infinite loops was added. Dropping that on top of your Aardwolf build it seems to work OK now (without any code changes on your part).
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

1,029 views.

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Internet Contents Rating Association (ICRA) - 2K]    [Web site powered by FutureQuest.Net]