I’m guessing this is the SurfaceGui contents ported over to a ScreenGui, adding the UIScale?
I will look into this 
thank you!
6 Likes
I will look into this! Thank you for the report
4 Likes
We will be replying to this thread and edit the title & contents when it’s live on Client!
5 Likes
That’s interesting-- haven’t run into that myself personally.
Do you have a .rbxm of the frame / screenGui you’re using that reproduces this consistently? I’ll try to figure out why that is happening.
4 Likes
The black circle has been reported-- we will fix it!
The Test Place UI wasn’t quite designed with the mobile in mind, and I’ll try to make it better.
Regarding the resizing-- the behavior is done through lua script responses in the drag response events, and you can find the corresponding model in the test place with the name “Offset Scale And Resize”.
5 Likes
This is great! Another great tool to UIs to make creating them easy
…now when will we stop having to script the AutomaticCanvasSize property 
AutomaticCanvasSize should take into account padding
4 Likes
Thank you for this new feature, you now do not have to implement your own system to achieve the same result, and is beginner-friendly.
3 Likes
You could do two things:
- Create a smaller parent that takes up the area that you want to drag, and have the UIDragDetector parented by that.
- Set the ResponseStyle to custom (For this case, CustomOffset is probably the one you want). On DragStart, store the position of the UI you want to move. On DragContinue, set the position of the UI you want to move as its initial position + the DragUDim2 of the UIDragDetector you’re using.
Constraint functions could work for this, too, but it would be doing the same thing as #2, and harder to set up.
Let me know if that works for you!
Edit: I suppose another hack could be that if your input on DragStart isn’t within a certain area (calculated by X/Y, over some Gui, etc), you could stop the drag by setting Enabled to false, then immediately re-enable for further drags. That’s not a pretty solution, though
1 Like
The cursor issue is known! A fix has been made & will be applied in two weeks.
5 Likes
There are known issues with cursors at the moment-- a fix should be incoming.
As for resizing, it’s expected to not work in edit mode, as it’s done by scripting on the events. It would only work in play mode.
2 Likes
Interesting-- we’ll definitely be looking into performance enhancements over time, but hopefully it’s not too big of an issue at the current state.
@mantorok4866 As shown by @XenoDenissboss1 , there does seem to be possible performance effects. If your custom dragger is simple in logic, it’s definitely possible to be better in performance.
We will be improving upon this over time.
3 Likes
The performance losses dont seem to be that crazy. Something else i found is that having a ton of ui instances with ui drag detectors parented into them will cause the client to freeze briefly every time you try dragging one instance out of the pile. This is probably even less of an performance issue since yknow, unlikely any game is going to have like over 1000 draggable instances be held in the exact same position.
5 Likes
It’s on a plugin so it should run without needing to play
3 Likes
Ah, at the moment, if a plugin is active, dragging is disabled. I believe that may be the reason.
We are looking into a better solution-- perhaps to disable the dragging only when the mouse is taken by a plugin or a tool (such as the Select, Move, Rotate, Transform tools, or the UIEditor plugin).
5 Likes
unlikely any game is going to have like over 1000 draggable instances be held in the exact same position.
Don’t jinx it 
We’ll take a look at such cases when we have the bandwidth to see if it’s a real issue / if anything can be improved-- otherwise, some performance effects are expected. Please do let us know if you find cases where regular usage causes a significant issue!
6 Likes
I see, personally i was expecting for that sort of use case to work without any code changes. I cant exactly pull off any hacky ways of doing this like first idea you proposed since it would mean also changing some of the code to account for the new parent.
The second and third hack are right now not exactly good enough for my use case mostly because i do myself have my own draggable’s system which does not have any of the performance issues i had talked about earlier. While no doubt the second method would look nicer i still would rather use my system until the performance issues get addressed. They aren’t anything game breaking or whatever but they do feel pretty bad to look at and use, especially on higher refresh rates.
Again, i was mostly interested in the idea if i could have that sort of behavior without any code changes.
3 Likes
Yeah, that’s definitely understandable! It’s definitely a use case that isn’t covered without scripting, but it’s something that can be looked into in the future.
We’ll be mentioning any performance improvements in the update logs, so hopefully it’ll be within an acceptable range sooner or later.
2 Likes
I definitely feel you lol
I spent a good few hours on a button drag system just yesterday, and next thing I know roblox just adds an entire instance that solves everything I put my work into 
3 Likes
This is so useful. Great update!
2 Likes
How would this work with UI frameworks like React? Would there be an API we could listen to?
Also, my primary use-case for this would be for my inventory system. If I could use a UIDragDetector to drag an inventory item out of the item grid in order to detect when to drop it onto the ground, I’d be able to delete the entirety of my custom dragging code.
Here’s a visual example of what I’m referring to:
8 Likes