Are you going to standardise ?

Not that I am actually likely to be using it, but my guess would be that a lot of folks would start out with the Infragystics controls, since they are supported and pretty flashy.. Only if there is some other set of controls with which they are already familiar, e.g., from doing .NET frontends (which makes me wonder if they would go back to ABL) would they be likely to choose it over the Infragystics controls. Or, I suppose, if they know someone who makes a strong recommendation.

Then, as experience is gained they might find that there is something they can't do and look around or ask around for alternatives. This might lead them into a different family, but that would mean redeveloping the screens done with the Infragystics controls, so much more likely they will pick and choose for special needs.

Of course, this might all get blown away if someone picked a different set and publicized it heavily in the forums, but it would have to be a very compelling endorsement to lead people away from the Infragystics controls as a starting place.

All speculation, of course.

I feel like I'm going to standardize for the key components on a single vendor. I see the following advantages:

- common appearance / color set / UI profiles

- similarities when saving user profile settings

- interoperability between controls (i.e. editor controls in grid, combo, etc.)

- same doc set / user community

- internationalization

- ...

I do not care too much about the source code. It's good to know, that it's available. But many controls have been developed using rather low level code that I don't want to get in to. To change the behavior, inheritance seems a more advanced way.

I prefer to count on a well known vendor - one, where I can rely on the fact, that he's still on the market place when the next UI shift is dictated by Microsoft (or whom else).

Today Infragistics is my choice for the key components. And I use other controls where required.

Although I'm a little bit disappointed by Infragistics in terms of the structure of the objects. They could have done better in keeping the way we need to code closer for the whole control set.

Single vendor. Same look and feel. Same programming interface. Probably Infragistics controls because there are supported by Progress and there will probably be lots of examples, forum posts etc. about these controls. There are feature rich. And look good.

What would happen if Infragistics goes bankrupt or abandone the product? Is there a escrow arrangement? Has anyone read the small print?

Question: One could also argue that you should use first-party Microsoft controls. Can you replace the basic browser/viewer objects with Microsoft controls that can be found in the Microsoft .NET framework?

Question: One could also argue that you should use

first-party Microsoft controls. Can you replace the

basic browser/viewer objects with Microsoft controls

that can be found in the Microsoft .NET framework?

You could do that but would run into limitations pretty quickly. One of the USPs of Infragistics is Application Styling. If you intend to use that, you are practically forced to use Infragistics controls for everything. Come to think of it that is a real vendor lock-in feature. On the other hand, it is acceptable as Infragistics is the market leader and supported by Progress.

You could do that but would run into limitations

pretty quickly. One of the USPs of Infragistics is

Application Styling. If you intend to use that, you

are practically forced to use Infragistics controls

for everything. Come to think of it that is a

real vendor lock-in feature. On the other hand, it is

acceptable as Infragistics is the market leader and

supported by Progress.

Yes, the advantages of working with the Infragistics controls probably outweigh the disadvantages that are mentioned...

There are some things for me that make some of the controls a real PITA. Multiple-item selection in a navbar, for example.