Not a bug
BYOND Version:511
Operating System:Windows 10 Home 64-bit
Web Browser:Chrome 67.0.3396.87
Applies to:Dream Seeker
Status: Not a bug

This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Descriptive Problem Summary:
Setting new screen coordinates of an atom on a client's screen does not send atom/MouseExited() if the item exits the bounds of the client's cursor with that change in coordinates.

I'm unsure if this is intentional functionality but I figured this is the best place to stuff this thread.
Hrm. Can you give me more info on this? Code snippet, test project, anything like that?
Correction in this, MouseExited() isn't called when del() is used on an atom.

My earlier investigations made me think it was a change in screen_loc, but after poking around some more today, this is what it seems to be.
Hrm, that's gonna be a hard case to catch I think, but I'll see what I can find.
Wait, wouldn't any solution to this ultimately require the server to track which clients have a mouse currently engaged over an atom?

Even worse, would not the object either have to be prevented from being destroyed until the client could fire the MouseExited() message to the server? What happens when a client suddenly becomes nonresponsive? Does deletion time out? Would the server still not have to keep track of the atom to ensure that it isn't deleted when engaged by a mouse hover event?

Given the logic of the potential solution, this doesn't really feel like a bug, so much as a complication for the developer to tackle.

...Unless there's some kind of inconsistency I'm not seeing.
I think you're right on that, Ter. (As usual.)

If the client were responsible for sending MouseEntered(), MouseExited(), and MouseMove(), it would be easy to include logic on the client end forcing it to send the exit message in response to a deletion--but the server would have already deleted the atom, making that part of the message meaningless.

However those procs are not triggered directly by the client, but rather are spawned by the server in response to an internal "mouseover" command. That command sends the current "over" atom, and the server compares that to the last-known value to determine if it should call MouseExited and then MouseEntered, or just MouseMove.

That last-over value counts as a reference, so if the atom is movable and you move it to null so it can soft-delete instead of doing a hard del(), MouseExited() should be called normally. Another option here is to move to null, then spawn a del(src) after some reasonable delay, although if you can use a soft-delete that's always the best strategy.

I'll close this as a non-bug.
Lummox JR resolved issue (Not a bug)