Russian Qt Forum
Ноябрь 05, 2024, 15:24 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: [1]   Вниз
  Печать  
Автор Тема: надо интегрировать Qt модули в MFC приложение  (Прочитано 10517 раз)
Гурман
Гуру общения
******
Offline Offline

Сообщений: 1442

Qt 2.2, 3.3, 4.5, 4,7, 4.8, 5.3, 5.6, 5.9, 5.12


Просмотр профиля
« : Декабрь 10, 2008, 11:42 »

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

есть на данный момент приложение, разрабатывавшееся несколько лет, разными людьми, с использованием 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?

Записан

2^7-1 == 127, задумайтесь...
Rcus
Гость
« Ответ #1 : Декабрь 10, 2008, 11:54 »

http://trolltech.com/products/appdev/add-on-products/catalog/4/Windows/qtwinmigrate/
Записан
Гурман
Гуру общения
******
Offline Offline

Сообщений: 1442

Qt 2.2, 3.3, 4.5, 4,7, 4.8, 5.3, 5.6, 5.9, 5.12


Просмотр профиля
« Ответ #2 : Декабрь 10, 2008, 12:10 »

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

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

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

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

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

2^7-1 == 127, задумайтесь...
Sergey B.
Программист
*****
Offline Offline

Сообщений: 544



Просмотр профиля WWW
« Ответ #3 : Декабрь 10, 2008, 18:16 »

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

Сообщений: 1442

Qt 2.2, 3.3, 4.5, 4,7, 4.8, 5.3, 5.6, 5.9, 5.12


Просмотр профиля
« Ответ #4 : Декабрь 11, 2008, 09:41 »

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

2^7-1 == 127, задумайтесь...
BRE
Гость
« Ответ #5 : Декабрь 11, 2008, 09:58 »

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

Сообщений: 1442

Qt 2.2, 3.3, 4.5, 4,7, 4.8, 5.3, 5.6, 5.9, 5.12


Просмотр профиля
« Ответ #6 : Декабрь 11, 2008, 10:05 »

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

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

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

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

тут все уже рассмотрено и посчитано - нам нужен единственный вариант - интегрировать большой кусок, разработанный с использованием Qt в большую и старую систему, написанную на MFC, и при этом мы не планируем покупать лицензию Qt, поскольку не планируем этот софт продавать (лицензия на Visual Studio у нас разумеется есть)
« Последнее редактирование: Декабрь 11, 2008, 10:16 от Гурман » Записан

2^7-1 == 127, задумайтесь...
Admin
Administrator
Джедай : наставник для всех
*****
Offline Offline

Сообщений: 1988



Просмотр профиля
« Ответ #7 : Декабрь 11, 2008, 10:21 »

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

Сообщений: 1442

Qt 2.2, 3.3, 4.5, 4,7, 4.8, 5.3, 5.6, 5.9, 5.12


Просмотр профиля
« Ответ #8 : Декабрь 11, 2008, 10:35 »

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

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

2^7-1 == 127, задумайтесь...
Tonal
Гость
« Ответ #9 : Декабрь 11, 2008, 11:30 »

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

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

Сообщений: 1442

Qt 2.2, 3.3, 4.5, 4,7, 4.8, 5.3, 5.6, 5.9, 5.12


Просмотр профиля
« Ответ #10 : Декабрь 11, 2008, 11:43 »

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

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

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

2^7-1 == 127, задумайтесь...
BRE
Гость
« Ответ #11 : Декабрь 11, 2008, 12:01 »

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

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

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

Так может сделать отладчик отдельным приложением и осуществлять взаимодействие пайпами, tcp/ip,  разделяемой памятью или еще как?
« Последнее редактирование: Декабрь 11, 2008, 12:06 от BRE » Записан
Гурман
Гуру общения
******
Offline Offline

Сообщений: 1442

Qt 2.2, 3.3, 4.5, 4,7, 4.8, 5.3, 5.6, 5.9, 5.12


Просмотр профиля
« Ответ #12 : Декабрь 11, 2008, 12:20 »

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

Записан

2^7-1 == 127, задумайтесь...
BRE
Гость
« Ответ #13 : Декабрь 11, 2008, 12:33 »

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

Сообщений: 1442

Qt 2.2, 3.3, 4.5, 4,7, 4.8, 5.3, 5.6, 5.9, 5.12


Просмотр профиля
« Ответ #14 : Декабрь 11, 2008, 12:47 »

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

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

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

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

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

2^7-1 == 127, задумайтесь...
Страниц: [1]   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.109 секунд. Запросов: 22.