小编Jus*_*dro的帖子

我正在尝试使用WebDriver进行自动化测试,但它目前无法模拟鼠标滚轮事件.作为一种解决方法,我试图用JavaScript来解雇这些事件.我现在正在直接在HTML页面上进行实验,而不是在WebDriver框架内.

我特意尝试在滚动div元素上触发鼠标滚轮事件.

到目前为止,我已经能够使用Chrome和IE9做到这一点,但我似乎无法在Firefox(5.x)中使用任何东西.

我正在使用以下跨浏览器代码来检测何时触发鼠标滚轮事件,这是我从网上抓取的.当我在我创建的滚动div(id ='view')中滚动鼠标滚轮时,此代码能够在所有浏览器中拾取事件.

<script type="text/javascript">
  function wheel(event) {
    var delta = 0;
    if (!event) {
      event = view.event;
    }
    if (event.wheelDelta) {
      delta = event.wheelDelta / 120;
    }
    else if (event.detail) {
      delta = -event.detail / 3;
    }

    alert(delta);
  }

  var view = document.getElementById('view');

  if (view.addEventListener) {
    view.addEventListener('DOMMouseScroll', wheel, false);
  }

  view.onmousewheel = wheel;
</script>

调用时,下面的函数可以在Chrome和IE9中触发鼠标滚轮事件,并在上述处理程序中获取预期行为.

function ChromeWheel () {
  var evt = document.createEvent("MouseEvents");
  evt.initEvent('mousewheel', true, true);
  evt.wheelDelta = 120;
  view.dispatchEvent(evt);
}

当然,它不适用于Firefox.我发现现有的文档太稀疏而且不知道FF如何处理这个问题.任何人都可以向我展示在Firefox中使用滚轮三角形(放置在FF预期的位置)中发射鼠标滚轮事件的最低限度,这样我的处理程序就可以将它拿起来？

我在C#中使用XmlSerializer遇到了一些令人惊讶的行为.考虑以下代码.

public class A : IEnumerable
{
    public class B
    {
        [XmlAttribute]
        public string PropA { get; set; }
        [XmlElement]
        public string PropB { get; set; }
    }

    public IEnumerator GetEnumerator ()
    {
        yield break;
    }
}

class Program
{
    static void Main (string[] args)
    {
        XmlSerializer serializer = new XmlSerializer(typeof(A.B));

        XmlTextWriter writer = new XmlTextWriter(@"E:\temp\test.xml", Encoding.Default);
        serializer.Serialize(writer, new A.B() { PropA = "one", PropB = "two" });
    }
}

在这个例子中,我尝试序列化嵌套类AB的实例,它本身不以任何方式使用容器类A. 但是当我尝试为它构造XmlSerializer时,抛出以下异常:

InvalidOperationException未处理:

要成为XML可序列化,从IEnumerable继承的类型必须在其继承层次结构的所有级别都具有Add(System.Object)的实现.Test.A没有实现Add(System.Object).

当我实际尝试序列化类型AB时,XmlSerializer正在尝试对类型A应用序列化约束我的理解是,除了在外部类型的实例中对数据的特权访问之外,嵌套类型不是特殊的并且表现得好像它是在命名空间中.

这种理解是不正确的,并且嵌套类型或XmlSerializer的语义是否证明了这种行为,或者这是否像XmlSerializer中的错误一样？

特别是对于XmlSerializer语义,是否有任何文档要求在针对嵌套类型应用时对所有外部类型强制执行XmlSerializer约束？

来自.NET的更高版本的通用Func <>和Action <>委托是非常有吸引力的,并且已经在许多地方证明了这些可以在面向.NET 2.0的代码中轻松地重新创建,例如这里.

从针对.NET 2.0的库的角度来看,这可能是针对任何更高版本的.NET构建的应用程序所消耗的,这是如何叠加的.在库中实现这个"兼容层"绝对是一个冲突的方法(在私有和公共接口方面),还是有办法使这个工作独立于消费应用程序构建的目标框架？

