This is a great question for which I have no ready-made solution. Exactly what comes first is one of those things that you take for granted when you get it for free as a MouseEvent target. The easy part is setting up all of your display objects to listen for a KeyboardEvent corresponding to a space bar, and to click the test with the mouse position at that moment.
The rest of your problem, the real problem, seems to come down to one definition that you need to make: A and B occupy the same screen space that is in front. In other words, once you have a list of all DisplayObjects for which hitTest is a hit, you need this comparison function to sort them from front to back. This is how I see what works:
To determine if DisplayObject A is in front of or next to DisplayObject B, you need to track their ancestors of the predicted list to their common ancestor, and then look down the next generation to see if - at the point where their pedigree diverges - the ancestor object is in front of or behind object B (i.e., their relative depth in the container of the common ancestor). Consider the mapping tree as follows:
E / \ CD / \ AB
E is a common ancestor. To determine if A is behind B, you need to check if C is behind D, which means you need to check the depths of C and D in container E (with DisplayObjectContainer.getChildIndex (child)). Obviously, in a complex user interface, a common ancestor may be many generations ago, but there will always be one, even if this is a stage.
EDIT:
How did I lose sight of the obvious ?! you donโt want to click the mouse button, but you didnโt say that you cannot use MouseEvents at all, right? Use the ROLL_OVER or MOUSE_OVER event to keep track of what you turned over, and hitTest with this object [pats his forehead in disgrace].
source share