如何用c#写所见即所得的设计器_c#应用

摘要
本文讨论了如何使用C#编写一个所见即所得的设计器,分析了设计器的基本原理,可能碰到的技术问题，连同如何调用.NET框架来实现一个设计器。

版权声明
本文是XDesigner软件工作室撰写，XDesigner软件工作室拥有本文版权，转载请注明出处，并保留本版权声明。

前言
随着电脑信息系统不断深入发展，其系统结构需要越来越灵活，这种灵活性就是表现为程式的高度可配置性，可能应用程式的工作流程能够随便改变，用户界面也能够随便改变，面对这种不断增强的灵活，是不可能通过修改程式代码来实现的，应用系统本身需要发生深刻变化，需要实现很强的扩展性和灵活性。此外z专门用于修改系统配置的外围工具也是很重要的。这些系统外围定制工具很大一部分就是一些所见即所得的设计器。比如工作流编制工具，WinForm或WebForm界面设计器，而报表设计器也是典型的外围定制工具。

总所周知，所见即所得的设计器是个相当复杂的程式，首先他需要复杂的图像化用户界面编程，包括图像的绘制，鼠标键盘事件的处理，还要抗屏幕闪烁。其次更有他后台的数据维护处理，包括用户界面和数据的同步，数据的组织安排，连同加载和保存文档的处理。而且这些处理过程能够算是纠缠在一起，需要很认真小心的分析设计，仔细编码。

本文就是探讨如何实现一个所见即所得的设计器。 关于本文，能够参考作者的另一篇文章－如何使用C#编写文本编辑器。

设计器类型
设计器按照用户界面和使用体验，能够分为两种模式，一种是基于直角坐标方式，另一种是基于流式排版方式。微软的Visio就是典型的直角坐标方式，而Word则是流式排版方式，而VS.NET的WebForm窗体设计器就是这两者的结合。

在直角坐标方式的设计器中，设计元素是使用XY坐标来在设计视图中定位的，对于矩形元素一般指定他的左上角的位置来定位，设计者需要指定设计元素的位置，有时还要配置他的大小。对于线段需要指定两个端点的XY坐标。设计者只要配置好了各个元素的位置大小就完成了设计文档的基本结构，剩下的就是配置各个元素各自的内容了。

在流式排版设计器中，设计元素是无需指定位置的，是根据一般根据从左到右，从上到下的排列原则填充到设计视图中（但有时会变成其他排列原则）。设计元素的位置是动态计算的。流式设计器可能还要使用键盘直接输入文本，需要显示光标。流式排版设计器能够看作文字处理器。

这两种设计器用户界面和使用体验不相同，因此其程式处理的方式也不相同，直角坐标设计器存在设计元素间相互覆盖，这影响绘图，此外还需要大量的鼠标拖拽操作，需要认真处理鼠标事件，但键盘事件处理得不多。而流式排版设计器中元素不会相互覆盖，因此绘制起来方便点，鼠标事件处理不多，但键盘事件处理的多，此外还需要处理光标。但这两种设计器他的文档对象模型有比较大的类似性。

在本文中，以下只讨论直角坐标方式的设计器。

设计器的功能
个人认为一个设计器应当实现的功能有

设计文档的加载和保存，设计器能够将当前设计的内容保存到一个文档中，这个文档能够保存到文档中，也可保存到数据库或某个服务器中。设计器能够加载文档来完全重现上次的设计结果。
设计器能够快速准确的绘制文档视图，当视图大小超过设计区域时，用户界面应当出现滚动条来进行滚动操作。
当前有互换式设计体验，用户能够使用鼠标拖拽操作来改变元素的位置大小等布局配置，用户改变了元素的布局或某些属性时，必须立即更新文档视图，而且更新区域应当尽量小。
支持所见即所得的设计体验，当设计器需要进行图像输出，例如输出图片或打印时，用户在设计器中的设计视图应当和输出的图像保持一致。
尽量减少屏幕闪烁。这需要绘制图像或更新视图时需要进行优化，尽快完成绘制操作。
若设计器需要进行扩展时，设计器应当提供足够的扩展能力，研发人员能够在这个设计器的基础上添加新的特性，使得设计器能显示新样式的文档视图。并且加载和保存文档时也能处理新的文档结构。
若需要能够支持VBA脚本，用户能够编写VBA脚本来控制设计器，包括其设计的文档内容。
文档对象模型
对于电脑程式，后台决定前台，而设计器的后台就是文档对象模型。相信大家对文档对象模型有所了解，我们在WEB页面中使用JAVASCRIPT脚本时就是访问了HTML文档对象模型,我们操作XML文档就是访问XML文档对象模型。

W3C国际组织对文档对象模型是这样定义的（摘自 http://www.w3.org/DOM/ ）
The Document Object Model is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents. The document can be further processed and the results of that processing can be incorporated back into the presented page. This is an overview of DOM-related materials here at W3C and around the web.

以我个人的英文水平翻译如下
文档对象模型是一种语言中立的接口或平台，程式或脚本能利用他来访问和更新结构化的文档。这些文档能够被进一步的处理，处理结果能够组成一个有效页面。这是W3C对web上的对文档对象模型原理的一般看法。

我个人认为，对于编程，文档对象模型其主要内容就是，面对比较复杂的文档，使用面向对象的编程思想，使用一个个程式世界中的对象来映射文档中的每一个特定的部分。加载文档时，能够解析文档，并把其表示的内容映射为一个个对象，此时应用程式能够修改这些对象的数据，当保存文档时，能够将这些对象数据组织起来按照特定的格式保存到文档中。这样程式就通过访问文档对象来访问文档，也能够修改文档对象来修改文档，如此实现了对复杂文档的处理。文档对象模型是处理复杂文档的标准操作模式。

设计器处理的是复杂的文档，因此也需要使用文档对象模型。文档对象模型可分为三大部分：文档基本元素，文档对象和各种类型的从文档基本元素派生出的文档元素。

文档基本元素是整个文档对象模型的最基础的对象（就像Object类型是.NET对象集团的基础相同),他定义了文档元素的通用接口，一般定义为抽象类，类型名称能够为DesignElement 。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有