Lua Code:
region:SetPoint(point, relativeTo, relativePoint, offset_x, offset_y)
Lua Code:
point, relativeTo, relativePoint, offset_x, offset_y = region:GetPoint(n)
If :SetPoint() is used to set one (or more) points on a region and said region is then repositioned via drag, :GetPoint() acts as if :ClearAllPoints() has been run, towit, UIParent is the new relativeTo and only 1 point is set.
This...this seems to be bloody absurd, even Microsoftian, behavior. Logically, since each point already has a set of rel characteristics, those would be retained and each point's offset coords updated. Instead, you have relationship-breaking behavior.
I could, frankly, forgive this if there was a API for getting relative offsets between two points, even if restricted to UIParent points, a sort of...
Lua Code:
dx, dy = GetRelOffset(frame, framePoint, UIParent_relPoint, UIParent_offset_x, UIParent_offfset_y)
...but I can't find one.
To reassert an updated and proper relative-to/offset relationship, you'd need to crawl recursively though the :GetParent() chain, checking points and offsets, heights/widths, etc, and try to work back to UIParent, then find an offset. I...call me crazy but that seems a tad excessive.
Am I missing something stunningly obvious or should I just bend over and take it like a tax audit?
(Since 'why' is often asked: Series of frames anchored to blizzardUI frames which may, or may not, be in their original positions; when created, the frames position relative to their respective blizzardUI frames; when adjusted, however, :GetPoint() won't return an offset to the original relativeTo region so the coords can't be used with the relativeTo region which, naturally, means that when the associated blizzardUI frames are moved, the custom frames stay put rather than move w/ the blizzardUI frames as they should.)
Threaded Mode
