@PappaSmalls Thank you, that reference file is really interesting!It's way, way more informative than the other drag examples I've seen posted, and the code is much cleaner and more understandable.It's very interesting that the code bypasses Hype's onDrag handler's and just uses jQuery UI - nice and simple

As a completely new Hype user (but an experienced JS programmer) I have two more follow-up questions:

Is it generally a good idea to use the Scene's onLoad event to add scripts that control or target the elements in that scene.

Can anyone point me to any equally succinct example of a drag-and-drop system using drop targets - or should any jQuery UI system work out-of-the box?

there are a few disadvantages using third party js-libraries for element positioning:- hypes framerate will be reduced by factor 2- increased loading time- possible incompatibilities with hypes runtime

in your example you load jquery -> 80kb, jqueryui -> 240kb and you'll additionally need the js touchpunch (hack) to make it work on mobiles. turn off css-positioning and your setup will fail. turn on responsiveness and your setup will fail.

this example will work with a completely hypesetup. theres only 2kb of code instead of 320kb++. you can use hypes own capabilities for anymating stuff. as long as you don't need third party libraries i would always rely on hype! YouMayNotNeedJQuery

this'll be the js-setup for ondrag of all elements to achieve the same:

I have a question about flexible scaling. I did put everything from your file in a group and made it to scale with windowsize. But the dragging is not synchronising with the mouse or touch (offset). What would be the secret for that?

Thanks for that Hans-Gerd!I just started using Hype a few days ago so that was very informative.

UPDATE:

Having tested this code in production on our target browsers we haven't yet noticed any drop in Hype's animation framerate when using jQuery, jQueryUI and Touch Punch. Also, we are using fix document sizes and scaling to different resolutions, so possible incompatibilities with responsive design has not yet been an issue for us.

I have been experimenting with your excellent drag-and-drop code, noticed a bug.If a user right-clicks one of the drag element, the element sticks to the mouse's position.When the left button is then clicked again, the element snaps back to a different start location.Do you know if there's a simple way to prevent this?

well the brwoserbehaviour on this is inconsitent. in ff it seems to work as is.i would expect @jonathan may have a look at it as onrightclickandmove hypes dragevent starts firing when the right click ends. this may be after a move ... but it's tricky here ...

as a simple workaround you can disable the contextmenu-event for the draggable elements with preventDefault()

i would expect @jonathan may have a look at it as onrightclickandmove hypes dragevent starts firing when the right click ends. this may be after a move ... but it's tricky here ...

That's interesting.... Hype calls event.preventDefault() which I would have expected to cancel the context menu from showing up in the first place since this happens after the mousedown event for the drag.

I made a fix that checks the event's button number or if the control key is being pressed, and this will ignore the drag start (or regular mouse down/click) event. I'm assuming if you request a context menu, that's what the user would want . It'll be in the next version; until then I'd go with @h_classen's workaround.

h_classen:

As of now it's a known issue that it's out of sync in responsive environments may be it gets a patch in the next release?!

michelangelo:

I took another look at this issue. I was able to fix one case where the positioning would be incorrect when 'Zoom Contents' was checked. So in the next version of Hype that will be one option for flexible layout and dragging.

However in the non 'Zoom contents' case, the fix is simply too much code for the runtime to be worthwhile. It kills me that there's a correctness issue where the tradeoff makes it better to not fix, but that's the reality of the situation . I will continue to consider options for this - perhaps the fix would only go into the full runtime, for instance. But for now, no fix is forthcoming. From documents I see, 'zoom contents' is very popular, so hopefully my partial fix will help a lot of cases.

Thanks so much @h_classen and @jonathan!You guys are amazing, thanks for all your help with this!The work-around should be fine.We're doing a lot of drag and drop over the next few weeks, so I'll keep you posted if I encounter any quirks.