d3.event.y在拖动行为期间有奇怪的值 [英] d3.event.y has strange values during drag behavior

查看:178
本文介绍了d3.event.y在拖动行为期间有奇怪的值的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我创建了一个示例,说明使用D3拖动行为和CSS {display:table} 样式的可调整大小单元格的布局。它适用于水平拖动,但不垂直。对于垂直调整大小, d3.event.y 提供的值对我没有意义。

I'm creating an example illustrating a layout with resizeable cells using the D3 drag behaviour and CSS {display: table} styles. It works fine for dragging horizontally, but not vertically. For vertical resizing, d3.event.y is providing values that do not make sense to me.

显示工作水平拖动和垂直拖拽损坏的小提琴。看看控制台输出,同时拖动以查看 d3.event 返回的值与 d3.mouse()

Here is a fiddle showing the working horizontal drag and the broken vertical drag. Take a look at the console output while dragging to see that the values returned by d3.event match the values returned by d3.mouse() for the horizontal drag, but they diverge for the vertical drag.

我可以通过使用 d3.mouse来修复行为() y坐标,而不是 d3.event y坐标。要看到这一点,请注释掉不工作行,并取消注释WORKS行。但是,我不明白为什么我需要这样做,它似乎不那么一般,因为我必须假设一个鼠标输入,而不是使用更通用的d3.event。

I can fix the behaviour by using the d3.mouse() y-coordinate instead of the d3.event y-coordinate. To see this, comment out the "DOESN'T WORK" line and uncomment the "WORKS" line. However, I don't understand why I need to do this, and it seems less general in that I have to assume a mouse input instead of using the more generic d3.event.

这是一个错误,还是我无法理解这里的内容?

Is this a bug, or am I failing to understand something here?

请注意,这个问题似乎也碰到了同样的问题,但使用HTML表而不是CSS表。我认为这将有助于记录这个问题发生在这两种情况下。

Note that this question seems to be hitting the same issue, but using HTML tables instead of CSS tables. I thought it would be helpful to document that this problem is occurring in both contexts.

还要注意,注释掉两行,实际上做垂直调整大小, RESIZE CELLS,使 d3.event 正常工作。当然,表不会调整大小。这表明它是关于调整大小的div的行为是领导 d3.event astray。

Also note that commenting out the two lines that actually do the vertical resizing, commented with "RESIZE CELLS", makes the d3.event work correctly. Of course, the table doesn't get resized then. This suggests that it is something about the act of resizing the divs that is leading d3.event astray.

推荐答案

好吧,我想我已经知道了这个问题。如果您查看代码的拖动行为,您将在 dragstart 中注意到用于计算鼠标偏移的值基于 this.parentNode 。简而言之,它使用 this.parentNode 作为参考点,并假定它将在拖动的持续时间内保持稳定。你在拖动期间修改父节点,所以它的参考点得到,在技术上,它漂亮的borked。在这种情况下,使用 d3.mouse 是你最好的选择,因为 d3.event.y

Alright, I think I've figured out the issue. If you look at the code for drag behavior, you'll notice in dragstart that the value used to calculate the mouse offset is based off this.parentNode. In short, it uses this.parentNode as a reference point, and assumes that it's going to be stable for the duration of the drag. You're modifying the parent nodes during the drag, so its reference point gets, to put it technically, pretty borked. In this case, using d3.mouse is your best bet, since d3.event.y is only going to be reliable as long as the parent node stays in place.

这只对y方向发生的原因是,所有行的x位置,即

The reason this only happens in the y direction for you is that the x position of all the rows, which are the parent nodes here, stay constant, whereas the y component changes during the drag.

相关的代码段:

parent = that.parentNode,





function moved() {
    var position1 = position(parent, dragId), dx, dy;

    //...

    dispatch({
      type: "drag",
      x: position1[0] + dragOffset[0],
      y: position1[1] + dragOffset[1],
      dx: dx,
      dy: dy
    });

这篇关于d3.event.y在拖动行为期间有奇怪的值的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