If you're creating them on mouseover and destroying them on mouseout,
why not wait until mousedown to create the draggable? You'd have to
"prime the pump" as the mousedown event it's looking for has already
occurred, but it does work. Looks something like this:
function (event) {
var d = new Draggable(div, {endeffect: function (element)
{Draggables.clear();} });
d.initDrag(event);
Draggables.updateDrag(event);
}
TAG
On Jun 16, 2006, at 4:41 AM, Kjell Bublitz wrote:
I was playing around with the event observe an was finally able to
use Ryans method. But here are some thoughts i want to share.
Observing mouseover will only help on page load - but it will not
improve the draggable performance cause the problem is (as far as
the theory goes) that all the draggables are in the memory of IE,
kicking..
Now if the draggables fill the memory right on page load OR if they
do so one-by-one using mouseover ..i think it doesn't matter.
Now i tried to counter this by creating a second observer which is
supposed to reset the draggable on "mouseOut" and "buttonUp". It
works pretty well and aims to free up memory this way by destroying
the handle. If this really helps is written elsewhere.
However. What i really need is something to fix the Sortables with
constraint:false, because from my expirience the problem with
sortables is the collision detection. It is simple to compare. Just
move a sortable item over a sortable list and then do the same
outside the list. It is like day and night. I guess that the
collision detection tries to apply itself but fails unhandled..
I think a possible fix would be to disable the collision detection
anywhere but the list(s) itself. Maybe it is possible to hook in
with a single Observer.. i don't know .. what you think? Ideas?
Best regards,
Kjell
_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
