Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

Entire forum ➜ MUSHclient ➜ Bug reports ➜ CancelMouseOver not working as expected

CancelMouseOver not working as expected

It is now over 60 days since the last post. This thread is closed. Refresh page

Pages: 1 2 3

Posted by

Fiendish USA (2,535 posts) Bio Global Moderator

Date

Fri 27 May 2011 06:47 PM (UTC)

Amended on Fri 27 May 2011 06:49 PM (UTC) by Fiendish

Message

WindowInfo option 19 claims to show

Quote:

Hotspot ID of the hotspot currently being moused-over (empty string if none)

Except if you call it from a CancelMouseOver routine, the reported hotspot is the one you just left rather than the one (or none) you might be in now.

It looks like my CancelMouseOver is being called before the mouse actually leaves the hotspot area. This is unintuitive behavior to me.

https://github.com/fiendish/aardwolfclientpackage

Posted by

Twisol USA (2,257 posts) Bio

Date

Reply #1 on Fri 27 May 2011 08:13 PM (UTC)

Message

I agree. In general, callbacks should be executed after relevant state has been modified, so the code has the most up-to-date view of what's going on.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Posted by Nick Gammon Australia (23,158 posts) Bio Forum Administrator

Date Reply #2 on Sat 28 May 2011 12:20 AM (UTC)

Message

I think it is done like that because this is the code that calls CancelMouseOver:


      // cancel previous move-over hotspot
      if (!old_mw->m_sMouseOverHotspot.empty ())   // HotspotId was used
        {
        // lookup that HotspotId
        HotspotMapIterator it = old_mw->m_Hotspots.find (old_mw->m_sMouseOverHotspot);

        // call CancelMouseOver for that hotspot, if it exists
        if (it != old_mw->m_Hotspots.end ())
          {
          RemoveToolTip ();
          old_mw->m_bExecutingScript = true;
          Send_Mouse_Event_To_Plugin (it->second->m_dispid_CancelMouseOver,
                                      old_mw->m_sCallbackPlugin,
                                      it->second->m_sCancelMouseOver, 
                                      old_mw->m_sMouseOverHotspot);
          old_mw->m_bExecutingScript = false;
          }
        old_mw->m_sMouseOverHotspot.erase ();  // no mouse-over right now
        m_sPreviousMiniWindow.erase ();  // no longer have a previous mouse-over
        }   // we had previous hotspot

The line in bold is where it is erased, and if that was moved up earlier then it wouldn't know which hotspot to notify is no longer active. Are you two suggesting something like this?


      // cancel previous move-over hotspot
      if (!old_mw->m_sMouseOverHotspot.empty ())   // HotspotId was used
        {
        // lookup that HotspotId
        HotspotMapIterator it = old_mw->m_Hotspots.find (old_mw->m_sMouseOverHotspot);
        
        string  sOldMouseOverHotspot = old_mw->m_sMouseOverHotspot;
        old_mw->m_sMouseOverHotspot.erase ();  // no mouse-over right now


        // call CancelMouseOver for that hotspot, if it exists
        if (it != old_mw->m_Hotspots.end ())
          {
          RemoveToolTip ();
          old_mw->m_bExecutingScript = true;
          Send_Mouse_Event_To_Plugin (it->second->m_dispid_CancelMouseOver,
                                      old_mw->m_sCallbackPlugin,
                                      it->second->m_sCancelMouseOver, 
                                      sOldMouseOverHotspot);
          old_mw->m_bExecutingScript = false;
          }
        m_sPreviousMiniWindow.erase ();  // no longer have a previous mouse-over
        }   // we had previous hotspot

It's more complicated than that because later on it also uses old_mw->m_sMouseOverHotspot but I supposed conceptually it could work.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Twisol USA (2,257 posts) Bio

Date

Reply #3 on Sat 28 May 2011 01:04 AM (UTC)

Message

Close, but instead of clearing the currently moused-over hotspot, instead set it to the hotspot (if any) that the mouse is currently over. Conceptually, that means moving the whole CancelMouseOver section to after the hotspot is updated.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Posted by

