надо интегрировать Qt модули в MFC приложение

[Гурман]

поиском нашел похожие темы, но когда прочел - не совсем то, что в моем случае, если пропустил, все равно просьба отнестись с пониманием

есть на данный момент приложение, разрабатывавшееся несколько лет, разными людьми, с использованием MFC

приложение объемом около 40000 строк, довольно сложное, работает со специфичной аппаратурой, имеет свой пользовательский интерфейс в виде MDI, меню, использует rich text в окне, множество форм ввода, рисует графики, и т.д.

надо разработать для него дополнение, имеющее развитый графический интерфейс, при этом оно должно использоваться в дальнейшем в приложении для Linux - решено разрабатывать его на Qt4, сначала интегрировать в имеющееся приложение на MFC, затем использовать уже в native Qt-приложениях в Linux

с Qt3 дело имели, про Qt4 читали, с самими библиотеками разберемся...

есть сомнения в возможности интеграции MFC и Qt4 в одном приложении - на doc.trolltech.com нашел только описание по миграции с MFC на  Qt3, про подобные действия с Qt4 ничего не вижу

кто-нибудь реально делал такое? какие подводные камни нас ожидают? где прочитать про интеграцию Qt4 и MFC? видел ссылку на книгу, где вроде описано про использование Qt в Visual Studio - там есть про интеграцию с MFC?

[Rcus]

http://trolltech.com/products/appdev/add-on-products/catalog/4/Windows/qtwinmigrate/

[Гурман]

спс, уже что-то, хотя похоже не на 100% то, чего хотелось бы

как вижу, там для Windows Migration Framework требуется коммерческая лицензия Qt - покупать ее ради миграции нам нет смысла, поскольку приложение разрабатывается для внутреннего использования, а Linux-версию предполагаем распространять под GPL (когда решим продавать, тогда и вопрос о коммерческой лицензии на Qt встанет)

другие варианты интеграции с MFC возможны? без покупки коммерческих лицензий

и все равно остаются сомнения, хочется пообщаться с теми, кто имеет опыт аналогичного перевода приложений подобного объема

мало ли что там может быть не так... например, классы для rich edit control у MS вообще очень плохо описаны и работают не совсем предсказуемо

[Sergey B.]

Может имеет смысл переписать всё с нуля?
На Qt это будет в разы быстрее MFC, однозначно.

[Гурман]

нет, это не реально, там много завязок под MFC, не только в интерфейсе, программа разрабатывалась с 90-х годов

[BRE]

нет, это не реально, там много завязок под MFC, не только в интерфейсе, программа разрабатывалась с 90-х годов

Как программа работающая со специфичной аппаратурой, может быть сильно завязана на GUI (и MFC в частности)?
Может сейчас самое время разделить функционал от GUI, а заодно и перейти на использование Qt?

[Гурман]

переход планируется в разработке следующих версий программы, это займет года два, и не переписываться с MFC на Qt все будет, а разрабатываться практически с 0, поскольку аппаратура тоже изменится

программа сложная, это измерительно-аналитический комплекс, GUI используется для управления аппаратурой и представления результатов

сейчас к нему надо приделать некоторую функциональность (примерный объем 7-10 тыс строк на С++), чтобы люди, которые им пользуются, продолжили работать с отлаженным комплексом, и получили новые необходимые функции, а если переписать влоб на Qt, это займет лишнее время, давать сразу в использование это будет нельзя, и результат нам не нужен, поскольку мы получим тот же софт, с теми же архитектурными и сервисными недостатками, только на Qt, хотя сейчас уже известно, как его надо делать по-другому

срок выделен небольшой, всего полгода, можно было бы используя MFC добавить необходимые функции, но поскольку дальнейшая разработка будет на Qt, имеет смысл уже сейчас эту функциональность на нем и реализовывать

тут все уже рассмотрено и посчитано - нам нужен единственный вариант - интегрировать большой кусок, разработанный с использованием Qt в большую и старую систему, написанную на MFC, и при этом мы не планируем покупать лицензию Qt, поскольку не планируем этот софт продавать (лицензия на Visual Studio у нас разумеется есть)

[Admin]

Только учтите начав разрабатывать программу на GPL QT.
вы можете навсегда забыть о смене лицензии для этой программы.

[Гурман]

дополнение для нынешней программы нужно только нам, распространяться за пределы предприятия оно не будет

а дальнейшая разработка новых версий - это отдельный вопрос, тем более, что без аппаратуры этот софт не имеет никакого смысла

[Tonal]

Если дополнение будет работать как модальный диалог, то ничего дополнительного не нужно - перед показам создавай QApplication и запускай диалог. После закрытия грохни и диалог и QApplication.

В противном случае таки найди исходники указанной либы и посмотри как она устроена.
Сделать по аналогии - труда не составит и лицензию не нарушишь.

[Гурман]

увы, не как модальный - по сути это должен быть встроенный отладчик для встроенного скрипта (который сейчас без отладчика выполняется)

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

и что, Qt Windows Migration Framework реально найти в сорцах? 

[BRE]

увы, не как модальный - по сути это должен быть встроенный отладчик для встроенного скрипта (который сейчас без отладчика выполняется)

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

и что, Qt Windows Migration Framework реально найти в сорцах? 

Так может сделать отладчик отдельным приложением и осуществлять взаимодействие пайпами, tcp/ip,  разделяемой памятью или еще как?

[Гурман]

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

[BRE]

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

Ты про удаленную отладку слышал? Когда код выполняется на целевой машине, а "морда" отладчика работает за тысячи километров на другой машине. Примерно так там все и происходит.
Хотя если отладчик тесно интегрирован с функциональным редактором, а еще и с исполняющей системой скрипта, то.... 
Можно только сказать огромное спасибо архитектору данной системы.

[Гурман]

там все разрабатывалось с начала 90-х годов, какая тут нафик архитектура?...

дело в том, что интеграция отладчика прямо в приложение - это минимум временных и трудовых затрат, поскольку он будет сразу работать с теми же структурами данных, что и основное приложение

а если его отделить от приложения, то надо разработать для них интерфейс коммуникации, отработать канал связи между ними - это все дополнительные время и деньги, но... такая функциональность никому не нужна, она не дает ничего полезного, кроме возможности сделать отладчик на целиком бесплатном Qt, что тут же будет компенсировано затратами (зарплатами) на реализацию...

вот в следующей версии, мультиплатформенной, разработанной уже по другой архитектуре - там не только возможно нечто аналогичное, но и планируется, из-за чего Qt, с его удобным механизмом сигналов-слотов очень хорошо подходит

то есть, сейчас интегрировать отладчик в приложение - технически и организационно гораздо проще