Здравствуйте, AndrewVK, Вы писали:

AVK>Зависит от проекта и начальных знаний. Если есть знания джавы то через пару недель можно начинать, если С++ или Дельфи то через месяц-полтора. Это естественно я по себе мерю.

Про Java я не понял, прости. Чем знания Java лучше, чем знания C++ или Delphi?

Здравствуйте, econt, Вы писали:

E>Про Java я не понял, прости. Чем знания Java лучше, чем знания C++ или Delphi?

Тем что дотнет ближе к джаве по духу, нежели к С++ и Дельфи

Здравствуйте, econt, Вы писали:

E>Здравствуйте, AndrewVK, Вы писали:

AVK>>Зависит от проекта и начальных знаний. Если есть знания джавы то через пару недель можно начинать, если С++ или Дельфи то через месяц-полтора. Это естественно я по себе мерю.

E>Про Java я не понял, прости. Чем знания Java лучше, чем знания C++ или Delphi?

В одной книжке было написано что Ява это улучшенный С++, а С# это улучшенный Ява

Вообщем по скорости изучения .Net лидирует по сравнению с ATL + MFC (я например вообще учился параллельно учавствуя в проекте Правда в этом есть свои минусы Некоторые вещи приходится переделывать )

Насчет GUI незнаю (я им не занимался) Самое лучшее это наверное Delphi но он пока не .Net-ий так что взаимодействие с другими модулями будет проблематично Он вообще какой то проблематичный (по своему опыту скажу)
В .Net что хорошо это то что все можно в последствии утащить в веб (без каких либо затруднений)
А что ты подрузомевал под ATL? Если COM то тогда .Net тут лидирует на 100% (так же если имеешь ввиду ATL 3.0 но на 200% )

+ в сторону С# это то что программы пишутся очень быстро

Здравствуйте, econt, Вы писали:

E>А наводящий вопрос можно? Чем именно В ЭТОМ проекте Вам не подошел MFC? И почему сначала решили MFC использовать? Возможно после Вашего ответа будет легче сориентироваться...

Война начиналась так: а не сделать ли нам программку для бухгалтерии с возможностями Access.
Берем VBA SDK, на нем есть примеры, понятно, что под MFC. Имеются также инклюды, всего-то мегабайтик. В них тоже все под MFC+ATL заточено.
Поскольку VBA зверь темный, и что ему нужно для жизни — неизвестно, принимается решение писать под тем, на что заточены инклюды.
Через некоторое время, когда интерфейс в целом организовался, оказалось, что библиотечные навороты не дают возможности создать полноценные экранные формы. Причем в принципе. Контейнер MFC оказался слишком громоздким для использования встроенных контролов, ATL не рассчитан на динамические TypeInfo.
Итог — визуальное представление форм осталось на MFC. Контролы используют ATL окна. Слишком много кода было написано до революции. И все.
Но что творится в душе этих библиотек — мне, например, до конца не известно.

Здравствуйте, Jekky, Вы писали:

J>Война начиналась так: а не сделать ли нам программку для бухгалтерии с возможностями Access.

Тогда интересно, чем вам Access не подошел? Если это программа для бухгалтерии, то Access для этого нормально подходит. Хотя интерфейс может кому-то чем-то не понравиться.

J>Берем VBA SDK, на нем есть примеры, понятно, что под MFC. Имеются также инклюды, всего-то мегабайтик. В них тоже все под MFC+ATL заточено.

В примерах всегда все красиво выглядит. На практике все гораздо хуже и сложнее. MFC — монолитная библиотека и не любит, когда программист пытается выйти за рамки установленных в ней правил. Простейший пример: попробуйте выполнить API-функцию EnableMenuItem(). Или попробуйте сменить пару Документ-Вид...

J>Поскольку VBA зверь темный, и что ему нужно для жизни — неизвестно, принимается решение писать под тем, на что заточены инклюды.

Ой, не нужно было принимать решение только на этой основе.

J>Через некоторое время, когда интерфейс в целом организовался, оказалось, что библиотечные навороты не дают возможности создать полноценные экранные формы. Причем в принципе. Контейнер MFC оказался слишком громоздким для использования встроенных контролов, ATL не рассчитан на динамические TypeInfo.

Естественно. Люди для этого свои библиотеки пишут, иногда даже со встроенной скриптовой обработкой.

J>Слишком много кода было написано до революции.

Вполне может быть, что теперь вам уже поздно что-то переделывать. Это можете решить только вы, как разработчики.

J>Но что творится в душе этих библиотек — мне, например, до конца не известно.

Ну, для этого есть исходные тексты, которые во многих случаях действительно способны помочь. По крайней мере можно посмотреть, как организована конкретная возможность библиотеки и сделать вывод о том, стоит ли это использовать.
Можно долго спорить о том, стоит ли использовать MFC. Можно привести высказывания выдающихся людей, как в защиту MFC, так и против. Позволю себе процитировать высказывание одного человека — Чарльза Петзольда:

Мне никогда не нравилась MFC. Еще до выхода этой библиотеки у меня сложилось
отрицательное впечатление об ее конструкции, более того, я считаю, что MFC
едва ли можно назвать объектно-ориентированной библиотекой.

С моей точки зрения, библиотека Windows Forms организована намного лучше, чем
MFC, и в моем представлении она намного ближе к идеальному
объектно-ориентированному интерфейсу для Windows.

