Against 3rd Party

Today I was “schooled” on the problems with using 3rd party controls in
a software project.  The arguments were valid, if you hadn’t ever
gone through the process of using a 3rd party control.  Below I
list the points made, and my counter points.  One thing to always
remember when the discussion turns to the UI is that nobody on this
project, myself excluded, has any experience creating a UI.

1.  Once using a 3rd party control you are beholden to the whims of that company’s release schedule.

1a. Once using a 3rd party control, and it is functioning as required
without error, you no longer should worry or care about that company’s

2.  Controls developed by 3rd parties don’t include all the functionalities required for the project.

2a.  Have you even researched a 3rd party control for this functionality?  For any functionality?

3.  When looking at a 3rd party control, I was worried about the
amount of code that it added to the #Region (.NET environment) 
section of the application / form.

3a.  Why does 100 lines of code, that you don’t have to write or
maintain, scare you?  Is it because it’s object oriented? 
Then it must be because it’s better than what you can write.

4.  The deployment cost of 3rd party controls in our business / software model is prohibitive.

4a.  For some perhaps, but we’re talking about a combobox here, not something from ESRI.

5.  Successful deployment of 3rd party controls is an extremely difficult prospect.

5a.  If it were Crystal Reports, then yes, but we are talking
about a combobox here.  Say have any of you actually created and
managed an installation package using a tool like Installshield or WISE
or Package and Deployment Wizard?  No?  Didn’t think so.

I did get permission to look for a combobox after 30 minutes of
discussion like I’ve noted above.  We’ll see what happens next.