在用现成的控件和自己开发之间你通常如何选择？
我想VB最重要的特色在于它可以以搭积木的方式来快速构造应用程序。

以前老虎说过，他通常不用非标准控件（所谓“标准控件”大概是指VB6内置的控件及ActiveX控件，约有几十个），因为不想给用户不熟悉的界面感受。不过，现在很多第三方控件并不存在这方面的缺陷，它们的界面美观、易用、符合通常的Windows应用程序的操作习惯。所以，老虎说的这一点不具有说服力了。

不过，用第三方控件有这样的问题，有时你花相当多的精力去熟悉它并把它纳入你的程序框架中，随着开发的进展，各种新的需求会冒出来，这时候，你发现有个重要的功能这个第三方控件它不支持，这时候不是很么？

也许有的朋友会说这是需求分析没做到位的事，这个我也不赞同。没有谁、即使是专业用户能在一开始就把需求想得特清楚的，尤其是用户交互这一块的需求，通常都是要做着做着会冒出新的想法的，这就是做软件的人必须接受、面对和适应的现实。就是说，到后期你发现之前选用的第三方控件不能满足需要的可能性是大大的，可能因此得重新写很多代码。

这么算下来，一折腾，用第三方控件倒反不合算了，不仅没让你快还让你绕远路了。要这么一通推理下来，貌似用第三方控件一点也不值得推荐了。。。

你们怎样看这个问题呢？遇到过这样事么？




[解决办法]
使用自己最熟悉的兵,而不是最强大最新的兵,这是比较稳当的做法.

第三方控件确实存在你所说的问题,因为它们毕竟是非微软官方的东东,BUG啊技术啊等我认为并不能比微软控制得更好.

对于小工程那当然是无所谓,出了问题大不了换.

大工程的话,那可就是一场灾难,所以我个人在一般情况下,还是比较小心使用第三方控件的.

即使要用,最好也不要完全围绕它来进行UI设计,除非我对它的了解达到非常深入的地步,详细掌握了它的每一个细节.

需求分析是否做到位了,这是一个方面,是受外因影响的.

而自己手里的兵是什么情况,就应该有十足的把握才行,不然吃了败仗后才发现居然是自己的阵地炸了,那....
[解决办法]
稳妥的做法是使用VB自带的标准控件和ActiveX控件.
[解决办法]
在下用vb时从不用非标准控件。自己也不会造控件，总感觉变一下思维事情就解决了。

[解决办法]
如果有商业关系，发现不够用就请求技术支持。
[解决办法]
用现成的
[解决办法]
一般情况，自己开发控件会蛋疼。用最熟悉的、有限的控件达到效果才是比较好的办法。就比如说MSHFlexgrid，要编辑功能，咋办？自己写？下第三方控件？其实往上面盖一个TextBox就行了……
[解决办法]
这其实不是技术问题。
在进行估价时需求没有细化是很正常的事情，但是工作量是按照需求提纲和方案设计（包括控件选用）估算的。
等到需求细化时明细超出预期的需求（无法实现的功能）要毫不犹豫地拒绝，除非追加工作量进行重新估价。

第三方控件除了操作习惯可能不同，其实最大的问题是技术支持。
有时候你明明按照帮助手册上的说明进行调用，表现行为却与预期不符。如果控件是通过代理购买的，问题反馈也要中间传一下，速度就慢。开发商排出本身问题后又要找环境的原因……
一圈下来很延误工时。哪像标准控件，你碰到的问题是别人早就解决了的。

老马说要用熟悉的控件非常正确，绝对不要选新奇的第三方控件，否则就是你花了自己的工时给人家做测试。
[解决办法]
使用自己最熟悉的兵,而不是最强大最新的兵,这是比较稳当的做法.
--------------------------------------------------
up 这句


接触VB 的时候只用工具箱中的 标准控件。


关于第三方控件，可以考虑它 是否 是你 "最熟悉的兵" ,

在尽可能的情况下避免重复发明轮子，但不等于 不定制轮子，根据需要也会开发自定义控件

自定义控件完全符合 "最熟悉的兵"