Посоветуйте пожалуйста, использовать API или все же MFC.

Аппликация должна управлять удаленным компьютером, работающим под другой осью. Типа терминала, т.е. принимать/посылать и обрабатывать сообщения от удаленного компьютера. Прога будет активно использовать COM-порты, LAN и USB. В тоже время должен быть максимально дружелюбный пользовательский интерфейс, включая меню на нескольких языках.
Так вот не знаю, на чем остановить свой выбор. API или MFC?

????????????, bel_nikita, ?? ??????:
A kakaia OS??? Esli Lunix — Poprobui 4o-nibud tipa QT ot Trolltech.

_>??????????? ??????????, ???????????? API ??? ??? ?? MFC.

_>?????????? ?????? ????????? ????????? ???????????, ?????????? ??? ?????? ????. ???? ?????????, ?.?. ?????????/???????? ? ???????????? ????????? ?? ?????????? ??????????. ????? ????? ??????? ???????????? COM-?????, LAN ? USB. ? ???? ????? ?????? ???? ??????????? ??????????? ???????????????? ?????????, ??????? ???? ?? ?????????? ??????.
_>??? ??? ?? ????, ?? ??? ?????????? ???? ?????. API ??? MFC?

Здравствуйте, BOuOB, Вы писали:

BOO>A kakaia OS??? Esli Lunix — Poprobui 4o-nibud tipa QT ot Trolltech.

А как ты думаешь, если человек собирается использовать MFC, то на какой оси он работает?

Здравствуйте, BOuOB, Вы писали:

BOO>????????????, bel_nikita, ?? ??????:
BOO>A kakaia OS??? Esli Lunix — Poprobui 4o-nibud tipa QT ot Trolltech.

Сама аппликация под Виндовозом
А удаленный комп — там пофиг какая ось. Обмен будет по COM и LAN.

Здравствуйте, bel_nikita, Вы писали:

_>Посоветуйте пожалуйста, использовать API или все же MFC.

_>Аппликация должна управлять удаленным компьютером, работающим под другой осью. Типа терминала, т.е. принимать/посылать и обрабатывать сообщения от удаленного компьютера. Прога будет активно использовать COM-порты, LAN и USB. В тоже время должен быть максимально дружелюбный пользовательский интерфейс, включая меню на нескольких языках.
_>Так вот не знаю, на чем остановить свой выбор. API или MFC?

У меня к тебе несколько вопросов:
1. Большой ли у тебя опыт использования MFC?
2. Большой ли у тебя опыт написания программ на чистом Win32 API?
3. Почему у тебя появились сомнения в целесообразности использования MFC?
4. Какие плюсы и минусы ты ждёшь от написания программы на чистом API?
5. Какие плюсы и минусы ты ждёшь от написания программы на MFC?
6. Ставятся ли какие то жёсткие условия на размер исполнимого модуля твоей программы?
7. Это коммерческое приложение с ограниченными сроками?

Здравствуйте, korzhik, Вы писали:

K>У меня к тебе несколько вопросов:
K>1. Большой ли у тебя опыт использования MFC?
K>2. Большой ли у тебя опыт написания программ на чистом Win32 API?
K>3. Почему у тебя появились сомнения в целесообразности использования MFC?
K>4. Какие плюсы и минусы ты ждёшь от написания программы на чистом API?
K>5. Какие плюсы и минусы ты ждёшь от написания программы на MFC?
Вся проблема в том, что у меня нет более-менее солидного опыта написания приложений под винду. Занимаюсь более низкоуровневым программированием. И не под Виндовс. Поэтому многое уже забыл ( Имею ввиду Виндовс).
И использование API для меня более понятно нежели MFC. Но с другой стороны используя MFC создавать апликации проще.
Если бы стояла задача создать пользовательскую программу(интерфейс), то конечно же выбрал MFC.
Но в моем случае придется активно использовать переферию ПК. Скорее всего спускаться на уровень ядра(драйвера корректировать и т.п.)
И вот, не знаю, как это будет сочетаться с MFC.
Скажу так, для меня проще и понятнее работать с железом, нежели с пользователем

