当年多线程逃的课，终究是要还的

        近期开发遇到的一个问题，就是目前在做Word文件导出功能，导出功能都OK了，但是在此之上有个问题，就是数据量稍微大一些，等待时间就会较长，如果这中间没有给用户任何提示，就会造成用户以为程序死了的感觉。为了解决这个问题就要写个进度窗体，然后问题来了：多线程。

        首先在主窗体（M）创建一个隐藏的子窗体（C），用于执行导出步骤（某些原因需要这么写），然后隐藏的子窗体有一个SaveFileDialog（S），用以让用户选择保存位置，隐藏的子窗体会再创建进度窗体（P）。当我给P赋予独立的线程妄图使用多线程来分别处理C和P时，问题来了：c#在可以调用 OLE 之前,必须将当前线程设置为单线程单元(STA)模式

        ？？？这是个啥玩意，而且我的Main明明前面也写了[STAThread]了啊

        简而言之，结论就是这么处理走不通。虽然我对此的认识也不能保证百分百正确，但是我认为是这样的：

首先，每个窗体都单独占用一个线程，各个包含COM组件的线程之间出于线程安全考虑，强制使用线程同步处理，即就是一个窗体的内容执行到底了才能执行另一个，即使你给某个窗体另外创建了单独的线程来跑，最后程序也会报这个错，并且强制要求你把这条线程改为“STA”模式（单线程单元）。

       那么这条路真的走不通吗？是的，但是也未必，想要达到初衷依然是可以解决的（并且已经解决了），这里的原因就是带有我猜测的部分了。经过测试，我在P里设置了两个Public方法，用于改变进度提示文字和进度条进度，按照线程同步正常写，虽然窗体会卡住不会刷新，但是两个方法确实执行了，那么突破口来了：或许同步限制只针对窗体或者换言之是COM组件，那么接下来就可以使用Application.DoEvent()，它的机制是将你的应用中尚未触发的windows消息打乱次序、提前触发，用以实时响应。换言之，就是用它来强制“刷新”窗体。那么，代价是什么呢？古尔丹 这玩意会大大降低效率，不过经测试仍在容忍范围内，所以无所谓啦~效果跑出来了就好。