Nick Gammon Australia (23,158 posts) Bio Forum Administrator

Date

Reply #4 on Sat 28 May 2011 01:34 AM (UTC)

Message

Bearing in mind what I said about needing it for the callbacks. So perhaps this:

Remember current hotspot name in old miniwindow, if any old miniwindow.
Remember current hotspot name in new miniwindow, if any new miniwindow.
Set "current hotspot" in both old miniwindow, and new miniwindow (if either exists) to the appropriate value (which might be empty).
Do the various callbacks for the old hotspot (eg. CancelMouseOver) using the saved hotspot name.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Twisol USA (2,257 posts) Bio

Date

Reply #5 on Sat 28 May 2011 02:02 AM (UTC)

Message

Exactly.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Posted by

Fiendish USA (2,535 posts) Bio Global Moderator

Date

Reply #6 on Sat 28 May 2011 03:37 AM (UTC)

Amended on Sat 28 May 2011 03:39 AM (UTC) by Fiendish

Message

Nick Gammon said:

Bearing in mind what I said about needing it for the callbacks. So perhaps this:

*Remember current hotspot name in old miniwindow, if any old miniwindow.

*Remember current hotspot name in new miniwindow, if any new miniwindow.

I don't quite understand this progression, since I don't know what "current" is referring to here. But I'm going to assume that at least the first "current" here means the hotspot that is being exited rather than the one being (potentially) entered, and that the second current means the hotspot being (potentially) entered.

Quote:
Do the various callbacks for the old hotspot (eg. CancelMouseOver) using the saved hotspot name.

Don't forget the callbacks for the (potential) new hotspot (MouseOver).

https://github.com/fiendish/aardwolfclientpackage

Posted by Nick Gammon Australia (23,158 posts) Bio Forum Administrator

Date Reply #7 on Sat 28 May 2011 04:29 AM (UTC)

Message

"Current" means the one that initiated the sequence. For example:

You mouse-over a hotspot. It remembers the hotspot ID that is now the "current moused over" hotspot. This raises a "mouse over" callback.
You move the mouse onto a different hotspot. First it needs to raise a "cancel mouseover" for the current (ie. the original) hotspot ... if any. Then it raises a "mouse over" for the new hotspot (and makes it the current one). The original one had to be remembered so we could pair the mouse-over with the cancel-mouse-over for the original hotspot.

Now your complaint, I gather, is that during the "cancel the original mouse-over" handling, it hasn't switched Info option 19 to the new hotspot. You can see why it might work that way, I hope. Effectively the code is "finishing off" the old hotspot. However I agree you might not expect it to behave exactly that way.

Quote:

Don't forget the callbacks for the (potential) new hotspot (MouseOver).

