• 恢复下C#WPF的编码,模拟Java的Undoable相关接口,在dotNet WPF框架下实现了两个例子:
1,基于图形的Undo接口,主要将UndoManager,UndoableEditSupport用C#写了一遍[编码过程中发现WPF在边界处理情况下的一个问题,还有就是要注意WPF下VisualTree在Z-order重叠情况下的事件传递机制[add-and-remove common language runtime (CLR) event accessors for the event,当控件作为放入一个Panel的时候,这形成了VisualTree在这个结构是事件的传递是可控的],MSDN上写的很清楚,关于RichTextBoxAddHandler。下面是JAVA标准接口和我自己实现的对比图,直接在袁牛发给我的JAVA API图上修改的。
2,基于文本的Undo接口,由于WPF没有开放RichTextBox的接口,文档的接口没有实现,只是引用RichTextBox的ApplicationCommand接口实现了功能而已。
我的基本设计:
  • 主要是定义一个扩展的MyRichTextBox类,从中取出每次的处理放入UndoManager,只有关键点在于要实现Insert和Delete的边界处理,Insert的处理可以通过重写OnTextChange根据UndoAction类型予以判断,再像图形接口一样生成UndoableEdit接口即可[当然,更好的方法是用OnTextInput接口]。但Delete的接口却没有那么简单,必须要能挂接到Delete Message发送之前,没有查到相关的API。不愿意卡太长时间,就暂时用现成的实现[ApplicationCommand]了。
  • 即使能抓到Delete Message的事件,也还有一点要注意,对于java的简单实现而言,是基于PlainDocument接口的,那么所有的格式信息就会丢失。查了下WPF开发组牛人prajakta的Blog,这个实现要用FlowDocument的接口得到TextPointer,转化为TextRange对象[Document对象空间],所有的格式信息都以DependencyProperty来保存在Control中的,注意到C#的引用问题,这里在往List<UndoableEdit>拷贝的时候注意要使用深拷
  • 顺便提一下RichTextBox里面的Undo/Redo实现,如果直接复写OnTextChange接口,就会发现MS的Undo/Redo逻辑实际上是一种简化的逻辑,所有的UndoableEdit对象都在一个操作stack里面保存,同一输入类型,比如我连续键入5个a,这5个a的操作会合并为一个UndoAction。所以,在Word和WordPad里面,我们看到的现象是一次Undo,所有的a都会消失。Java这点要做的好一点,但是也是以Vector<UndoableEdit>的规模增长作为代价的,MS的这种做法在用户许可的情况下也不失为一种明智的做法。
然后借鉴了另外一个牛人的RichTextBox实现的LiveWriter逻辑,Lester:Google Blog Live Writer
代码当然没的说的,写的很好,封装的逻辑有点像原来在SilverLight里面封装BirdEyes的逻辑。[我脸好长,这种话都敢说]
不过,Lester的代码是基于Google Blog API的,简单的说就是WCF框架下的Web Service调用逻辑[Google Blog API的那帮牛,自己写了类似于JAXB和JAX-WS2,0的逻辑],但只能访问Google Blog.
想到了怎么改到MSN space上用呢?查了下MSDN的MetaWeblogAPI,发现MSN也可以这样干,然后就去把XMLRPC的包下了,和MetaWeblogAPI整合在一起,然后就可以用来发布MSN的Space了。
原理:MSN的Space里面有个Pulish by email的功能,这个API实际上是通过开发一个服务接口,将发布内容发到Space的email发布队列里面去,然后再由服务端进行处理。[个人猜想,不过看起来比较像]
一点改进:MetaWeblogAPI是基于同步接口的,这个需要改进下,自己写个异步代码就行了。Lester的代码后台逻辑和UI线程封在了一起,不是很符合Chris Sell描述的单线程UI原则。
3,自己用WCF写了个P2P的会话应用,太简单了!学习了下MSDN上的Peer-to-Peer例子,MS的官方文档还是要考虑的周全的多。
所有的东西都放在google SVN上了,地址如下:http://code.google.com/p/jptocsharp/

Advertisements