I think I'm on to something... The adding of a hidden element introduced some other "side effects". Instead I tried adding " - (children.length * 2)" to the offset calculation (line 763 in version 1.7.0) , so now it is: var offset = Element.offsetSize(dropon, droponOptions.overlap) * (1.0 - overlap) - (children.length * 2);
That seems to fix it nicely, with or without the (child == null) patch. BTW in my previous post there's an mistype. The offset calculation error happens on the right of the cursor, not left. On Jun 20, 3:43 pm, "Gareth Evans" <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