Well you get that now, don't you? And I think it is correct for the new one:


      // if different hotspot from before
      if (sHotspotId != mw->m_sMouseOverHotspot)
        {
        // this is our new one
        mw->m_sMouseOverHotspot = sHotspotId;
        mw->m_bExecutingScript = true;
        Send_Mouse_Event_To_Plugin (pHotspot->m_dispid_MouseOver,
                                    mw->m_sCallbackPlugin, 
                                    pHotspot->m_sMouseOver, 
                                    sHotspotId);
        mw->m_bExecutingScript = false;

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Fiendish USA (2,535 posts) Bio Global Moderator

Date

Reply #8 on Sat 28 May 2011 04:54 AM (UTC)

Amended on Sat 28 May 2011 05:00 AM (UTC) by Fiendish

Message

Nick Gammon said:
Well you get that now, don't you?

Of course. I just thought the list looked wrong without stating it.

Quote:
Now your complaint, I gather, is that during the "cancel the original mouse-over" handling, it hasn't switched Info option 19 to the new hotspot.

Right. I think this goes likewise for some of the other windowinfo options, like X/Y mouse position. I'd want to know the position outside the hotspot. Right now it looks like cancelmouseover has been processed before the mouse has left the area instead of after the mouse has left, which is what I hope for.

https://github.com/fiendish/aardwolfclientpackage

Posted by Nick Gammon Australia (23,158 posts) Bio Forum Administrator

Date

Reply #9 on Sat 28 May 2011 05:41 AM (UTC)

Amended on Sat 28 May 2011 05:42 AM (UTC) by Nick Gammon

Message

Well I think I found a bug that you didn't. Muahahaha.

Can you confirm this?

According to this page:

http://www.gammon.com.au/mushclient/mw_hotspots.htm

You are supposed to get pairs of events, like this:


mouse-over -> cancel-mouse-over

and


mouse-down -> cancel-mouse-down OR mouse-up

But I just noticed this:


mouse-over ... cancel-mouse-over ... mouse-down ... mouse-up

So far so good. But then move the mouse out of the hotspot and get:


cancel-mouse-over

So that's an orphan cancel-mouse-over. If you mouse-down, and move the mouse out of the hotspot, you just get the cancel-mouse-down.

In fact I'm inclined to think that if you move the mouse over a hotspot, then click and release it, you should then get:


mouse-over ... cancel-mouse-over ... mouse-down ... mouse-up ... mouse-over

Because the mouse is over the hotspot, right? Then the cancel-mouse-over is no longer an orphan.

What do you think?

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Fiendish USA (2,535 posts) Bio Global Moderator

Date

Reply #10 on Sat 28 May 2011 05:58 AM (UTC)

Amended on Sat 28 May 2011 05:59 AM (UTC) by Fiendish

Message

Quote:
you should then get:
mouse-over ... cancel-mouse-over ... mouse-down ... mouse-up ... mouse-over

This is what I see already. Not sure why it isn't working for you. :\

If anything, I think it's a little weird for cancel-mouse-over to get called just because you've clicked. If I had my way, I think I'd want the progression for *move the mouse over a hotspot, click, release, move the mouse away* to be

mouse-over ... mouse-down ... mouse-up ... cancel-mouse-over

and for *move the mouse over a hotspot, click, move the mouse away, release* to be

mouse-over ... mouse-down ... cancel-mouse-over ... cancel-mouse-down

but that probably adds a fair deal of complexity

https://github.com/fiendish/aardwolfclientpackage

Posted by

Nick Gammon Australia (23,158 posts) Bio Forum Administrator

Date

Reply #11 on Sat 28 May 2011 06:32 AM (UTC)

Message

I'm getting inconsistent results now. However the code doesn't do it automatically. The mouse-up code does not generate a mouse-over. However a slight movement afterwards (or maybe a queued movement) seems to do it.

I can't really account for it. The release version seems to generate the extra call most of the time, but it simply isn't in the code to do it, on the mouse-up event.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Fiendish USA (2,535 posts) Bio Global Moderator

Date

Reply #12 on Sat 28 May 2011 06:52 AM (UTC)

Message

I doubt that it's a slight movement on my part, since I'm using a laptop and the buttons are not physically linked to the touch sensor.

https://github.com/fiendish/aardwolfclientpackage

Posted by

Nick Gammon Australia (23,158 posts) Bio Forum Administrator

Date

Reply #13 on Sat 28 May 2011 08:01 AM (UTC)

Message

It seems to sometimes do it and sometimes not for me, even if I hold the mouse still with one hand.

Anyway, I think I have fixed it (commit 5334bac), but am not totally confident. Twisol could apply the patch and see if it works better or worse than before. If you like, Fiendish, I can upload the revised executable in a pre-release form for you to test.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Fiendish USA (2,535 posts) Bio Global Moderator

Date

Reply #14 on Sat 28 May 2011 08:12 AM (UTC)

Amended on Sat 28 May 2011 08:19 AM (UTC) by Fiendish

Message

I'll be happy to test it out, though I'm a bit scared that I'm going to start getting multiple mouseovers now after mouseup.

https://github.com/fiendish/aardwolfclientpackage

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.

91,730 views.

This is page 1, subject is 3 pages long: 1 2 3

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.