Очевидно, что MFC и Windows Forms не только повышают производительность
программиста, но и, подобно любому интерфейсу более высокого уровня,
обладают меньшей гибкостью по сравнению с интерфейсом более низкого уровня.
Windows API позволяет делать много такого, что невозможно при использовании
классов Windows Forms.

Программирование для Microsoft Windows на C#
Charles Petzold,
стр. XIV
www.charlespetzold.com

Мне остается только присоединиться к мнению уважаемого мной человека.

А вообще, насколько я понимаю, у зарубежных фирм есть тенденция создавать свои библиотеки и вести свою документацию по ним. Поэтому любой программист фирмы может использовать эту библиотеку. Возможно IT сможет рассказать подробнее...

Здравствуйте, MikaRSDN Soukhov, Вы писали:

MS>Здравствуйте, econt, Вы писали:

E>>Здравствуйте, AndrewVK, Вы писали:

AVK>>>Зависит от проекта и начальных знаний. Если есть знания джавы то через пару недель можно начинать, если С++ или Дельфи то через месяц-полтора. Это естественно я по себе мерю.

E>>Про Java я не понял, прости. Чем знания Java лучше, чем знания C++ или Delphi?

MS>В одной книжке было написано что Ява это улучшенный С++, а С# это улучшенный Ява

MS>Вообщем по скорости изучения .Net лидирует по сравнению с ATL + MFC (я например вообще учился параллельно учавствуя в проекте Правда в этом есть свои минусы Некоторые вещи приходится переделывать )

MS>Насчет GUI незнаю (я им не занимался) Самое лучшее это наверное Delphi но он пока не .Net-ий так что взаимодействие с другими модулями будет проблематично Он вообще какой то проблематичный (по своему опыту скажу)

А чем не нравится родное GUI .Net?

MS>В .Net что хорошо это то что все можно в последствии утащить в веб (без каких либо затруднений)
MS>А что ты подрузомевал под ATL? Если COM то тогда .Net тут лидирует на 100% (так же если имеешь ввиду ATL 3.0 но на 200% )

MS>+ в сторону С# это то что программы пишутся очень быстро

Здравствуйте, Ursus, Вы писали:

U>А чем не нравится родное GUI .Net?

Мне он очень нравится (по сравнению с тем же MFC)
Просто у нас в конторе есть программисты пишущие на Delphi Так они делают задания по GUI намного бысрее чем C#-цы Почему? Но если дело доходит до чего то сложно, то тогда все. Стопор.

Здравствуйте, MikaRSDN Soukhov, Вы писали:

MS>Здравствуйте, Ursus, Вы писали:

U>>А чем не нравится родное GUI .Net?

MS>Мне он очень нравится (по сравнению с тем же MFC)
MS>Просто у нас в конторе есть программисты пишущие на Delphi Так они делают задания по GUI намного бысрее чем C#-цы Почему? Но если дело доходит до чего то сложно, то тогда все. Стопор.

Два вопроса
1) C#-цы специализирутся на GUI?
2) А под Дельфями они пользуют внешние GUI компоненты?

Я думаю просто пока не наработан навык работы с C# в GUI такой какой был наработан в Дельфе. И не ватает компонент ( гриды, списки специалиированные, деревя хитрые и так далее )

У нас, например выигрыш вроде бы имеется ( по сравнению с VB ) и чем сложнее интерфейс тем жэтот выигрыш больше. Правда пока используется почти тот же стиль что и в VB, ну не привык народ к OOП в GUI

Здравствуйте, econt, Вы писали:

E>А вообще, насколько я понимаю, у зарубежных фирм есть тенденция создавать свои библиотеки и вести свою документацию по ним. Поэтому любой программист фирмы может использовать эту библиотеку. Возможно IT сможет рассказать подробнее...

Именно так и должно быть, по идее. Вопрос в ее наличии

Здравствуйте, MikaRSDN Soukhov, Вы писали:

MS>Мне он очень нравится (по сравнению с тем же MFC)
MS>Просто у нас в конторе есть программисты пишущие на Delphi Так они делают задания по GUI намного бысрее чем C#-цы Почему?

Опыт, наработки.

Здравствуйте, Ursus, Вы писали:

U>Два вопроса
U>1) C#-цы специализирутся на GUI?
нет
U>2) А под Дельфями они пользуют внешние GUI компоненты?
я не знаю Я не Дельфист

U>Я думаю просто пока не наработан навык работы с C# в GUI такой какой был наработан в Дельфе. И не ватает компонент ( гриды, списки специалиированные, деревя хитрые и так далее )

U>У нас, например выигрыш вроде бы имеется ( по сравнению с VB ) и чем сложнее интерфейс тем жэтот выигрыш больше. Правда пока используется почти тот же стиль что и в VB, ну не привык народ к OOП в GUI
Может и у нас до этого дойдуи

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, MikaRSDN Soukhov, Вы писали:

MS>>Согласен MFC + ATL <<<< .Net Так что только чистый С#

ГВ>Ой ли? ИМХО, исходно сделано противопоставление иного характера — своё vs чужое "стандартное". И здесь подсовывать агрегат вместо инструмента (я имею ввиду .Net в качестве агрегата vs C++ в качестве инструмента) ты считаешь правомерным?

А что неправомерно в таком постинге? Смысл очевиден: чужое "стандартное", но не МФЦ/АТЛ, а .НЕТ.
Впрочем, MikaRSDN Soukhov сам может объяснить.