看到很多朋友都有跃跃欲试的想法。
特地将我目前刚刚接到的一个Project 公布在这里，如果你有你的完整的算法，可以在这里交流，

我目前还没有和Project委托方谈妥价格，待价格谈妥后，我会告诉你，你所能获得的报酬。估计不会低于1000欧元，只有提供完整代码的朋友才能获得我所支付的报酬。对有价值的完整算法（无代码），我也将考虑支付一定的报酬以致奖励。

对于代码所使用的语言不做限制，你可以使用任何你所熟悉的语言。

Project的具体内容如下：
某个药房，为了配合ISO质量评定，制定了一系列QMS(Qualities Management System) 文档。这些文档目前以分散的形式存放在计算机硬盘内。 这就使得阅读这些文档很不方便。
你的任务是写一个应用软件，来整合这些文档，确切的讲，通过你的软件可以将这些文档整合起来，使得其成为一本书。这个软件可以对这本书进行加工，比如修改该章节内容，添加章节，删除章节，当然任何章节还可以包含其自身的子章节，这些子章节也同样可以被加工（修改内容，添加，删除）对于目录来讲必须提供 link 的功能，也就是说，点击目录能够转到该目录的当前页。
任何章节必须提供history 这个功能， 所谓History 功能是指，如果你对该章节修改以后，必定要覆盖其原有的内容，但是不能因为覆盖了其原有的内容而使其原有内容彻底消失，而是其原有内容成为了该章节的history, 使得文档访问者有可能访问其history, 这样在必要的时候可以复原，history 必须保持向后两步的history.
由于该软件支持文档的加工，那么这里所指的文档加工，也包括制表，以及绘图功能。

笼统来讲，这是一款类似于MS-Word 或 PDF-Reader的软件，另外还多出了一些客户的特殊要求的实现。

软件的具体要求还会有所变动，这个取决于客户的需求。

大约就是这些，如果你有想法，或有疑问，可以在这里提出来，也可以联系我本人。

knocker,
先谢过，不过不符合我意。
我不需要什么OLE， 所有功能必须由软件自己实现。这几天很忙，该项目还没有时间开始。

不过布局是可以的，我也是此意。

knocker,

如果word 的功能符合要求的话，那么委托方何必让我来写程序？如果用你的方法，那才是多此一举，直接拿MS-Word 用不是更好？ 如果Adobe也像你们这么想，那么就不会有PDF了。

请注意我在1楼写的项目要求， 该软件要实现history 功能，要实现编辑功能。我给大家一个网页，这个网页的某些功能在一定意义上符合我的要求。下面是连接：http://en.wikipedia.org/wiki/Computer_science
这只是一个例子， 请注意它的edit 功能， 我所要实现的是，当你按下Edit按钮的时候，你可以编辑当前文档，然后存储，同时原先文档成为当前文档的最近history, 如果你再次编辑该文档，那么第一层面的history 就成为第二层面的history 了，依次类推。 之所以要有这个 history 是为了能够看到文档编辑的过程，以此能够看到企业的发展过程。

这款软件是独立的文档编辑器和阅读器，如果具有对其他文档格式的文档的调阅功能比如对MS-Word， MS-Excel。。。 的调阅，那当然很好， 不过不是必须。

我也不知道大家对软件开发到底有没有概念，感觉上大家没什么概念。
我是自己摸索的，没有人教过我。

我看到Knocker一上来就给了我一个大概的框架程序，这样做当然是可以的。

我说说我的一些想法吧。

写软件呢和写一般的那些趣味小程序是一样的，如果你一上来就写代码，像开无轨电车一样，想到那儿写到那儿，那肯定是不行的。这就是说，你一上来呢，先要设计一下，这个设计其实就是为整个问题建立一个数据结构，接下来就是建立一个大概的框体程序，就像knocker 现在做的那样，然后再次对问题分析，这个时候你要分析当每一个控件作用的时候会发生什么事，将整个流程写在纸上，现在再回到你的第一步建立的那个数据结构，你看看那个数据结构是不是符合要求，如果不符合，那么改善它。(通常那个数据结构会不停地被修改) 然后不断的丰富你的窗体内容，直到程序最终完成。

我建议大家先在数据结构这个层面谈谈看法。
我心中基本已有一个底。

Knocker，
通过对这个问题的讨论，我也想让你对OOP有一个比较清楚的了解。

我也反感过，但是我觉得人应该虚心的学习，广纳百川，方为大海。
你应该问这么个问题，为什么OOP有其如此大的生命力？