La integración de Qt en aplicaciones MFC de legado

Question

Actualmente mantenemos un conjunto de aplicaciones de MFC que están bastante bien diseñado, sin embargo, la interfaz de usuario está comenzando a verse desgastado y una gran parte del código está en la necesidad un poco de refactorización para poner en orden algunos problemas de duplicación y/o rendimiento Hacemos uso de bastantes controles personalizados que manejan su propio dibujo (todo escrito usando MFC).

Recientemente he estado haciendo más investigación sobre Qt y los beneficios que proporciona (multiplataforma y compatible con lo que podríamos llamar un marco más "profesional" en busca de desarrollo de interfaz de usuario).

Mi pregunta es - ¿cuál sería el mejor enfoque para tal vez mudarme a la Qt framework? Qt juega bien con MFC? ¿Sería mejor comenzar a portar algunos de nuestros controles personalizados a Qt e integrar gradualmente más y más en nuestras aplicaciones MFC existentes? (¿es posible?).

Se agradece cualquier consejo o experiencia previa.

Answer 1

En mi compañía, actualmente estamos usando Qt y estamos muy contentos con él.

Yo personalmente no tenía que mover un MFC-aplicación en el uso del marco de Qt, pero aquí hay algo que puede ser de interés para usted:

Qt/MFC Migration Framework

Qt/MFC Migration Framework

¡Es parte de Qt-Solutions, entonces esto significa que tendrá que comprar una licencia de Qt junto con una licencia de Qt-Solutions. (Editar: not any more)

Espero que esto ayude!

Answer 2

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

¿Has mirado en wxWindows que es gratuito? Buen artículo here. Solo como un lado, si quería una única base de código para todas las plataformas, entonces es posible que tenga que migrar lejos de MFC; estoy bastante seguro (alguien corregirá si está equivocado) de que MFC solo apunta a Windows.

Otra opción sería mirar Feature Pack update a MFC en SP1 de VS2008 - incluye acceso a controles nuevos, incluidos los controles de cinta de estilo de Office.

Answer 3

Es un problema espinoso, y sospecho que la respuesta depende de cuánto tiempo tenga. Obtendrás un resultado mucho mejor si transfieres tus controles personalizados a Qt: si usas las clases QStyle para hacer el dibujo real, terminarás con un código capaz de reproducir temas de inmediato.

En general, mi consejo sería hacer de tripas corazón e ir todo el camino a la vez. Claro, podría tomar más tiempo, pero la alternativa es pasar una edad tratando de depurar el código que no bastante jugar pelota, y terminar escribiendo más código para tratar con incompatibilidades menores entre los dos sistemas (estado allí, hecho eso)

tanto, para resumir, mi consejo es empezar una rama y arrancar todo el código MFC viejo y reemplazarlo con Qt. Obtendrá la independencia de la plataforma (casi) de forma gratuita, y aunque le tomará un tiempo, obtendrá un producto mucho más agradable al final.

Una última palabra de advertencia: asegúrese de tomarse el tiempo para entender 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 el código Qt estilo MFC.

Answer 4

He liderado 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 fueron sus entradas, controles y resultados. Además, creamos varios casos de prueba especialmente para cualquier lógica inteligente dentro de la GUI.

A veces tuvimos que refactorizar algunas lógicas comerciales para proporcionar una interfaz limpia a las GUI, pero esta es la forma en que debería haberse hecho en primer lugar tbh.

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, para crear GUI equivalentes a las antiguas. Una vez que hicimos eso, pudimos colocar la GUI en el lugar donde estaba el antiguo, reconstruirlo y probarlo. Al principio tropezamos mucho pero pronto resolvimos los errores comunes y los solucionamos. Navegamos (creo) 612 diálogos, aunque había un equipo de alrededor de una docena de nosotros trabajando en él.