如果这是一个非首发,那么它们会更好:A)定义一组具有不同名称的相同参数化代理？或者.. B)严格遵守.NET 2.0约定,并根据需要定义新的委托类型？

我正在尝试在构建过程中通过无头Eclipse执行JUnit测试.使用以下命令从Ant脚本调用单元测试:

eclipsec.exe -noSplash -application org.eclipse.ant.core.antRunner -data "C:\SomeDirectory" -buildfile "C:\Path\To\tests.xml"

这种方法很好,除非Ant脚本由于任何原因需要失败(通过显式任务,因为单元测试失败,或者因为单元测试向上游引发了异常).在任何一种情况下,eclipsec都会引发一个对话框,报告"发生了错误".这伴随着一个例外.堆栈跟踪的顶部(如果相关)是:

java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at org.eclipse.ant.core.AntRunner.run(AntRunner.java:513)
    at org.eclipse.ant.core.AntRunner.start(AntRunner.java:600)

我真的不关心Ant脚本或Eclipse失败的原因 - 这就是日志记录的用途 - 但是随之弹出的对话框是不可接受的,因为它在等待隐形时挂起我们的持续集成系统用户来点击它.

有没有办法可以抑制这个对话框？ 有什么方法可以解决这个不需要真正的用户响应它的对话框吗？

附加信息:

Eclipse版本:Indigo(截至昨日).Ant和JUnit内部.

Java版本:JDK 6.0_30 32位

操作系统:Windows(7和Server 2003)

我希望能够在某些工具栏中更改ToolStripComboBox控件的边框颜色，因为与平面样式一起使用时ComboBoxes的默认边框颜色是SystemColors.Window，而对于工具栏的默认控件颜色，该颜色基本上是不可见的。在Reflector中进行了很多研究之后，我看不到任何明显的方法，因为ComboBox渲染背后的所有基础结构在内部和私有接口背后都得到了高度保护。

在ToolStrips之外，我见过的一种用于固定ComboBoxes边框颜色的常见解决方案是将ComboBox子类化，覆盖WndProc并手动绘制边框。这对于ToolStripComboBox控件不起作用，因为内部ComboBox控件是ComboBox自己的私有子类，我看不到替换控件实例的方法。

我正在考虑的另一种解决方案是将扩展的ComboBox对象之一放入ToolStripControlHost中，该工具允许我绘制边框，但是随后我不得不放弃一些专业的渲染器调整。我注意到的第二个缺点是鼠标悬停时偶尔会闪烁。

将设计切换到WPF是不可接受的解决方案。在父控件中为绘制边框包装控件也是不可接受的，因为这与ToolStripControlHost替代方法无关。

有没有人有一个聪明的解决方案来解决这个问题，或者有没有在野外对ComboBox平面样式渲染堆栈进行现有的（许可许可）重新实现，从而解决了现有实现中的一些缺点？

可以显式实现C#中的接口方法,以便在将实例显式强制转换为接口类型时调用它们的实现.为什么在类的虚方法上也不支持这个？

尽管解决"多重继承"问题对于接口来说是独一无二的,但似乎由于其他原因明确实现了成员对接口有用,它们对虚拟方法也很有用.我们想到一个更清洁的返回型协方差模型.

编辑:按要求,一个例子:

public class Foo {
    ...
}

public class Bar : Foo {
   ...
}

class Base {
   abstract Foo A ();
}

class Dervied {
  private Bar _b;

  Bar A () {
    return _b;
  }

  Foo Base.A () {
    return _b;
  }
}

我知道使用辅助方法来模拟这个,但是净效果似乎具有显式实现可能具有的任何不良特性,但具有更脏的API.我的问题的关键不在于如何做返回类型协方差,而是为什么虚拟方法不支持类似的接口机制.