K>6. Ставятся ли какие то жёсткие условия на размер исполнимого модуля твоей программы?
Нет. Жестких условий нет. Сам себе хозяин.

K>7. Это коммерческое приложение с ограниченными сроками?
Нет. Это приложение внутреннего назначения. Т.е. оно будет использоваться в внутренних целях фирмы. На заводе и объектах.

Здравствуйте, bel_nikita, Вы писали:

_>Вся проблема в том, что у меня нет более-менее солидного опыта написания приложений под винду. Занимаюсь более низкоуровневым программированием. И не под Виндовс. Поэтому многое уже забыл ( Имею ввиду Виндовс).
_>И использование API для меня более понятно нежели MFC. Но с другой стороны используя MFC создавать апликации проще.
_>Если бы стояла задача создать пользовательскую программу(интерфейс), то конечно же выбрал MFC.
_>Но в моем случае придется активно использовать переферию ПК. Скорее всего спускаться на уровень ядра(драйвера корректировать и т.п.)
_>И вот, не знаю, как это будет сочетаться с MFC.
_>Скажу так, для меня проще и понятнее работать с железом, нежели с пользователем

ну раз ты многое забыл (GUI Windows), то тебе, я думаю. сложновато будет делать интерфейс на чистом API, очень много нюансов.
Пиши на MFC.
Ну и если душа требует полёта посмотри на библиотеку WTL
здесь статьи для начинающих по этой библиотеке.

Здравствуйте, bel_nikita, Вы писали:

_>Так вот не знаю, на чем остановить свой выбор. API или MFC?

Посмотрите для начала в сторону WTL.

Здравствуйте, korzhik, Вы писали:



K>ну раз ты многое забыл (GUI Windows), то тебе, я думаю. сложновато будет делать интерфейс на чистом API, очень много нюансов.
K>Пиши на MFC.
K>Ну и если душа требует полёта посмотри на библиотеку WTL
K>здесь статьи для начинающих по этой библиотеке.

В где саму либу можно взять ? Кстати — а почем бы тогда не посоветовать wxWindows или FoxToolKit ?

Здравствуйте, Аноним, Вы писали:

А>В где саму либу можно взять ?
WTL

>Кстати — а почем бы тогда не посоветовать wxWindows или FoxToolKit ?
а я не пользовался поэтому и не могу советовать

????????????, korzhik, ?? ??????:
Da ladno, nu tormozhu ia segodnia.
Ia bi pisal na MFC, menshe gemoroia v lubom slu4ae (+-GUI).
K>????????????, BOuOB, ?? ??????:

BOO>>A kakaia OS??? Esli Lunix — Poprobui 4o-nibud tipa QT ot Trolltech.

K>? ??? ?? ???????, ???? ??????? ?????????? ???????????? MFC, ?? ?? ????? ??? ?? ?????????

Здравствуйте, bel_nikita, Вы писали:

_>Вся проблема в том, что у меня нет более-менее солидного опыта написания приложений под винду. Занимаюсь более низкоуровневым программированием.
Мне кажется, тебе больше подойдет Win API, а не MFC. Запаришся ты разбираться в MFC с работой потоков, объектами синхронизации и т.п. Imho, MFC полезен там, где нужно сваять интерфейс типа "документ-представление". А тебе, как я понял, скорей всего нужна прозрачность работы с Win API, а представление данных вторично. Кроме того, ты можешь написать на Win API основной модуль, а интерфейсную часть — на MFC.

Все вышесказанное, это если бы твою задачу выполнял я. У тебя могут быть другие резоны.

Здравствуйте, bel_nikita, Вы писали:

Ну раз уж мы в форуме "проектирование"...

_>Вся проблема в том, что у меня нет более-менее солидного опыта написания приложений под винду. Занимаюсь более низкоуровневым программированием. И не под Виндовс. Поэтому многое уже забыл ( Имею ввиду Виндовс).
_>И использование API для меня более понятно нежели MFC. Но с другой стороны используя MFC создавать апликации проще.
_>Если бы стояла задача создать пользовательскую программу(интерфейс), то конечно же выбрал MFC.
_>Но в моем случае придется активно использовать переферию ПК. Скорее всего спускаться на уровень ядра(драйвера корректировать и т.п.)
_>И вот, не знаю, как это будет сочетаться с MFC.

