3

According to this question, the answer begins with "The MouseEnter/Leave events are too unreliable to do this." What exactly makes these events unreliable?

Community
  • 1
  • 1
Kyle Baran
  • 1,793
  • 2
  • 15
  • 30
  • 3
    If you move your cursor very fast, the OS won't bother interpolating all the positions in between and so won't dispatch events in certain boundary cases. – Cameron Oct 29 '14 at 19:02
  • 1
    You can leave a comment on the answer and notify the poster with the @ symbol preceding their name if you need further info from their answer. – Pierre-Luc Pineault Oct 29 '14 at 19:03
  • @Pierre-LucPineault: It appears the OP did exactly that and it was suggested that they post a new question. See Hans' comment here: http://stackoverflow.com/a/12553029/1250301 It might be a good idea for the OP to post a comment back there to let Hans' know that he has taken his advice. – Matt Burland Oct 29 '14 at 19:04
  • 2
    @Pierre-LucPineault If you look at the question you'll see that the OP left a comment there and was instructed to ask a new question. Vicious cycle... – D Stanley Oct 29 '14 at 19:05
  • @MattBurland Hahaha oh wow, did not see that. But IMO it's clearly asking for more details on the answer. Well, hm. – Pierre-Luc Pineault Oct 29 '14 at 19:08

2 Answers2

4

The mouse position is only polled every so often. It's very possible that one of those events - the mouse entering, or leaving, could occur between when the polls occur, and the events would not fire correctly.

This also makes a pretty concrete assumption that mouse movement will be continuous, rather than discrete - what if the user has a touch screen monitor? What if the mouse goes directly from inside the control to being way outside it, with no movement in between?

furkle
  • 5,019
  • 1
  • 15
  • 24
  • IMHO, what this really demonstrates is that Microsoft foobar'd their logic. A correctly written event system would *always* balance `enter` with `leave`. Infrequent polling shouldn't matter; the system can remember what events it has sent, and behave appropriately. It doesn't matter how far the mouse moved: at a given instant, it *is* either inside or outside a given control. Of course it would still be possible for it to completely miss that a control was passed over - so not send either enter or leave - but that is a different problem. – ToolmakerSteve Aug 02 '17 at 13:21
  • [This answer](https://stackoverflow.com/a/26638928/199364) is a more accurate description of what goes wrong, in OP's case. [There are reports elsewhere that suggest `leave` sometimes doesn't happen after `enter`, which is what my previous comment was about.] – ToolmakerSteve Aug 02 '17 at 13:27
2

You missed the point entirely. These events are unreliable for the OP question, not in general.
The question was about seeing if the cursor is inside the forms client area. Having many controls the MouseEnter/Leave are unreliable because you will get these events even if you are inside the form's area.

γηράσκω δ' αεί πολλά διδασκόμε
  • 7,172
  • 2
  • 21
  • 35
  • This answer is correct. To clarify: Windows doesn't guarantee that it will send the **complete** sequence of enter/leave events that programmer expects. OP's code was written assuming the **form** would always get `enter`/`leave` events. This might not happen. Consider starting from inside one of the controls, then moving quickly to outside the entire form. Might get the `leave` of the inner control, but *never* get `enter/leave` of the form itself. – ToolmakerSteve Aug 02 '17 at 13:25
  • NOTE: According to Microsoft's current [WinForm control spec](https://msdn.microsoft.com/en-us/library/system.windows.forms.control.enter(v=vs.110).aspx), in the case I describe, `leave` **is** fired both for the inner control and the form. If this indeed happens, then the behavior has been improved in newer .Net framework versions. – ToolmakerSteve Aug 02 '17 at 13:48