Тяжелый конечно вопрос, но таки об этом задумался.
Думаю о Windows Forms Application VB.NET и о С (#.NET ???)
Вкратце(если получится вкратце):
1) VB6 - для меня USER интерфейс.
Придерживаюсь строго стиля текущей WIN OS без самодеятельностей, как правило модифицирую имеющиеся контролы (реже создаю) через API - хитрости, манифесты - для стиля, 32-битные иконки через ResHacker, всякие там WinProc и т.п. Ну в целом все красоты решаются -большим объемом нестандартных работ.
2) Использую API для решения ряда других прикладных вопросов. В частности очень много GDI+/-
3) В основном приложение VB6 состоит из форм и кучи модулей, классы терпеть не могу (использую наверно 2-3шт CMultiFrameImage от Бенедикта, ClsText, Splitter) и плохо в них разбираюсь, хотя в том же сплиттере и CMultiFrameImage модифицировал немало. OCX-ов никогда не писал, чужими (включая от Microsoft ) стараюсь не пользоваться, ActiveX.EXE не понял и не хочу, люблю CreateObject и оч. не люблю раннее связывание.
4). Использую БД аля MS Access через MS ADO и не о каких SQL и прочем слышать не хочу, мне достаточно.
5). Оч. люблю использовать Shell(proga.exe) и ShellAndContinue(proga.exe) -модификация Shell с контролем ожидания завершения вызванного процесса - как с системными, так и с нек. другими утилитами.
Ну, топиков моих тут много даб все это проиллюстрировать.
Если я правильно понимаю, новые VB/C(#?).NET + Windows Forms Application сильно облегчат создание красоты в части п.1.
Но при этом совсем без API все же думаю не обойтись. Ну т.е. все API, приемы и т.п. что я использую в VB хотелось бы иметь возможность также красиво использовать при необх.
Потом новые всякие прибамбасы. Какие-нибудь Ribbons (родные, от Win7) на VB6 небось при всем желании не вставишь -просто пример привел.
В пользу VB.NET думаю то, что язык хоть и отличается, но примерно такой же, т.е. если тупо пытаться переписывать имеющиеся чисто-VB6 проекты на VB.NET, то это сильно проще чем на C++#.
Но есть ряд подводных камней. Я много работаю с телефонией и использую в частности
OpalVoip , при этом уж не знаю хвастаться или стыдиться, даже перечислен в
списке разработчиков и имею доступ к репозиторию(сам правда править коды на сайте через SVN так и не научился - мож оно и к лучшему, а то еще понапорчу).
Стыдиться, это потому что C++ практически не знаю. Хотя умею тестировать и модифицировать имеющийся код библиотеки или консольного приложения.
Но стоит вопрос как пририсовать "морду" к приложению.
Если что-то запускаю из под VB6, генерирую из под VB6 "командный" файл и в зацикленном C++ консольном приложении использую конструкции типа:
1.
2.
3.
4.
5.
6.
7.
8.
void TheProga::Main()
{
...
for (;;) {
PThread::Sleep(500);
if( (_access( "the.file", 0 )) != -1 ){
DeleteFile("the_file");
//далее следует код куда звонить и чего делать...
Ну, аналогично, если C++ генерирует событие, то пуляет файл в сторону VB6, а VB6 ждет файл по таймеру и отображает что-нибудь на форме:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
void MySIPEndPoint::OnRegistrationStatus(const PString &aor, PBoolean wasRegistering, PBoolean reRegistering, SIP_PDU::StatusCodes reason)
{
if (reason == SIP_PDU::Information_Trying)
return;
PString FNM;
FNM = aor.Left(aor.Find(';'));
ofstream outfile(FNM + ".rrg");
if (reason == SIP_PDU::Successful_OK)
outfile << "Registered OK\n";
else
outfile << "Not Registered (" << reason << ")\n";
outfile.close();
}
Попытки установить прозрачное взаимодействие между VB6 и C++ давно закончились ничем, и до сих пор к этому не возвращался. Пока "пуляем файлы".
Жить конечно можно, живу, но все это сильно "тормозит развитие", и если нагрузка большая, то надежность приложения сильно снижается. Любой нормальный программист-профи обсмеет.
Если например, писать софтфон (идея как бы есть) с кучей кнопок и действий типа play/record/dial/hangup, то "форма-морда" и "интеллект-начинка" должны быть реализованы в рамках одного exe.
Т.е. по идее и в идеале хотелось бы (Я нарочно смешал C++ и VB6 код для иллюстрации желаемого решения типичной задачи):
1.
2.
3.
4.
5.
6.
7.
8.
9.
void MySIPEndPoint::OnRegistrationStatus(const PString &aor, PBoolean wasRegistering, PBoolean reRegistering, SIP_PDU::StatusCodes reason)
{
if (reason == SIP_PDU::Information_Trying)
return;
if (reason == SIP_PDU::Successful_OK)
Form1.LabelStatus.Caption = "Registered OK"
else
Form1.LabelStatus.Caption = "Not Registered (" & reason & ")"
}
Начинка на C, значит наверно нужен C(#).NET для формы. Это в пользу C.
Хотя Windows Forms Application в VC2005 EE на дурака даже в примитиве с одной кнопкой типа Dial пока прикрутить не удалось.
В примерах есть OpenPhone но он использует WxWigest -так понял "левая морда", слышал еще про MFC, но сдается что это не то и для виндов (чтоб просто и по стандарту) нужен WinForms.
===
Еще проблемы, которые периодически всплывают - уж не знаю насколько относится к вопросу - многопользовательская среда, запуск приложения под обычным юзером (я злоупотребляю админом), при этом настройки приложение хранит в CURRENT_USER и в HKEY_USERS\.DEFAULT\Software (для WIN Service кот. скажем прямо не совсем настоящий), данные прога хранит в /Program Files/Proga/etc. что подозреваю неправильно. Пользователей у кот. возникают иногда проблемы (в основном на серверах, куда лазют разные юзеры под своими терминалами), кормлю советами-затычками, что в прочем обычно помогает.
===
Таковы в общих чертах "проблемы мировой революции".
Ну т.е. в каком направлении мне посоветуете двигаться. C ? VB ? NET?
Для C стоит VC2005EE. Я так понимаю это называется C#. Не?
Если VB.NET, то чего ставить? Рабочая система - XP и думаю надолго, от вистов глаза рябит. Но проги должны работать (ну это рынок) соотв. up to WIN7 x64 и выше со всеми Themes (что впрочем худо-бедно и с VB6 правдами и неправдами достигнуто).
Крайняя попытка более менее серьезно ставить VB.NET была этак году в 2005, восторгов VB.NET не вызвала, правда стоит чего-то на нотебуке.
Чего не хочу, так это глубоко закопаться в что-то новое а потом понять что это не то что надо.
