Can't understand why we should overwrite UpdateSizeAndAnchors when create EditModeExpandedSystemSettingsDialog
Etern213 opened this issue ยท 13 comments
When create EditModeExpandedSystemSettingsDialog, The default function UpdateSizeAndAnchors was overwrite, and it cause the dialog position in UIParent(400, 500), which might cover the frame we want to move, like this
I think we should add systemFrame:GetSettingsDialogAnchor():SetPoint(self, true)
in it, or just use the original UpdateSizeAndAnchors function in EditModeSystemSettingsDialogMixin.
@teelolws
I probably did that to stop something tainting. Most likely I traced UpdateSizeAndAnchors and found it was tainting the function if I use the original.
Edit mode is really sensitive, I have to be careful not to taint anything in EditModeSystemSettingsDialogMixin or the player starts getting errors when moving their target frames and such.
Instead of 400, 500 I should find the coordinates of the target frame, putting it to the left/right/top/bottom depending on which side of the screen the target frame is on. I'll need to find Blizzards code, see how they do it.
I probably did that to stop something tainting. Most likely I traced UpdateSizeAndAnchors and found it was tainting the function if I use the original.
Edit mode is really sensitive, I have to be careful not to taint anything in EditModeSystemSettingsDialogMixin or the player starts getting errors when moving their target frames and such.
Understand.
But maybe there is a better way to set it position rather than just use frame:SetPoint("TOPLEFT", UIParent, "BOTTOMLEFT", 400, 500)
Let me think about it. Thanks for your reply :)
Instead of 400, 500 I should find the coordinates of the target frame, putting it to the left/right/top/bottom depending on which side of the screen the target frame is on. I'll need to find Blizzards code, see how they do it.
I notice this addon and lib this afternoon, and want to use it in my own UI addon "Etern_UI".
Maybe I can help you to build EditModeExpanded together :)
I do not de-select the default Edit Mode frame as that will taint the frame if I do:
I just think about de-select the previous default Edit Mode frame when we select a custom frame use EditModeManagerFrame:ClearSelectedSystem()
last night. I test many times and didn't found any taint issue.
How do you find the taint issue?
I might be able to just hide the Selection frame, without calling the full DeSelect functions. I'll try it out when I get some time.
Taint issue vs Taint. If I de-select it, it will taint the frame. This doesn't mean that it will cause problems, but I don't want to take the risk!
When I first wrote the addon, during 10.0.0, I was constantly getting "Addon Blocked Due to EditModeExpanded" errors so I coded it very carefully to not change any default Edit Mode code as much as possible.
Taint issue vs Taint. If I de-select it, it will taint the frame. This doesn't mean that it will cause problems, but I don't want to take the risk!
When I first wrote the addon, during 10.0.0, I was constantly getting "Addon Blocked Due to EditModeExpanded" errors so I coded it very carefully to not change any default Edit Mode code as much as possible.
Emmm, I understand, but I think pay too much attention on taint will limit our thinking.
Whatever, I will care more about taint later.
Sometimes yes, sometimes no. I don't truly understand why it does. Maybe if Blizzard code hooks the OnHide function?
I might be able to just hide the Selection frame, without calling the full DeSelect functions. I'll try it out when I get some time.
I will try it too. And I think I must review the taint page in fandom. :(
I was confused, will SetPoint/Show/Hide taint the frame and then taint the original path?
None that I know of. Just taint.log to see what tainted, or test global variables using https://wowpedia.fandom.com/wiki/API_issecurevariable