You can use constraints, here...
- All objects constructed with local orientation aligned to world
- Flap and Frame origins both at world 0
- Slider origin at its hinge point
- A target Empty at the center of the constraining rail
- Flap and Empty CtrlP parented to frame
- Slider parented to Flap
- Slider given locked track constraint targeted on the Empty ( In this example, positive X is to our left)
- Flap's Rotation limited to a range in Y so as not to run off the end of the slider
Now you can simply key the rotation and location of the frame, (the rest will follow), and key the Y rotation of your flap.The slider will behave appropriately.
Here's the implementation on your file, (revised, I've made a correction to center the hinge of the flap to the flap's rotation)
And a 2.79 version:
On the question of how parenting interacts with constraints, I have to reverse-engineer.. I wouldn't know where to look in the code in a reasonable time, so what follows is an informed guess, which I would be happy to have corrected.
Further to @sambler's answer here, at a lower level, to perform a transformation T of a child C in a parent P's space, you would:
- Give C the inverse transformation of P (as it were, bringing everything into World space), followed by...
- ... executing T on C, followed by...
- ... giving C the transform of P again, to put it back in the frame it came from.
These transformations would be multiplied together in the right order, as matrices, to yield a single transformation matrix by which you can multiply the coordinates of all the vertices of C.
Naively, I can imagine, if 'Local' is selected, constraints being checked at step 2, with any targets undergoing step 1 as well as C, so they are compared in P's space. The effect is that constraints are applied after parenting.
In this case, the slider (its origin) does rotate with its parent. Its local rotation (at step 2) is constrained.