if the parent frame's effective scale is .5 and you calculate the screen space difference between the child frame's left side compared to the parent frame's left side as being 100 units then use that to set the point with an offset of 100 units, it will end up only 50 screen space units away because of the scale of the parent frame. this is regardless of the child frame's scale.
Just because you put a frame relative to another frame doesn't mean it's attached to that frame. Hence my analogy about the paper.
Say you have a frame (frameA) at TOPLEFT, UIParent, TOPLEFT, 75, -80 and you have another frame (frameB) at TOPLEFT, frameA, TOPLEFT, 0, 0. It's the same as putting frameB at TOPLEFT, UIParent, TOPLEFT, 75, -80. That's where it stays until you move it or its parent frame.
both frames would move if you managed to move the UIParent's TOPLEFT, i do believe.
it isn't the act of putting two frames next to each other that connects them, it's the act of calling SetPoint with a relative to anchor. you're absolutely right about the concept of parenting, only the parenting mechanism for frame placement is SetPoint not SetParent.
yeah, parenting is only pertient to visibility (alpha, Hide, etc) and scale. it's kind of confusing, really, because scale has implications for the actual frame sizes and such, but i believe that's only because it changes the scale of the numbers used in the anchor system (which probably helps confuse the two systems).
in your analogy, engigell, you're describing the anchoring system more than the parenting heirarchy. the staple is in fact, an anchor.
edit: i guess we all check the forum at the same time.
it's not the parent that's being lost, it's the "relative to" anchor.
and the "relative to" anchor is all you need to move. if you say a frameA's LEFT is located 15 pixels away from frameB's RIGHT it doesn't really matter whether frameA is parented to frameB, if frameB's RIGHT moves so does frameA's LEFT. right?
StartMoving() and StopMovingOrSizing() should take a reference Frame and Point as optional arguments. that would let you do StopMovingOrSizing(frameParent, "CENTER") to have your new point coordinates relative to the "CENTER" point of frameParent.
with no arguments, they'd function the same as they do now so it would be a backwards compatible method to solve this particular issue.
I'll have to think about that, maybe that is a better solution. I guess it depends partly on performance; with that method, you'd have to GetCursorPosition(), GetEffectiveScale(), bit of division, ClearAllPoints(), SetPoint() for every frame, although maybe it doesn't matter since the user persumably doesn't drag stuff around all that often while needing top performance.
well, presumably the EffectiveScale wouldn't change during the update, so that would only need one call at the start.
the ClearAllPoints is probably the deal breaker, tho. i was figuring that SetPoint with the same anchor would change the point instead of creating a new one. probably more efficient to do what you're doing.
you're still calling StartMoving(), tho. i was suggesting not calling it and mimicking its behavior with your own OnUpdate() function so you're just adjusting your points on your own and not having to totally re-create the attachment.
i realize you've got something that works for you, but it seems like the kind of problem that might crop up for others. i was simply offering a different approach -- one that avoids the quirks of the system by circumventing it entirely.
exploring the problem a bit more, i'm curious what happens in a subframe that has multiple points. do they all get reset to ui space or StartMoving delete them?
i'm not sure i'm totally following this, but i'll chime in anyways. :P
why do you need the anchor point to be set if the buttons are movable in the window? if it's purely for the ability to move children when the parent moves, i'm wondering if you can call StartMoving() on all the children when you do for the parent. does that work or does it blow up?