Hi Azaozz, I also Identified the problem myself as an increasing value in the dropOnEmpty iteration but I couldn't trace where it was coming from other than the offset calculations. I think we have a general consensus that there is a bug here... I find it odd that junkmates fix worked for him, but not for me, my fix worked for me but not for you... I guess they're workarounds rather than fixes.
I need the guide code in my dragdrop for functionality on another screen so i'm willing to sacrifice a bit of performance for it... but I'm still not happy with my fixes to dragdrop- as I said, I wasn't sure what else it would break, since I did no unit tests etc, it was mainly a quick hack to get things so they didn't jitter... Anyone got any ideas here? Gareth On 6/21/07, azaozz <[EMAIL PROTECTED]> wrote: > > > I ran into the same problem, but with horizontal list. In my case, > there are 3 rows containing 20 - 30 small icons (20 x 20px). In both > versions, 1.7 and 1.7.1_beta3 the "shakeyness" starts after about the > 6th or 7th icon. It seems that the error in the calculation for the > drop position in dropOnEmpty gets larger and larger when there are > more items in the row. At the 10th icon it's about 25px left from the > cursor, at the 20th icon - about 65px, etc. > > With the (child == null) fix, most icons behave properly, except the > last 3-4. That comes from the same error in calculating the drop > position, as when you hover over 1 or 2 icons before the last, > dropOnEmpty calculated position is 80-90px left, so (child == null) > fires. > > Unfortunately I'm not that good in js and can't find where this error > comes from (everything in the code looks good). As a workaround I've > made a hidden last element with width:100px; float:right; margin- > right:-110px; that compensates for the error and stops the > "shakeyness" of the last few elements. > > Gareth, the (children.length == 0) didn't work for me. It just > disabled the dropOnEmpty functionality. Perhaps the markEmptyPlace and > createGuide don't work well in horizontal alignment. It also made > dragging/hovering slower in IE6. > > On Jun 14, 12:23 am, "Gareth Evans" <[EMAIL PROTECTED]> wrote: > > Oops... attacfhed > > > > On 6/14/07, Gareth Evans <[EMAIL PROTECTED]> wrote: > > > > > > > > > Okay, so a bit more digging around... something appears to be weird > with > > > the offset calcuations. > > > From my observations, the onHover handler and the onEmptyHover handler > get > > > fired. > > > They both calculate where to insert an item, and one of them > calculates it > > > differently to the other. > > > This results in the 'jitterbug' i've referred to. > > > The patch earlier described (and documented on trac, but its actually > a > > > patch for some other tree functionality) shows a if (child == null) > > > conditional around the final 'insert' statements. > > > Because of this, I *think* that the for loop that appears above this > if is > > > not actually required and it's sufficent to just check children.length== > > > 0. > > > Meaning, if there are no children elements then we want the > onEmptyHover > > > to insert the element. > > > I'm not very familiar with the intricacies of Sortable, other than > what > > > i've played with to get this working, but when I check children.length== > > > 0 instead of having the for loop using offsets to identify if where > the item > > > should go, the 'jitter' effect goes away for me. > > > As previously mentioned, both onHover and onEmptyHover fire when i'm > doing > > > a drag with dropOnEmpty:true. > > > > > I'm trying to figure out what i've broken by removing the offset > > > calculation, and if it's going to be an issue for anything else I > might do > > > with Sortable later in my developments. > > > > > Could one of the scripty gods read this thread and advise? > > > > > I'll attach a shortened version of my new dropOnEmpty code, which has > some > > > other modifications to allow a 'marker' element, from Tankut Koray, > and > > > myself to make his code conditional. > > > I haven't touched made any modifications to scripty base > dragdrop.jsfunctions other than onEmptyHover but > > > unMark, onHover have been changed by Tankut, and markEmptyPlace and > > > createGuide have been created by him. I've since added if statements > before > > > his code to read an options setting so I can turn his functionality > off (I > > > only need it on one page) > > > > > This issue has been driving me mad for weeks so it'd be good to get > this > > > stuff sorted. > > > > >http://dev.rubyonrails.org/ticket/7807 > > > This patch is similar but doesn't quite fix the functionality in my > app... > > > for some reason. > > > (It adds the if (child==null) which worked for junkmate's app, but > didn't > > > work for mine, I had to go to the children.length == 0) > > > > > Gareth > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