Ну, скажем так. MFC сама по себе лежит на Win API и ничего экстраординарного не привносит. Так себе, довольно тонкая ОО-оболочка над API. Разве что реализация модели Document-View-Controller более или менее "нечто новое" по отношению к Win API. Заморочки с потоками на самом деле не критичны, и в смысле организации приложения, т.е. — проектирования, прекрасно разрешаются через PostMessage/GetMessage. Если, разумеется, не лень написать правильные обёртки под такие обмены данными. Так что, с этим не парься. Другое дело, что MFC — довольно-таки кондовая вещица, и сложные интерфейсы на ней неприятно делать.

_>Скажу так, для меня проще и понятнее работать с железом, нежели с пользователем
Век живи...

K>>7. Это коммерческое приложение с ограниченными сроками?
_>Нет. Это приложение внутреннего назначения. Т.е. оно будет использоваться в внутренних целях фирмы. На заводе и объектах.

ИМХО, с MFC будет по-любому удобнее, чем на чистом Win API. Всё зависит только от пожеланий к организации интерфейса. Я имею ввиду не количество контролов на формочке, разумеется, а например, нужно ли будет наворачивать PropertySheets многоуровневые, будут ли какие-то нестандартные комбинации контролов и т.д., и т.п. Но и тут вобщем-то, MFC поможет до некоторой степени.

Не хочу тебя отговаривать от разработки интерфейса на чистом Win API, но ИМХО, это означает одно из двух: либо предполагаемый интерфейс очень прост в смысле организации (а тогда MFC вполне сгодится), либо ты вполне готов написать собственную либу для поддержки разработки интерфейса. Во втором случае нужно очень крепко подумать — а стоит ли?

Ну а теперь о главном. О проектировании — то бишь. В твоём случае я бы накрыл взаимодействие с периферией и прочими подобными вещами группой классов. Эти классы пусть взаимодействуют с периферией наиудобнейшим и наинадёжнейшим образом, а для отображения информации либо кидаются сообщениями через PostMessage или SendMessage (PostMessage может оказаться не слишком надёжным, а SendMessage создаёт повышенный риск зависаний если протокол обмена плохо продуман). Другой вариант — сложить сообщения в очередь, а UI пусть их периодически считывает. Управляющие сообщения от пользователя можно передавать, например, во внутренние очереди этих классов. Название паттерна не подскажу, но суть примерно такова:

class DeviceManager
{
    MessageQueue m_queueCommands;
        MessageQueue m_queueUrgentCommands;
    public:
      void PutCommand(const Command &cmd)
        {
          // Здесь вставить синхронизацию.
            if (DetectPriority(cmd) == Highest)
              m_queueUrgentCommand.AddCommand(cmd)
          else
              m_queueCommand.AddCommand(cmd);
        }
        
    // Этот метод лучше всего поместить именно в этот класс,
        // а объект Command должен нести достатчно информации для его классификации.
        CommandPriority DetectPriority(const Command &cmd)
        {
          // Здесь нужно облазить содержимое команды и вычислить её приоритет.
        }
};

Для возврата сообщений (вероятно — индикации?) почти то же самое, только диспетчеризация уже будет зависеть от объекта, который содержит "ответное" сообщение. Ну и, вероятно, очереди ответных сообщений будут считываться отдельным потоком, который будет диспетчить их по нужным окнам и делать правильные PostMessage.

Т.е., основная задача — правильно разработать интерфейс "UI <-> управление устройствами". Термин "правильно" означает: так, чтобы на уровне интерфейса был определён протокол взаимодействия с интерфейсом пользователя. По моему опыту после такого проектирования вопрос об использовании MFC/WTL/ATL/Win API и т.п. для интерфейса отпадает сам собой, поскольку вырождается в: "Да какая, к чёрту, разница? Хоть на консоль пуляй!" Руки-то уже развязаны! Выбираешь один-два способа передачи сообщений и сосредотачиваешься на структуре набора сообщений и надёжности управления устройством. ИМХО — это основное. Потом, если будет желание/настроение/время сможешь и поменять библиотеку UI.

Ну вот так. Или примерно так.