在桌面和Surface(PixelSense)1.0上运行的WPF应用程序的约定

O. *_*per 8 .net c# wpf cross-platform pixelsense

编辑:为避免混淆:这是关于以前称为或仍称为Microsoft Surface 1.0的表.它不是以前称为Microsoft Surface 2.0的表,也不是现在称为Microsoft Surface的平板电脑.编辑结束

我正在编写一个WPF应用程序,它既可以在桌面系统上运行,也可以在MS Surface/PixelSense 1.0上运行.我正在寻找关于如何做到这一点的惯例.

我知道平台之间存在一些差异,这就是为什么桌面和PixelSense版本的基本GUI骨架不同(在这种情况下,Canvas桌面版本和ScatterViewPixelSense版本中的根GUI元素).

但是,桌面版本中有许多基于WPF的用户控件/ GUI片段,它们在PixelSense版本中的显示方式大致相同.

不幸的是,标准WPF控件在PixelSense中似乎不起作用.CheckBox必须更换的控件SurfaceCheckBox才能对用户输入作出反应,这可以通过PixelSense上的这个小代码示例轻松验证:

var item = new ScatterViewItem();
var sp = new StackPanel();
item.Content = sp;
item.Padding = new Thickness(20);
sp.Children.Add(new CheckBox() { Content = "CheckBox" });
sp.Children.Add(new SurfaceCheckBox() { Content = "SurfaceCheckBox" });
myScatterView.Items.Add(item);
Run Code Online (Sandbox Code Playgroud)

显然,这意味着WPF用户控件无法在没有任何更改的情况下显示在PixelSense上,这可以通过资源中的声明(如PixelSense表示层上的Microsoft文档)进行确认,其中诸如此类与WPF树视图相关的问题也可参考对,我这篇文章的PixelSense WPF层该如何改写为PixelSense一个WPF桌面应用程序SO问题.后一页甚至将所需的更改调为最小,但仍然是更改.

此外,对如何在PixelSense上使用特定WPF桌面控件的SO问题的反应意味着使用.NET 4.0可能会简化事情,但我不认为PixelSense 1.0 SDK 支持.NET 4.0 (它是.NET 3.5) - 据我所知,基于).

作为一名软件工程师,我仍然不同意使用相同的编程语言两次编写相同GUI片段(在相同布局中基本相同的控件,对数据模型具有相同行为)的策略.这似乎是错的.

那么,到目前为止我找到了三种可能的解决方案:

  • 编写标准WPF的GUI片段.然后使用脚本复制包含这些GUI片段的库,同时转换所有相关的Xaml文件(例如使用XSLT),以便将标准WPF控件替换为Surface*对应的.
    缺点:
    • 每当WPF项目中的某些内容发生变化时,始终保持脚本正常工作并运行它们所需的维护需求增加.
    • 此外,定义要考虑哪些Xaml文件以及用什么替换哪些控件(想想额外的第三方PixelSense控件......)可能会变得复杂.
    • 最后,生成的PixelSense项目将是WPF项目的精确副本,除了Xaml文件,因此不能引入特定于PixelSense的代码(或者如果可以,这将使用于生成PixelSense项目的脚本更多复杂).
  • 仅针对PixelSense/Surface,并让桌面用户安装Surface SDK.感谢用户Clemens的建议!
    缺点:
    • 用户必须安装Surface 1.0 SDK,这在当前系统上是一项非常重要的操作:为了使Surface 1.0 SDK能够在Windows 7 64位计算机上运行,必须执行各种操作,例如修补MSI文件.
    • PixelSense/Surface 1.0模拟器是在台式计算机上运行Surface 1.0应用程序的唯一可能性.这个模拟器不是很好用,在某些系统上是彻头彻尾的错误:在我的电脑上,它看起来像这样:越野车Surface 1.0模拟器 (输出仅覆盖模拟器窗口的3/4,但输入在整个窗口中注册.即点击Surface模拟的右下角,我必须点击(显然是透明的)右下角模拟器窗口.)
  • 创建GUI时,不要明确使用标准WPF或PixelSense控件类,而是使用创建适当控件类型的特定于平台的工厂.
    缺点:
    • GUI片段不能再用Xaml编写; 至少大多数控件及其所有绑定都必须在C#代码中创建.

我目前倾向于第三种选择,因为它似乎是一个可以接受的平台独立支付价格.然而,我认为WPF是桌面和PixelSense GUI之间的连接元素,这应该是一个常见的问题,我想知道这是否还没有解决过.所以,我在这里问:这通常是怎么做的?

PS:定位不是问题.上述GUI片段在PixelSense上的可旋转ScatterViewItems中以及在桌面上的正常垂直方向上显示.

Rob*_*evy 7

让我们首先跳回到Wayback机器到Surface 1.0的构建时间......

这一年是2006年.在Windows操作系统(甚至主流手机中)没有多点触控的概念!没有API允许应用程序在同时与多个控件交互时响应用户.内置于现有UI框架的输入路由,捕获和聚焦机制基本上都禁止多点触控以非糟糕的方式工作.即使这些问题神奇地消失了,大多数应用程序仍会在用户做了一些他们无法处理的东西时崩溃(例如同时单击"保存"和"退出"按钮),并且用户会非常胡思乱想,因为外观和感觉现有的应用程序/控件针对微小的鼠标光标进行了优化,而不是大手指.

因此,在2006年,我领导Surface团队在WPF之上创建一个抽象层来解决所有这些问题......结果就是你要问的1.0 SDK.我们尝试通过子类化现有的UI控件而不是创建一个全新的层次结构来最小化您提到的软件工程问题(这个决定使得开发SDK 变得更加困难)所以尽管你必须在每个平台上使用实例化不同的类但是之后原始版本控件中使用的事件和属性将按预期的Surface版本工作.

快进到2009年...多点触控开始获得动力.Windows 7增加了对多点触控的本机支持,但并未真正解决UI框架问题.

快进到2010年...... WPF和Surface团队合作采用Surface为我列出的问题构建的许多解决方案,使其适应Win7的原生触摸堆栈,并将它们作为WPF 4.0的内置部分发布. ..这提供了多点触控输入路由,事件,捕获和聚焦,但触摸功能无法简单地添加到内置的WPF控件中,而不会破坏大量现有应用程序.所以Surface团队发布了"Surface Toolkit for Windows Touch",它提供了大多数Surface 1.0 UI控件的WPF 4.0兼容版本.但是从2006年开始的Surface 1.0与这个新版本的WPF不兼容,所以当你最终可以为Windows和Surface构建杀手触摸体验时,你仍然无法共享100%的代码.

快进到2011年...... Surface 2.0(使用PixelSense技术的那款)发布.它使用了新的WPF 4.0功能(不再需要Surface 1 SDK附带的许多API),并且包含了Surface Toolkit for Windows的更新版本,尽管现在控件已被重新设置为地铁.最后,产品时间表已同步,您可以使用单个代码库为两个平台构建出色的触摸体验.

好了,现在回到你现在的问题......你问的是Surface 1.0所以2011年的真棒并没有真正帮助你.你可以利用2010年的东西:

  1. 使用WPF 4 API和Surface Toolkit for Windows Touch构建应用程序
  2. 编写一些采用Surface输入事件并通过WPF 4的输入堆栈路由它的代码(执行此操作的能力并不广为人知,但它是专门为此类场景创建的).

那你怎么做那些事情?好问题.幸运的是,我的好友Joshua Blake有一篇博客文章以及一些可重复使用的代码来引导您完成它.请查看http://nui.joshland.org/2010/07/sharing-binaries-between-surface-and.html.