Sorry, because I am not sure what is the question. Do you see my video?
I think I am moving the “Camera” window, that is pop-up widget. It is created in another user interface, not in main UI.
Did I answer your question?
Not at all. You’re moving the pop-up menu with your script. How are you doing it. Could we see the script.
I think I am moving the “Camera” window, that is pop-up widget. It is created in another user interface, not in main UI.
This makes no sense. The anchor is supposed to create it:
- this is the anchor:
It creates a pop-up. How do you reference the pop-up the anchor created. I can imagine 3-4 ways.
How do you get access to that widget:
You’re moving it somehow - so you have access to it. How did you do it?
Can we see your move script?
Ah, jackpot. It’s a bit of an abomination. You’re not even moving the pop-up widget, you’re moving the entire canvas it’s somehow sitting in. I am astounded to see this actually works, even if it produces weirdness.
I’ll have a look later on. I feel this can be done differently, I’d need to double check what the anchor is doing to its child in Slate. And it was supposed to be a Slateless week 
Can’t guaranteed this will work with an anchor at this point but I’ll have a look. It could be actually a neat feature to have poppable, draggable anchor windows.
Are you planning on having multiple of those at the same time?
1 Like
Thank you so much!
Right, that’s true. In my project, I have three menu anchors.
Maybe you also can look this. If solve this issue, we can arrive the same result.
Thanks my herro! Really appreciate.
Are they all the same class? Do they need to co-exist at the same time?
There was a question but it was edited out:
This is how you can manually create a pop-up and reference it:
So you can move it without the extra canvas:
You could try it but I am not sure it’s going to work; it does remove one UI layer. Maybe. Do tell! I feel like the anchor has its own local space, would have to dig deeper to find out. I’ll be back later on.
1 Like
Use Application Menu Stack
Not sure if this is related to this issue at all. When False the anchor does not kill its children automatically. That’s pretty much it. So you could have many instances, could be useful, especially if you bind what the pop-up does dynamically.
the anchor does not kill its children automatically
Unrelated, but just yesterday I watched an interview with the creator of Windows Task Manager, and all internal names are rather gruesome like that. His name is Dave, and since he brewed the first iteration at home (garage), the functions have funky names.
So when you call End task:
The system call actually executes DavesKillAllChildren(); or thereabout. They never updated the names due to them being low priority bugs.
1 Like
This sounds more like it could address it, tbh.
I recreated it with traditional drag & drop and it works absolutely fine. It needs no timer and no ticking, so it’s really efficient to boot. It does create one super uncanny effect I’ve yet to see elsewhere, though. Will investigate if I ever find the time but it’s irrelevant here.
Your issue:
You’re nesting things unnecessarily deep and then shift elements inside itself. Don’t. Shift the entire backup widget inside the canvas of the main widget instead. Otherwise the anchor does not know what to do with the weirdly distorted local space / desired size.
Look up Drag & Drop tuts to see how they work. And how to reference the pop up is shown somewhere above.
Look up drag & drop tuts to see how the feature works.
If you do not want to use D&D, you could probably get away it with a timer (or tick) - the method you opted for originally but it’s somewhat crude. Not sure how non-sustainable and maintenance heavy it’s going to get if you keep doing things this way. Hard to tell without know where this is going. I’d personally avoid it.
While D&D is not without its limitations, it, at least, gives you an entire framework and functionality to work with. Sometimes you may want to escape those limitations, ofc. For example: here’s a version of draggable windows that does not utilise d&d and works fine:
I used it many times and it worked well enough. It’s using onMouseMove to get location.
Now - the real question: why are you using the Menu Anchor in the first place? Its child was never meant to be draggable! Making UMG do what is was never designed to do is a bit like shooting oneself in the foot. Try dragging native button to see what I mean…
If you want to pop new draggable windows, have a look at the link I posted. I’d never use the menu anchor for that. Not saying it couldn’t work, but I’d expect it to be fussy. And it seems to be.
1 Like
After read your all suggestion, I try to cancel menu anchor.
And then I merely use the “Set visibility” Function to pop-up. And use the EVENTDISPATCHERS to use the button of pop-up to close up the pop-up window.
As for the movable function, I still keep the original move script.
Because, I always consider I need a menu anchor to arrive the pop-up result. But, after I rethink, maybe I also can control the visibility to arrive the similar result, right?
(I add the pop-up UI (I created) to the mainmenu UI. Like this pics, I think this method is similar to the question we discussed at first times.
Anyway, that’s really appreciate! And, if I need, I will also have a look at Drag&Drop. 
Look like is a very good references!
Great explanation! I will keep this knowledge in mind.
Keep in touch! My herro.
Yup, you will arrive at much better result. Press a button → create a widget, add to canvas / viewport (canvas is better). Show, hide, or deatroy it as needed. You can have as many as you need and move them around easily. This should not be done with anchor menu. It’s meant for context menus.
1 Like
Hi,
After reading this Post for a while here’s a hint from me
Your Border in Menu Widget (I think it is a border) - like Everynone said - use Canvas Panel instead - those are transparent until you place anything inside that has color, for example Border, Image etc.
You can have those but just make sure to remove color’s Alpha to make it transparent
Also the Menu Widget can be pretty empty by default, if you add pop-ups then have them as totally separate Widget
If they have to be movable - have them always liek I did on my Tutorial - in top left corner, when spawning move to desired location and then dragging is not an issue anymore
If they are static - make them in desired place already in the Widget
Either directly in Menu if those are always visible or in the separate Widget that you can show/hide
Also a little correction to Everynone’s “Destroy” Widget - it’s called “Remove from Parent” in case of Widgets
Also when you have things wrapped up in elements like Lists or Canvas Panels you can hide them easily while keeping the data as is by hiding the Parent ‘wrapper’ (List, Canvas, Border etc.), if you remove from Parent you may need to adjust the data inside of the Widget again (depending on situation)
Meaning that your Menu (and pretty any other place) can control what shows up and hides by Creating Widgets, Removing them from Parent or Hidinh/Showing up
Hope that helps 
1 Like
Thank you bro!
I will take this into consideration in the future.
1 Like
Also if you want here’s the Project (UE4.27) that uses popped up windows and a few parts always visible as sort of menu
You can find there some different things that can be done with them (like sticking to sides, moving to front on click, saving location and size and more) as well how it was implemented
(pay good attention on Anchors and all other values below that)
Maybe you’ll get some inspiration or just copy-paste to use in your Project
It is somewhat buggy and some stuff is weirdly implemented but some stuff can be pretty useful
Enjoy!
Oh, thank you so much!
You are so kind!
OK, I will take a look this project.
1 Like