本人封装的一个VB创建多线程的API函数（标准DLL）,很实用,使用方便,欢迎试用、提意见！(首发于VBGOOD)
本帖最后由 taoguangye 于 2011-11-25 12:58:55 编辑
本站下载地址http://download.csdn.net/detail/taoguangye/3841198 最新正式版（1.0.282）:
http://www.vbgood.com/forum.php?mod=redirect&goto=findpost&ptid=108165&pid=624176&fromuid=231244 不从编译器着手，一切都是徒劳 VB对多线程的支持，我个人坚定的认为不敢恭维。反正我曾经很发力的搞过，都不成功，很不稳定。 VB 的多线层不稳定主要是线程运行环境与VB环境不同引发的开发理念不同所导致的。
因为用 Windows API 创建的线程直接运行于 Windows 的 Win32 子系统，直接由系统的 Win32 子系统管理
进程中的线程(包括时间片分布、内存管理等等)，但 VB 的程序不是直接运行于 Win32 子系统的，而是由
VB 运行库来分配管理这些进程线程资源的。当然，VB 运行库也是运行于 Win32 子系统，但这样一来，
VB 的应用程序与直接运行于 Win32 子系统的程序中间就间隔了一层，这就意味着两者之间肯定存在着一定
的差异，如果在线程中还保留着 VB 的开发理念去写程序，很容易造成理念上的错误或资源访问差异的问题。
最终很容易导致程序奔溃的结果。可以说，如果在 VB 里搞多线程程序，就要用 Windows SDK 的思路去开发，
不能再用 VB 的思路去开发，不然就很容易出问题，因为这个线程的运行环境是直接的 Win32 子系统，而不
是依赖于 VB 的运行库。很多人在还没有理解这个 Win32 子系统与 VB 运行库概念的时候，常会出现程序
奔溃的问题，但是当了解了Win32 子系统与 VB 运行库的概念后，虽然编写的 VB 程序可以避免问题的产生，
但换个角度来看，其实用 C/C++ 来实现会发现过程更简单，也不至于无法单步调试这么不方便，而且开发
理念也不容易混乱，可以说概念更清晰，但如果在 VB 里必须把 Basic 写成 C 语言的概念一样，即使能写
也会觉得怪怪的，时不时还会范些理念上的错误，可以说如果用 VB 写这种过程会很累，就像在 Basic 代码
中嵌入 C 语言，而且还得用 Basic 来写出 C 语言的效果，这才叫人烦恼。
比如在线程中使用 Redim 语句(只是比如)，这就用到了很多资源，虽然 VB 里看上去简单，但在实际的技术
中，这是使用了 COM 标准接口的 VARIANT 类型并对其分配空间的操作，要处理这个数组在 SDK 方式中还要
使用好几个 API 和结构体才能实现这个功能，但在 VB 里并不是调用这些API来处理的，而是 VB 运行库中
包含了相关的处理过程，而对于没有加载相关 API 的 Win32 子系统的新线程来说，这个语句可能就会引发
无法找到相关函数资源的问题导致程序失败而奔溃。虽然实际情况可能并非如此，但这种类似概念的情况是
肯定存在的。个人感觉这样在VB里写多线程即使写成了也很累，还不如直接用 C/C++ 来写得方便。 学习学习了， 看看怎么 跑多线程。 有时间看一下 学习了~
VB的多线程不敢用。。 好东西，多多学习!
以前我以这么认为，直到我写出这个DLL，但稳定性主要在于VB本身控件的线程安全性上，只要尽可能不让多线程同时访问对象和控件，几乎没有什么问题。
线程函数中redim 没有问题，dim f(33) 这种固定数组也没有问题，不信你试试。 我个人认为,其实最稳定的VB6多线程方案,还是微软自家的单元线程了.
确实因为线程安全问题,多线程工程中无法使用MDI窗体及非线程安全的控件,但是如果仅作为处理过程的线程级封装的话就多数情况下够用了吧.
再说了,VB6编程里需要用到多线程的地方其实主要还是费时操作为主,这样的话一般来说就足够了.
提到运行库的话，就与根本原因接近了，不过在关键点的地方偏离了。。。
运行库并非导致该问题的必然愿意，如果是C＋＋写一个多线程的单线程模型的运行共享对象，则一样会挂，哪怕完全用 atl写，不用mfc也是如此；
究其原因，很简单。。。 想研究vb的多线程就先研究研究COM对象吧，研究完了也就不说vb不支持对象了，也就不再提用vb实现多线程了。。。
增加activex dll方式使用，详见：
http://www.vbgood.com/forum.php?mod=redirect&goto=findpost&ptid=108165&pid=624473&fromuid=231244 线程函数可以不用写在标准模块中,可直接写在类事件thread中了.呵呵
补充：VB , API
