Integración de Qt en aplicaciones MFC heredadas

Question

Actualmente mantenemos un conjunto de aplicaciones MFC que están bastante bien diseñadas, sin embargo, la interfaz de usuario está empezando a verse cansada y gran parte del código necesita bastante refactorización para solucionar algunos problemas de duplicación y/o rendimiento.Usamos bastantes controles personalizados que manejan todos sus propios dibujos (todos escritos usando MFC).

Recientemente he estado investigando más sobre Qt y los beneficios que proporciona (multiplataforma y admite lo que se podría llamar un marco de trabajo de apariencia más "profesional" para el desarrollo de UI).

Mi pregunta es - ¿Cuál sería el mejor enfoque para quizás pasar al marco Qt??¿Qt funciona bien con MFC?¿Sería mejor comenzar a migrar algunos de nuestros controles personalizados a Qt e integrarlos gradualmente más y más en nuestras aplicaciones MFC existentes?(¿es posible?).

Se agradece cualquier consejo o experiencia previa.

Answer 1

En mi empresa, actualmente utilizamos Qt y estamos muy contentos con él.

Personalmente, nunca tuve que mover una aplicación MFC para usar el marco Qt, pero aquí hay algo que podría ser de interés para usted:

Marco de migración Qt/MFC

Marco de migración Qt/MFC

Es parte de Qt-Solutions, por lo que significa que tendrá que comprar una licencia de Qt junto con una licencia de Qt-Solutions.(editar: ya no)

Espero que esto ayude !

Answer 2

(Esto realmente no responde a sus preguntas específicas, pero ...) No he usado personalmente QT, pero no es gratis para el desarrollo comercial de Windows.

¿Has mirado wxWindows cual es gratis?Buen articulo aquí.Aparte, si desea una base de código única para todas las plataformas, es posible que tenga que migrar fuera de MFC. Estoy bastante seguro (alguien lo corregirá si está equivocado) de que MFC solo está dirigido a Windows.

Otra opción sería mirar el Actualización del paquete de funciones a MFC en SP1 de VS2008: incluye acceso a nuevos controles, incluidos los controles de cinta estilo Office.

Answer 3

Es un problema complicado y sospecho que la respuesta depende de cuánto tiempo tengas.Obtendrá un resultado mucho mejor si traslada sus controles personalizados a Qt; si usa las clases QStyle para hacer el dibujo real, terminará con un código compatible con temas listo para usar.

En general, mi consejo sería hacer de tripas corazón y recorrer todo el camino de una vez.Claro, puede que lleve más tiempo, pero la alternativa es pasar un tiempo intentando depurar código que no funciona. bastante jugar a la pelota y terminar escribiendo más código para lidiar con incompatibilidades menores entre los dos sistemas (he estado allí, lo he hecho).

Entonces, para resumir, mi consejo es iniciar una rama y eliminar todo el código MFC antiguo y reemplazarlo con Qt.Obtendrá independencia de plataforma (casi) gratis y, aunque llevará un tiempo, al final obtendrá un producto mucho mejor.

Una última palabra de advertencia:asegúrese de tomarse el tiempo para comprender la "forma Qt de hacer las cosas" (en algunos casos puede ser bastante diferente al enfoque MFC). Lo último que desea hacer es terminar con un código Qt estilo MFC.

Answer 4

He dirigido un equipo que hace este tipo de cosas antes (no de MFC a QT, pero los principios deberían funcionar).

Primero documentamos los diálogos y cuáles eran sus entradas, controles y salidas.Además, creamos varios casos de prueba especialmente para cualquier lógica inteligente dentro de la GUI.

A veces tuvimos que refactorizar alguna lógica de negocios para proporcionar una interfaz limpia para las GUI, pero esta es la forma en que debería haberse hecho en primer lugar.

Ahora teníamos una lista de GUI, entradas, salidas, pruebas y una interfaz que la GUI encapsulada tenía que coincidir.

Comenzamos, proyecto por proyecto, a crear GUI equivalentes a las antiguas.Una vez que hicimos eso, pudimos colocar la GUI en el lugar donde estaba la anterior, reconstruirla y probarla.Al principio tropezábamos mucho pero pronto solucionamos los errores comunes y los solucionamos.Navegamos (creo) por 612 cuadros de diálogo, aunque había un equipo de aproximadamente una docena de personas trabajando en ello.