Интерфейсы писать - сложнее, если не пользоваться готовыми компонентами и/или не знать логику работы MFC. А грид - чем не устраивает то, что Chris Maunder наваял ? И вообще www.codeproject.com - много чего найти можно.

Уже говорено не раз. VC - для построения БОЛЬШИХ систем. Там, где время ваяния своих собственных визуальных компонент существенно меньше времени на ваяние продукта из этих компонент. Если это условие не выполняется - нечего GUI на VC строить. Хотя в принципе, на VC GUI тоже можно делать легко и просто, НО : с отработанным framework - наличием и опытом работы с библиотекой компонентов, подходящей (покрывающей) данную задачу. А если только осваиваете VC, тогда конечно ой :-)

2c127
>Да был там фреймворк и библиотеки классов всякие. Года два разрабатывали.

Ну, за два года можно много чего наработать! И со связями с БД и без.

>Правда они не были специально заточены под работу с БД. В результате те несколько форм, которые удалось написать выглядели очень красиво. Но на большее не хватило. Ну не бывает универсальных решений. Вопрос же не о том что можно-нельзя а о том что просто-сложно.

Это говорит о примитивной проблеме - отсутствии грамотной архитектурной постановки проекта !
Библиотеки/фреймворк подразумевают создание набора компонент (классов) с заданными свойствами, но главное : простых в использовании для данной задачи ! Т.е. схематично : суммарные затраты времени на библиотеку-1 год, на форму - 2-7 дней. Если же формы невозможно в итоге создавать быстро - надо признать, что разработка ТАКОЙ библиотеки была проваленным проектом.
И VC тут ни при чем.
Попросту говоря, ну кто мешает на VC реализовать тот же VCL, если хочется... Или что-то еще более навороченное. Вот только выплывает наружу простая вещь : КВАЛИФИКАЦИЯ. VC к ней более чувствителен. Именно потому, что СВОИХ решений приходится использовать больше, нежели стандартных компонент. Пример - в одной из разработок я использовал Chris Maunder grid. Для отображения инфы из ADO Recordset пришлось дописать унаследованный класс. Заняло (сумм.) около 3 ч/недель (с тестами). Использование такого класса в последующем проекте составляло ок. 3 ч. на написание и тестирование

2funikovyuri:
Ну да, полностью эмуляция Delphi, наверное не получится. Хотя, возможно, я просто не исследовал возможности framework :-) - не нужно было (Я про VS 6, потому как VS.NET - это практически та же Delphi по среде, лишь возможности обратной связи код- среда поменьше).
Про то, что квалификация - это в первую очередь использование - согласен абсолютно ! Но в VC готовых решений меньше (MFC менее мощная, чем VCL) и поэтому встает вопрос поиска/разработки самостоятельно (конечно не вместо, а вместе с MFC/ATL), что и ТРЕБУЕТ квалификации.
2c127:
Т.е. библиотека GUI - два человеко-года. Это немало. И дело совершенно не в среде разработки. За такое время можно было вполне примитивно сдублировать (раз уж Delphi - rulez) структуру VCL на базе MFC. Технология подмены классов известна давно (чтобы не делать все в виде ActiveX-ов). И дальше работать практически как с Delphi - набросал компонентов на формочку, переобозвал их своими классами, в инициализации написал присваивания свойств. В чем отличие далее ? В отсутствии Object Inspector ? (хотя я видел что-то подобное для VS6, но сам не юзал). В части обработчиков сообщений же его примерно на 90% заменяет Class Wizard. Но при этом библиотеку можно и нужно продумать так, чтобы она закрывала максимум потребностей проекта. Надо несколько проектов ? Хорошо, в базовую библиотеку делаем классы с общими свойствами, для конкретных проектов - наследуем и "добиваем" под проект. Далее используем библиотеку, которая заточена под проект. При условии приличных затрат времени на разработку базовой библиотеки и конкретных "проектных доработок", сам проект далее уже не должен отнимать много времени на GUI всяко.
Могу сказать честно, что я сам полностью такого не делал, но поучаствовал в подобном проекте, так что знаю, что говорю.
Кроме того делал мелкие (относительно) вещи, ну типа MDI приложение с одним видом документа, который весьма сложен - включает странички, на которых гриды, диаграммы и т.д. Источник документов - MSSQL через ADO (+серверная логика), но уровень ADO изолирован в связи с последующей (пока не реализована) версией получения данных через Инет. Вместе с изрядным освоением VC/MFC+MSSQL это заняло 4 чел./мес при использовании free grid'а (+мелочь типа усовершенствованного CRegKey) и купленного Teechart. И еще изрядно поимелся с также купленной библиотекой BCG Control Bar Pro, от которой впоследствии частично отказались, но частично оставили. И при дальнейшем расширении проекта я знаю, что добавление новых видов/документов при сохранении общих принципов интерфейса не вызовет особых напрягов в части GUI. Вот новый уровень передачи данных - это да...
Скорее всего, что на Delphi данный проект с использованием доп. библиотек занял бы меньше времени, но это уже выбиралось не мной.
В итоге я только хочу сказать, что время разработки может быть сопоставимо при определенных условиях.