визуальное портирование C ++ с MFC на сенсорный экран
Ищите среду графического интерфейса для использования с C ++ для «модернизации» существующего интерфейса для сенсорного экрана.
Я начинающий программист с опытом работы в C ++ / Java, которому только что был назначен проект, включающий использование существующей программы C ++ с использованием MFC (3 представления данных, несколько текстовых / радиоуправляемых диалоговых окон и т. Д.) И изменение интерфейса для «сенсорный экран дружественный» такие как большие кнопки управления, ползунки и еще много чего.
Мне дали довольно свободное правление с инструкциями, чтобы сделать «более современный интерфейс» в отличие от типичного MFC с голыми костями, которое мне дали. Я знаю, у меня есть немало уроков, поэтому любые предложения полезны.
Пока что я выбрал следующие варианты:
- MFC просто настройте существующие элементы управления, чтобы приспособить их к сенсорному вводу, оставьте дерьмовый интерфейс.
- Управляемый C ++ или C ++ / CLI выяснить, как сохранить базовую структуру C ++, имея возможность разрабатывать новый интерфейс с помощью WPF или Windows Forms.
- Qt совершенно новый для меня, но кажется многообещающей альтернативой.
На самом деле мне просто нужно найти способ, чтобы эта программа выглядела так, как будто она не была написана более 10 лет назад, и до сих пор, обучая себя MFC, она не кажется настолько гибкой с точки зрения включения какого-либо графического дизайна / темы.
Есть ли другие альтернативы, которые я должен рассмотреть? Есть ли в MFC нечто большее, чем кажется на первый взгляд, и мне просто нужно больше узнать об этом? Как я уже сказал, любые предложения о том, на что стоит обратить внимание, полезны.
Решение
То, что вы перечислили как № 1, может быть одним из двух подходов. Один из них (назовите его «1а») — это продолжать использовать ту же версию VC ++ и MFC, что и оригинал, и выполнять только необходимый минимум редактирования, чтобы увеличить размеры элементов управления там, где это необходимо. Если не считать некоторой довольно неудачной попытки написания существующего кода, это может вообще не потребовать какого-либо реального программирования и будет относительно быстрым и легким.
Вторым (назовите его 1b) будет обновление с использованием ток версия VC ++, MFC и т. д. Это может включать немного обновления кода, но, вероятно, ничего страшного (хотя, если это много Больше более 10 лет, могут потребоваться значительные обновления кода). С некоторой осторожностью вы можете немного обновить пользовательский интерфейс (например, перейти с меню на ленты, включить поддержку цветовой темы), но при этом довольно минимальные вложения.
Ваш # 2 может легко закончиться как почти полное переписывание. Несмотря на внешнее сходство, C ++ / CLI является полностью другой язык от C ++. Единственный способ, которым это действительно имеет смысл, — это если у вас есть немного кода, не относящегося к пользовательскому интерфейсу, который вы можете полностью оставить в покое, и использовать C ++ / CLI исключительно как «мост» между существующим C ++ и .NET UI (и пользовательский интерфейс довольно минимальный, поэтому довольно посредственная инструментальная поддержка C ++ / CLI не вызывает больших проблем). Если ваш пользовательский интерфейс более чем тривиален, C # имеет достаточно лучшую поддержку инструментов, поэтому он может быть лучшим выбором, чем C ++ / CLI.
Ваша # 3, вероятно, потребует лишь незначительно меньше переписывания, чем 2, по крайней мере, кода, который связан с пользовательским интерфейсом. Хотя код остается C ++, Qt довольно сильно отличается от MFC. Большим преимуществом было бы, если вы (возможно, скоро) захотите поддерживать что-то, кроме Windows (например, iOS или Android). Для переносимости Qt имеет огромный преимущество перед любой из названных вами альтернатив.
Многое возвращается к вопросу о том, сколько кода на C ++ вы можете сохранить без изменений. Если у вас много кода в «движке», который четко отделен от пользовательского интерфейса, и довольно простой пользовательский интерфейс, то сохранение существующего кода имеет большой смысл, и переписывание пользовательского интерфейса с нуля не так уж страшно проблемы. С другой стороны, если пользовательский интерфейс и код бизнес-логики сильно переплетены (довольно распространены), то, скорее всего, незначительные изменения в пользовательском интерфейсе также могут существенно переписать остальную часть кода.
Вывод: если пользовательский интерфейс сильно переплетен с другим кодом, ваш единственный реальный выбор — от 1a до 1b. Если пользовательский интерфейс легко отсоединить от другого кода, выбор между 2 и 3 (по крайней мере для меня) в первую очередь зависит от того, будет ли вообще иметь значение переносимость (сейчас или в ближайшее время).
Другие решения
Других решений пока нет …