Currently, I have an icon that is the child of a GoGroup which is turned on/off by the user. When the parent node is moved, I want the child icon to remain in the same spot.
I’ve currently overridden DoMove in GoNode to subtract the offset of the move and reposition the child node appropriately. Unfortunately, when I programmatically move the child node back to where it was, I think I’m triggering another DoMove event. The resulting behaviour is that the node I am moving runs away off the screen (but the child node dutifully remains in place).
I’d prefer to use the GoGroup concept because the selection and interrogation behaviour is automatically and correctly deferring to the parent node. However, it’s unusable as is.
Is there a way to keep DoMove from recursing onto itself? Or do I have to create a separate GoNode and handle the selection behaviour manually?
I don’t think your approach is going to work. The better place to do the override is MoveChildren, but we don’t have a sample of anything like your requirement.
Maybe if you post a screenshot, and a little more about the "why" behind the requirement, some other approach may be better. (use "post reply" button at bottom right to get the full editor with uploadable screenshots)
The scenario is that I have a well on the surface of the earth. The surface location can currently be fine tuned by a user and is a valid user story if you consider them turning on a satellite photo to properly position the surface location by eye.
The surface is connected to a bottomhole location via a well bore. The bottomhole location may or may not be directly below the surface location. Regardless, the bottomhole location is a property of the surface location and is impossible to place by eye. The user will have to position the bottom hole location using an input form based on survey data received from the drillers.
So, my surface location is movable, my bottom hole location is not. However, making them separate pronodes doesn’t give me the selection behaviour that I want.
Selecting the bottom hole location should defer to the surface location, as in the given screenshot. This behaviour is most easily achieved by making the bottom hole icon a child of the the GoGroup. That works fine.
The problem arises when I try to move the surface location. Without overriding the move behaviour, the bottom hole location merrily moves along with the surface location. If I override DoMove or ComputeMove to have the child icon oppose the GoGroup’s movement (thus remains in place), I get the recursive movement I mentioned and the surface location runs off the screen.