@User the multi caret thing, does it happen when you click from one tf directly into another?

Or tf, stage, tf?

If it's tf to tf, it might be around this line in openfl https://github.com/openfl/openfl/blob/develop/packages/textfield/src/openfl/text/TextField.hx#L3099

Without remembering what

relatedObject

is, it seems like one TF to another could skip that condition (where the cursor gets hidden)

@User - it happens without any interaction, ie, 5 tfs on screen, all get input focus (visibly) on startup

Oh... ok what I described is an issue on GH

Flixel only or OpenFL too?

It’s OpenFL

you mean the same thing happens in openfl? not flixel?

ive never noticed this behaviour

Yeah we're talking about it on the openfl discord

ok, so if im following it may be fixed?

Will be fixed when this is merged

I got annoyed and just merged it

Is somewhere drag drop example for html5 target?

there is no drag and drop inside haxeui-core

you'll have to wire it up youself, out of interest, if there was a sub system inside core to handle this, what would you expect of it?

@User - can confirm latest openfl doesnt exhibit the double focus issue... nice one 👍

@bright-gpu-74537 For drag/drop managers I've written in the past, I found the following useful. Names are just examples for me overall concept. Feedback Very welcome. moveTarget - The displayObject to be moved. Ex: a dialog component. mouseTarget - A displayObject that is assigned to trigger the drag/drop. Ex: a dialog component's titlebar. If mouseTarget is unassigned, same as moveTarget. dragBounds - A Rect specifying the bounds in the moveTarget's parent's coordinate space. dragOffset - The x & y offset to be added to the moveTarget during drag in addition to the mouse x/y offset from the moveTarget's x/y. dragTolerance - the distance the mouse must travel while mouseDown on the mouseTarget before drag begins, so as to prevent accidental drag. I usually find 2 or 3 pixels works well. dragEventType - specifies wether to use mouseMove or frame loop during drag for position updates. Then, events like: dragPending, dragStart, dragging, dragBound, and dragComplete.

ok, that seems like a pretty nice starting point... the number of times q's have been asked about d&d it think its probably time to get something in core, but im always weary about it as i feel like d&d can be quite opinionated

Note that I added dragEventType above, after thinking about it.

why would you want to use anything but mouse / user input for dragEventType?

Also, I think an event broadcast when the moveTarget overlaps with any displayObject in an optional list.

Well, for some complex displayObject drags, mouseMove can feel laggy and clunky, if the dragged item needs to do any more of it's the end drawing during drag. For instance, my connected branch hierarchy in VCR. For most situations, mouseMove is the better choice and should of course be the default.

ok, ill have to think about that one

must seems like a good list to start with... wonder if anyone will add anything else

Me too. I'd be very happy to help write this for core and anything maybe needed in OpenFl backend to get things rolling.

sounds like a pretty nice offer :) I would say that if a backend needs to be modified to facilitate it, then its the wrong angle

(i think)