Announcement

Collapse
No announcement yet.

Slate Drag & Drop operation : transparent images result in images displayed from prior operations

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Slate Drag & Drop operation : transparent images result in images displayed from prior operations

    Hello,

    I'm writing a plugin for UE4 and have been implementing a drag & drop mechanism by inheriting from class FDragDropOperation.
    The operation itself works as intended: widgets can receive the operation, I can drag it around etc.

    However, there is a visual bug going on: after having dragged an image around, a second drag of a different image will result in having the previous image(s) displayed under the current image.
    Here is a gif showcasing the problem:

    https://gyazo.com/9d120ac58dbe30c06fd4353982d0b85e

    It works the same the other way around. I have debugged the widget's image content, and it's always the correct one and there is only a single image available.
    To me, it seems like the window being used as a mouse decorator in the first drag & drop gets cached in some way and the new image of the new operation is laid on top.

    Here is a screenshot of the relevant code
    https://gyazo.com/ab4d11567c32c18328314c028168908d

    Might an underlying Slate bug or design issue be the problem here? Because as far as I can tell, through debugging etc., every new drag & drop operation creates a new drag and drop object, which in turns has an FSlateBrush object called brush, which gets instantiated with the eventIcon UTexture2D pointer of the respective dialogue event.

    So basically, in pseudocode:

    Start drag & drop:
    Create operation
    Create brush from texture
    Add image to window that uses brush
    On drop: destroy window and operation

    Since this is a rather complex topic I'd rather ask on the forums than on the Q&A hub; maybe this is by design and I shouldn't use something with transparency.

    #2
    Small update: I managed to do a workaround that doesn't quite fix the issue, by painting an SColorBlock under my actual image. This way, the "cached window" gets overdrawn before I add the new SImage to it. Of course, this results in transparency not being supported, but at least it's properly useable like this.

    Comment

    Working...
    X