2001-11-21
今天我很高兴，终于收到了项目款。如果节俭一些，又可以过几个月了。为了管理账目，写了一个小程序。这可能是作程序员的唯一好处吧。我还是继续侃我的框架吧。
serialization、dynamic creation support和property manage彼此需求，他们构成了一个闭合的环。要想解决问题必须先孤立出最重要的部分，忽略或模拟其他部分。在这里我认为property manager是最大的难点。它的难度在于属性变量类型的描述和导出。
我一直非常羡慕Delphi的Object Inspector和VB的属性编辑器。在我的构想里，我想实现一个类似Object Inspector风格的属性编辑界面作为该系统的唯一属性UI界面。在确定property manager的具体实现方式之前，我要先完成UI界面，为以后调试property manager打些基础。在开始动手之前，我仔细的观察了delphi Object Inspector动作行为。我猜想delphi Object Inspector是由一个具有LBS_NOINTEGRALHEIGHT和LBS_OWNERDRAWFIXED风格的LISTBOX构成的。这样设计应该非常经济，可以避免大量的item管理、定位和滚动处理。于是我用spy++看看它的基本风格，它的CLASSNAME叫TInspListBox，但却没有LBS_NOINTEGRALHEIGHT和LBS_OWNERDRAWFIXED风格。而且还有一个0x111风格，spy++无法确认它，真是奇怪。但我还是使用LISTBOX来完成。为了避免界面闪动，在LISTBOX及其子窗口上使用WS_CLIPSIBLINGS和WS_OVERLAPPED风格和利用compatible dc是关键。下面的图片中的属性编辑器是不是很像delphi object inspector。
delphi在属性类型的管理上有编译器优势。编译器结合TObject自动导出published中的所有变量的RTTI。当VB 4.0出现的时候，delphi才出现。但delphi很快就赶超了vb。很大的原因在于delphi自身可以编写component，这在当时的vb中是没有的。delphi object inspector可以显示并编辑一下数据类型：
基本数据类型
enum
set
TPersistent的子类。
它不能使用指针类型，这在编译器中已经限制住了。虽然我可以借鉴delphi的很多做法，但很可惜我没有编译器优势。现在的vb使用automation来解决类似的问题。
当然了，我可以像MFC那样使用一系列的macro和static结构来模拟RTTI。但问题是：既然所有的对象是动态注册并构造的，那么用户自定义类型也应该是动态注册并管理的。如果使用类型名称作为类型标示，那么两个对象可以导出不同的结构但具有相同的类型名称。另外，很多类型应该是可以在不同对象中共享的，例如：RGB、RGBI、RGBIA、FONT。那么，对象如何导入这些类型，这些类型的载体如何设计的问题就变得非常突出。
我也可以像VB那样使用automation。但我必须与ITypeInfo、IPersist这些接口打交道，这是非常繁杂的。
经过了一些小规模的试验程序，我最终还是选择了automation。在设计软件时，其实很多互不兼容方法都可以完成相同的功能。但我们必须在其中选择一个。当然我希望我的思维足够严密，可以考虑到最大程度的可能性。但，往往事与愿违。当系统已经发展到了一定规模，突然发现一个至关重要的问题没有考虑到。这时只有两个选择，是打些补丁还是重新开始，真是很难抉择。我一般是重新开始，这是最令人沮丧的。
就像前面我说的那样，我非常不喜欢和ITypeInfo这类microsoft提供的接口打交道。原因只有一个，microsoft提供的文档即复杂又非常不明确，甚至没有相应的例子。但COM这种机制又导致这种复杂性。COM的机制导致了它必须是自描述的。以前我在设计COM组件时，当系统的接口和定义超过20个时我就会怀疑自己的方法是否非常愚蠢。但仔细回顾后，发现自己正在描述一个自包含的对象集，为了考虑到充分的可能性，也只能如此。
在这种设计中，我认为关键问题是通过ITypeInfo生成一个symbol table，它同时是类型描述的catch区。我不想把这个系统搞的像DTC（microsoft interdev design－time control）那么复杂，至少我不需要event。为了定义symbol table的element，我必须先定义系统所支持的变量类型。简化变量类型是非常必要的，至少在系统设计初期是这样的。基本变量类型如下：
VT_I2： "sort"
VT_I4："LONG"
VT_R4："single"
VT_R8："double"
VT_CY："CY"
VT_DATE："DATE"
VT_BSTR："BSTR"
VT_ERROR："SCODE"
VT_BOOL："VARIANT_BOOL"
VT_VARIANT： "VARIANT *"
VT_I1： "signed char"
VT_UI1： "unsigned char"
VT_UI2："WORD"
VT_UI4："DWORD"
VT_I8："__int64"
VT_UI8： "unsigned __int64"
VT_INT："int"
VT_UINT: "unsigned int"
VT_HRESULT："HRESULT"
VT_LPSTR："LPSTR"
VT_LPWSTR："LPWSTR"
可以看到这些都是在VARENUM中可以看到的VARIANT类型。对于用户自定义类型有如下支持：
ENUM
ALIAS
支持IDispatch的COM接口。
除了COM接口外，所有类型都不支持指针类型。COM接口必须是指针类型。
在上面的类型描述中，没有TKIND_RECORD类型。对此我犹豫了很常时间。导出RECORD指针可以大大简化对象编程并且提高的对象的运行速度。但它违背了dynamic creation support的很多原则，另外在属性赋值操作上也会有很多问题和不稳定性。它甚至可能使对象描述出现递归问题。因此在这里暂时忽略它，以后有了好的方法再说。
可能有人对该系统支持ALIAS有些不解。我是这样考虑这个问题的：我们在支持变量类型的可定制性的同时，也应该支持变量编辑的可定制性。例如：VT_LPWSTR可以作为对象名称的变量类型，同时也可以作为一种文件名称的变量类型。但对于两种使用我想应该有不同的用户处理方式。对于文件类型变量，我更希望在double click editbox或click property edit button后popup一个file open dialog。这时就不能使用默认的VT_LPWSTR编辑处理方式，需要一个单独的可注册类型编辑模块单独处理这个类型，这就需要ALIAS。
下面的问题就简单多了，定义一些符号结构、写几个函数递归ITypeInfo，来构造symbol table。
