2.vcl是源代码类库,类似于MFC类库,是可以看到源代码并可修改的,而vb里的控件大多是activex/com控件...是二进制形式的,两者有本质的不同.
3.Component Object Module...当你想在不同系统中运行一个功能模块时,当你想让人家能够使用你模块的功能而不想让人家看到你的源代码时...当......太多啦...

解决方案 »

  1.   

    使用com可以说是更一级的继承,也就是说是接口级别的一种继承
    也是和VCL的一点区别
      

  2.   

    .Component Object Module...当你想在不同系统中运行一个功能模块时,当你想让人家能够使用你模块的功能而不想让人家看到你的源代码时...当......太多啦...
    to gameboy999
    如果是这样解释.那它不就跟activex控件是一个道理了呀.它也是只能用不能改的呀..
      

  3.   

    com是实现二进制的面向对象的一种方法
      

  4.   

    我觉得VB并不是一个很完整的OOP开发工具,因为他对类的支持太少了。
    在VB中定义类,只能用Class Module,而且定义的类无法继承,所以比VC差了很多。
    但是VB制作软件方面,特别是应用软件却比VC强,简单好用。
    所以VB也是很可爱的。
      

  5.   

    谢谢nicrosoft.谢谢求败.谢谢大家.看来我要更努力了.....嘻嘻
      

  6.   

    这下面是有关com的一点简介(就是非专业的简介了)If you've used Visual Basic much, you're very familiar with using components to do your programming: you use both visual ActiveX controls (such as spin buttons) and nonvisual ActiveX components (such as database access objects). It's hard to find a significant Visual Basic program that doesn't make heavy use of premade reusable components. But although you reuse plenty of components, most folks don't yet write a whole lot of reusable components of their own.If you're programming in C++, you likely have a different experience of reuse. C++ and object-oriented programming claim to make reuse easy, but what has your experience been? Have you been able to create a library of reusable objects? A few of you no doubt have, but most of us have not. And if we have such a library, do we routinely make good use of it? It's not just a lack of discipline that keeps us from reusing our code: the fact is that it's hard to reuse code (it never seems to do quite what we need) and it's even harder to write reusable code (it's very hard to be general enough yet useful enough).On top of that, what C++ makes easy is not creation of reusable binary components; rather, C++ makes it relatively easy to reuse source code. Note that most major C++ libraries are shipped in source form, not compiled form. It's all too often necessary to look at that source in order to inherit correctly from an object—and it's all too easy (and often necessary) to rely on implementation details of the original library when you reuse it. As if that isn't bad enough, it's often tempting (or necessary) to modify the original source and do a private build of the library. (How many private builds of MFC are there? The world will never know . . .)