While an item is being dragged, any color changes or sound effects defined in the style are completely ignored. The OnDragEnter event fires, but it is pointless because style changes cannot be executed from within the event.
Is there any way to make the buttons function just like the standard mouse cursor while dragging?
That’s by design: during a native Slate drag-and-drop the pointer is captured by the drag operation, and hit-testing is suspended for widgets under the cursor — so hover/press state changes never reach the Common Button while dragging. OnDragEnter fires because that’s the drop-target interface, but it’s outside the normal style-state machinery, which is why your style edits are ignored.
Workarounds that actually show feedback:
- Drive appearance manually in OnDragEnter/OnDragLeave: on CommonButtonBase use SetBackgroundColor (and SetRenderOpacity for dimming) instead of style edits — background color changes apply immediately regardless of state machine.
-
- For sounds, play them directly in OnDragEnter/OnDragLeave via Play Sound 2D — don’t rely on the style’s hover/press sounds while dragging.
-
- If you need the full visual set (brush swap, borders), put a Border/Overlay on top of the button and toggle its visibility in OnDragEnter/OnDragLeave — visual layer, not the button’s state machine.
- Longer term: a custom Slate drag layer that forwards hover to the drop targets is the ‘real’ fix (that’s what Windows Explorer-style drag cues do), but for UMG the manual driving above is the standard approach — and honestly clearer to read later, since the drag-cue logic lives next to your drag logic instead of hidden in the style table.