eyesoar

Hi Carl I thought it was fairly clear but try this. http://codepen.io/anon/pen/VYqprL You should be able to drag the black section (drag2) left and right. But enabling drag1 causes drag2 to snap back to its original position. comment out drag1[0].enable(); to see how dragging drag2 should work. Commenting in or out one line of code to see the issue is about as reduced a case as I can make it. Matt

Thanks This certainly does do work the way I was after. It is an elegant solution I had all sorts of previous tests to see what direction someone was dragging in to try to block the wrong type of movement. I didn't realise such a simple answer was sitting there all along. While this does solves my problem but there is still the issue that enable() is buggy. I have had problems with it in a previous project but that was quite complicated and I assumed it was something I was doing wrong So had some nasty logic to get around it. I think it would be good to flag enable() as something to be avoided unless it is being used where there aren't multiple draggables.

Hi Carl That looks pretty similar to the version I was running. And no I get the same result. Matt

Thanks for the suggestion That does work but it's not quite what I'm after. I was still hoping to have a up/down drag on the horizontal div go through to the parent div. This is why I was disabling on DragStart not on press. The horizontal div doesn't fire an a DragStart if I just drag vertically and I don't have to find a place outside of that div to drag on. Besides that I would still like to know what is going on with the enable() call taking over another dragger.

I have 2 draggables drag1 - type:"scrollTop" & drag2 - type:"scrollLeft" On an ipad I notice when dragging horizontally the page jiggles vertically. o stop this I disable drag1 on DragStart of drag2. This is all fine but … When I enable drag1 on DragEnd of drag2 the content of drag2 snaps back to it's starting position. This error occurs on both the iPad and chrome osx. As I understand it this should work just fine - any pointers to what is going on or how to get around it would be greatly appreciated. Matt

Thanks for the link Carl. Sorry I didn't come across that before. I do see the complexities of tracking multiple thrown objects and can see the point of just having it for dragging which is likely to be the most common use. Obviously the auto scroll on throw was just to be able to follow the path of a thrown element (either game or UI) kind of like having a camera follow the object. Having said that this is starting to sound like its on thing and should probably be handled outside of the drag class. The feel of the "virtual camera" is most likely something that needs to be chose for a specific application and not just keep it visible. Matt

I have just had a look at the new auto scroll feature. (it looks great as does direction) Would it make sense to include the option to auto scroll on throw ? Currently if you throw the draggable object it disappears of the page. Sure I could adjust it myself on throw update but it seems to me like a nice option to include. Matt