Нужен совет по выбору инструмента

[DGrees]

Итак, расскажу свою историю по порядку.
Учился я на энергетика, увлекаюсь электроникой. И захотелось мне очень-очень изучить микроконтроллеры и всю работу с ними. Ну а ессно просто так это не сделаешь, нужна конкретная задача. И на свою голову я решил в качестве дипломного проекта сделать стенд, имитирующий подстанцию, управляемую автоматизированной системой диспетчерского управления.
Взялся за гуж, не говори что не дюж. Но до этого не думал, что все так сложно будет.
Сделал целиком стенд (1м на 1.3м, состоит из порядка 1000 деталей, которые я же и моделировал в САПР), сделал печатные платы, которые этим всем будут заведовать (напаять пришлось около 1000 элементов вручную), освоился с ассемблером (все в контексте использования ATMega644), написал примерно для контроллера прогу на Си в IARe, тоже соответсвенно не очень простая получилась.
Диплом то защитил, красный, но вот хвосты остались. Надо сделать программу для компьютера.
До этого делал простенькие программы в С++ Билдере, Делфи. А тут попались под руку исходники (проект микропроцессорной системы зажигания SECU-3 на базе ATMega64),  которые предназначены для тех же целей, что мне и нужны:
1. Умеют прошивать МК (общаться с бутлоадером МК и скармливать ему прошивку без программатора через виртуальный ком-порт)
2. умеют влиять на параметры работы управляющей программы МК, передавать МК какие-либо команды
3. принимают от МК текущее состояние подключенной периферии
4. имеет сносный графический интерфейс.
Эти исходники написаны на Visual С++.
Ну, думал я, щас скачаю студию, разберусь, и сделаю свою прогу. А не тут то было, ессно. Вроде синтаксис знакомый, букафки знакомые, а в целом нифига не понятно. Концепция вообще не такая как в билдере ( ну то есть есть форма, на которую складываешь элементы и задаешь им функции). Тут целиком главного окна я не нашел, только разрозненно, и диалоговые окна в ресурсах. Подошел в институт на кафедру программирования к преподавателям, которые типа знают Visual C++. Они понять не смогли каким образом вообще написан код, где там функция main или Tmain, почесали репу и дали мне пару книжек по С++, мол разбирайся сам. Ну конечно кое-что полезное поведали - что можно приложение, нужное мне, написать тремя способами: WinAPI, MFC или Windows Forms. Еще я так понял, что мало мне смысла ковырять те исходники... Проще наверное с нуля сделать.
Поэтому прошу совета - на чем мне начинать делать эту программу, и хотя бы примерно в какой последовательности? Функции программы описаны выше. С радостью отвечу на все уточняющие вопросы.

[Dimka]

DGrees, если исходники для Visual C++, то важно, какой версии? Ещё важно, что эти исходники дают в результате сборки - приложение или библиотеку? Ну и третье важное, как ты этими исходниками собирался воспользоваться: подключить библиотеку к своей программе, или написать программу, копируя нужные тебе куски из имеющихся исходников?

WinAPI, MFC - это C++, Windows Forms - это .NET (хотя по концепции это будет наиболее близким к на C++ Builder).

Если Visual C++ 6.0 и более ранние версии, то .NET не поддерживается.

К твоему сожалению ничто тебя не избавит от необходимости изучить концепцию графического пользовательского интерфейса. В частности, концепцию событийно-управляемого приложения, чтобы не возникал вопрос, где там main - он скрыт вместе со всеми вспомогательными вещами, обеспечивающими главный цикл приёма и диспетчиризации сообщений о событиях, и программисту в подавляющем большинстве случаев с ним делать нечего. Однако если есть желание разобраться с этим досконально, можно написать вручную при помощи WinAPI всё, что мастера и макросы MFC, а также среды C++ Builder и разработки .NET приложений скрывают от разработчика. Однако это трудоёмко, хотя разница поменьше, чем между кодом на языках ассемблера и C.

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

На чём начинать делать "эту программу" - не знаю, потому что у тебя совсем никак не описана "эта программа". Ты сказал, что у тебя есть какие-то исходники, в которых код умеет делать 4 вещи. Но ты совершенно не сказал, зачем они тебе, какую задачу ты с их помощью собрался решать, и, следовательно, каковы требования к будущей программе. Короче говоря, нужна концепция программы с полным перечнем задач, которые с помощью этой программы должен решать пользователь, и подходов к организации человеко-машинного взаимодействия для решения этих задач (вплоть до макетов экранов пользовательского интерфейса, чтобы прикинуть сложность "сносного графического интерфейса").

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

Т.е. пока твой вопрос, если перевести его на язык железячников, звучит на уровне: "У меня есть три коробочки с какими-то элементами: красненькими, синенькими и чёрненькими. С каких мне начать паять мою схему?" Без постановки задачи, проекта и спецификаций на элементную базу о каком паянии может идти речь? А по хорошему ещё и такая важная вещь есть, как соответствующее контрольно-измерительная аппаратура и методы проверки. В программировании такое тоже есть - тестирование программ (проверка результата на соответствие спецификациям) и валидация (проверка результата на соответствие постановке задачи).

[RXL]

DGrees, соглашусь, что на BCB писать интерфейс проще и удобнее. Кстати, ничто не мешает именно так и сделать, а не-GUI часть программы с большой вероятностью можно портировать из VC в BCB.

[Алексей++]

А так ли будет сильно наворочен интерфейс ?
Если да, я бы сделал на Qt4. Интерфейс там делать  - раз плюнуть, с компортами библиотека работать умеет. К тому же - кроссплатформа, что очень пригодится, если нужно будет запускать программу с каких-нибудь девайсов, где крутится какой-нибудь линукс

Но в исходниках нужно будет отделить GUI от логики, чтобы переход был безболезненным.

[DGrees]

DGrees, если исходники для Visual C++, то важно, какой версии? Ещё важно, что эти исходники дают в результате сборки - приложение или библиотеку? Ну и третье важное, как ты этими исходниками собирался воспользоваться: подключить библиотеку к своей программе, или написать программу, копируя нужные тебе куски из имеющихся исходников?

Насчет исходников, цитирую: Created using Microsoft Visual Studio 6.0 & Borlad C++ Builder 5.0. В 2010 Студии нормально не компилится,ошибки. Эти исходники в результате сборки дают законченное приложение для настройки и контроля блока управления системой зажигания автомобиля. Думал копировать нужные куски из имеющихся исходников. Но тут возможно проще будет написать с нуля и использовать какие-либо распространенные библиотеки и т.д. Этот момент я тоже не знаю.

WinAPI, MFC - это C++, Windows Forms - это .NET (хотя по концепции это будет наиболее близким к на C++ Builder).

Если Visual C++ 6.0 и более ранние версии, то .NET не поддерживается.

Ого как оно. У меня никогда не было учебных предметов, связанных с программированием, поэтому у меня сейчас нету ак сказать общего представления о системах программирования.

К твоему сожалению ничто тебя не избавит от необходимости изучить концепцию графического пользовательского интерфейса. В частности, концепцию событийно-управляемого приложения, чтобы не возникал вопрос, где там main - он скрыт вместе со всеми вспомогательными вещами, обеспечивающими главный цикл приёма и диспетчиризации сообщений о событиях, и программисту в подавляющем большинстве случаев с ним делать нечего. Однако если есть желание разобраться с этим досконально, можно написать вручную при помощи WinAPI всё, что мастера и макросы MFC, а также среды C++ Builder и разработки .NET приложений скрывают от разработчика. Однако это трудоёмко, хотя разница поменьше, чем между кодом на языках ассемблера и C.

Ну мне без графического интерфейса вообще никуда. Ну и событийно-управляемый интерфейс я уже видел в билдере, но тогда я о всяких майнах не задумывался. Пока нет задачи разобраться прям уж досконально, сейчас надо написать приложение _{и отдохнуть наконец-то,а то месяц уже без нормального сна}.

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

Ну да, я это и хочу, просто не понятно что ж выбрать то)

На чём начинать делать "эту программу" - не знаю, потому что у тебя совсем никак не описана "эта программа". Ты сказал, что у тебя есть какие-то исходники, в которых код умеет делать 4 вещи. Но ты совершенно не сказал, зачем они тебе, какую задачу ты с их помощью собрался решать, и, следовательно, каковы требования к будущей программе. Короче говоря, нужна концепция программы с полным перечнем задач, которые с помощью этой программы должен решать пользователь, и подходов к организации человеко-машинного взаимодействия для решения этих задач (вплоть до макетов экранов пользовательского интерфейса, чтобы прикинуть сложность "сносного графического интерфейса").

Итак. Как я уже описал, разрабатывается система управления подстанцией. То есть программа будет мнемосхемой подстанции:

(click to show)

На этот рисунок рядом с каждым коммуникационным аппаратом будут добавлены кнопки с иконками "отключить" и "включить". Сами коммуникационные аппараты - не статические картинки, а у каждого два варианта - либо замкнут либо разомкнут. Также у линий будут лампочки-индикаторы - есть напряжение на них или нет.
То есть программа должна принимать состояние коммутационных аппаратов от МК и уметь давать МК команды, чтобы тот включал определенны активаторы.
Также программа должна уметь перепрошивать МК для обновления прошивки без программатора. Для этого я думаю сделать кнопку (меню наверное только ради этой функции пока не целесообразно делать), которая вызывает окно, в котором прошивку можно считать, можно записать другую. Еще будет кнопка для настройки параметров соединения с МК - то есть выбор порта, скорость. Всякие биты данных, чет-нечет и прочее надо жестко определить в соответствии с интерфейсом МК.

Добавлено через 28 минут и 21 секунду:
А сообщения изменять можно? У меня медленный инет (через мобильник, еще и без 3G), поэтому сначала отправил само сообщение, в потом хотел добавить картинку. На SMF платформе обычно такое можно, а тут кнопочку изменить не нашел....
--
кнопка изменить появилась после нескольких сообщений

[Джон]

Подошел в институт на кафедру программирования к преподавателям, которые типа знают Visual C++. Они понять не смогли каким образом вообще написан код, где там функция main или Tmain, почесали репу и дали мне пару книжек по С++, мол разбирайся сам.

Хммм... заставляет задуматься. В MFC-проекте действительно нет main, но её нет и в DLL сборках.

В силу

Created using Microsoft Visual Studio 6.0 & Borlad C++ Builder 5.0.

осмелюсь предположить, что скорей всего UI сделан в Борланде, а VC++ библиотеки работы с железом, причём скорей всего на уровне WinAPI.

Если это было сделано ещё в шестёрке, то никакого .NET там нет, поэтому про него можно просто забыть.
В 2010 Студии проект шестёрки и не скомпилится нормально. Слишком уж много времени прошло между ними, да и "винды" поменялись. Требуется подгонка и, если не забывать, что программа это не код и язык, а всё-таки логика, алгоритм, то заставить работать можно и под 2010.

А можно взглянуть на список файлов проекта? Мне кажется, что их можно использовать. В крайнем случае, как первый шаг, можно скомпилить и в шестёрке.

[DGrees]

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

А можно взглянуть на список файлов проекта? Мне кажется, что их можно использовать. В крайнем случае, как первый шаг, можно скомпилить и в шестёрке.

Мне в принципе именно логика и алгоритм нужны. Синтаксис подредактировать не такая уж проблема, тут особо думать не надо.
Список файлов - без проблем: https://github.com/ashabelnikov/secu3man  Но там проект офигенного масштаба, я поэтому подумал про то, чтобы свой проект сделать с нуля, а фрагменты исходника вставлять уже в свой.
Как уже говорил, это проект микропроцессорной системы зажигания (secu-3.org). Этот проект успешно внедрен и работает на моем авто. Так что по сути это вещь вполне рабочая

[Dimka]

Чисто организационно я бы предложил такую схему реализовать в виде векторной карты, состоящей из типовых векторных же элементов (собственно, как почти всякая CAD и делает). Но, естественно, что функциями CAD для отображения схемы воспользоваться не получится, поэтому схему либо придётся рисовать самому (писать код, обеспечивающий отрисовку каждого типа элемента), либо использовать какую-то графическую библиотеку, умеющую это делать (я лично такую на вскидку не назову - не приходилось сталкиваться о схемами). Векторное представление позволит масштабировать изображение в зависимости от размера окна (и/или экрана монитора) у пользователя.

Это же решение позволит несколько усовершенствовать интерфейс, отказавшись от "типовых" и не очень подходящих в данном случае кнопок. Если каждый элемент схемы будет отдельным объектом, у него могут быть разные способы отображения в зависимости от режима работы. Поэтому линии под напряжением можно изображать просто другим цветом (например, более ярким). А замыкание и размыкание ключей делать по клику на сами изображения ключей. Для демонстрации того, что ключи "кликабельны", используют такой эффект, что при наведении мыши изображение немного меняется (например, цвет фона) и показывает пользователю, что данный элемент активный - т.е. это не просто рисунок, а с ним ещё что-то можно сделать.

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


Собственно управляющие функции, выходит, полностью или частично реализованы в имеющихся исходниках. Они не связаны с графическим интерфейоом (хотя в неаккуратных исходниках могут быть связаны сильно). Их нужно оттуда выудить и перенести в свой новый проект. Если там не будет графического интерфейса, то портирование из Visual C++ в C++ Builder не должно быть сильно трудозатратным. Но какие-то базовые вещи (типа динамических массивов, строк и т.п.) придётся поменять на аналоги. В целом, если среда C++ Builder более освоена и понятна, я бы советовал реализовывать проект в ней. Но окончательный выбор зависит от решения: найти и использовать чужую библиотеку для отрисовки схемы или написать реализацию самостоятельно. Так как чужая библиотека может быть связана с какими-то другими базовыми библиотеками, различающимися в Visual C++ и C++ Builder, или требовать использование Qt, GTK+, Tk и т.п. графических библиотек.

Если удастся хорошо выделить все нужные функции из имеющихся исходников и создать собственную библиотеку со внятной системой операций и данных, то её можно реализовать как lib или DLL, а графический интерфейс в таком случае можно реализовывать практически на чём угодно, что покажется более простым и удобным, поскольку обращение к экспортируемым из DLL функциям и данным поддерживается очень многими средами. Этот вариант стоит рассматривать только в том случае, если по субъективному ощущению знания C++ Builder настолько плохие, что можно сказать, безразлично, какую среду разработки осваивать.

[DGrees]

Чисто организационно я бы предложил такую схему реализовать в виде векторной карты, состоящей из типовых векторных же элементов .... Векторное представление позволит масштабировать изображение в зависимости от размера окна (и/или экрана монитора) у пользователя.

Это же решение позволит несколько усовершенствовать интерфейс, отказавшись от "типовых" и не очень подходящих в данном случае кнопок. ...

Это вообще предел моих мечтаний   Но я думал что это наверное совсем жутко сложно, поэтому и не предлагал такой вариант.
Вышеизображенная схема делалась в автокаде, так что извлечение координат никакого труда не составит.
Про кнопки тоже согласен, и про цвета линии тоже. Было бы шикарно. Программу я сейчас пишу для монитора 1680х1050, а использоваться наверное будет на 1024х768.
Кстати в исходном проекте бегающие стрелки на циферблатах, как мне показалось, именно рисуются.

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

Абсолютно согласен.

Насчет функций, библиотек, портирования в билдер.
Насколько я понял, студия считается более серьезным продуктом для написания программ, поэтому есть большой интерес освоить ее.
Познания в билдере - где-то лет в 12  (сейчас мне 21) изучил книгу "занимательно программирование С++" авторов Симонович и Евсеев, издательства АСТ-Пресс, 2001 год. Написал все программы этого учебного курса. После этого иногда использовал билдер для написания несложных вспомогательных программок, типа авторана для дисков и прочей фигни.
Исследование нового мне интересно, поэтому еще хотел изучить Студию.
А насчет ДЛЛ страшновато, ибо вот с ними вообще никогда не работал. В смысле не создавал никогда. Но если надо - значит изучу. Мне бы только направление указать и учебный курс

[Вад]

Чисто организационно я бы предложил такую схему реализовать в виде векторной карты, состоящей из типовых векторных же элементов (собственно, как почти всякая CAD и делает). Но, естественно, что функциями CAD для отображения схемы воспользоваться не получится, поэтому схему либо придётся рисовать самому (писать код, обеспечивающий отрисовку каждого типа элемента), либо использовать какую-то графическую библиотеку, умеющую это делать (я лично такую на вскидку не назову - не приходилось сталкиваться о схемами). Векторное представление позволит масштабировать изображение в зависимости от размера окна (и/или экрана монитора) у пользователя.

Зачем так сложно? Отрисовать целиком всю картинку, а поверх неё - показывать изменяемые элементы в нужных позициях. По сути, есть несколько меняющийся view, рендерящийся из одной большой картинки и накладываемых поверх нескольких маленьких на основании текущего состояния модели.

[Dimka]

DGrees, если изучать Visual Studio, то явно не 6.0. Поэтому нужно будет делать портирование из 6.0 в, например, 2010.

Вад, мне не кажется более простым показывать изменяемые объекты в нужных позициях поверх отрисованной схемы, ибо такими объектами является большая часть схемы (ключи и линии).

[DGrees]

DGrees, если изучать Visual Studio, то явно не 6.0. Поэтому нужно будет делать портирование из 6.0 в, например, 2010.

Ну да, я собсно поэтому 2010 студию и поставил.
Ну дык это, какой проект делать? MFC? Какой учебный курс посоветуете? Где взять информацию/библиотеки/классы для работы с графикой, ком-портом?

[Dimka]

DGrees, проект для чего?

Visual Studio оперирует понятием solution, внутри которого имеются projects. Каждый project - это единица сборки (exe, dll или lib).

Я бы на твоём месте:
1) Создал пустой solution. (New Project/Other Project Types/Visual Studio Solutions/Black Solution.
2) контейнер для имеющихся у тебя исходников
2.1) Внутри solution создал Visual C++/Win32 Project, в свойствах проекта указал бы тип Dynamic Linked Library
2.2) Добавил бы в проект файл main.cpp, где описал бы функцию DllMain (см. в MSDN, как и с какими параметрами она пишется).
2.3) Собрал solution и убедился, что всё хорошо собралось.
3) тестовое приложение
3.1) Внутри solution создал ещё один проект Visual C++/Win32 Project, в свойствах проекта указал бы тип Executable
3.2) В Dependences этого проекта указал, что он зависит от предыдущего проекта.
3.3) Добавил бы в проект файл main.cpp, где описал бы обычную функцию main.
3.4) Собрал бы solution и убедился, что всё хорошо собралось.

Это рабочий каркас. Дальше из имеющихся у тебя исходников перетаскивал бы в первый проект нужные части, разбираясь, что там к чему, что в каком порядке откуда вызывается. Нужные функции/классы/глобальные переменные помечал бы с помощью _declspec(dllexport), указывающей, что эти функции будут экспортированы из DLL (доступны в других программах - в частности, в тестовой). А в тестовой программе писал бы вызовы этих функций, работу с классами и глобальными переменными - писал бы модели сценариев действий пользователя. В тестовой программе всё экспортируемые DLL элементы должны импортироваться с помощью _declspec(dllimport) (см. MSDN с примерами использования).

Отработав в тестовой программе сценарии действий пользователя и определив тем самым круг экспортируемых из DLL функций, классов и глобальных переменных, приступил бы к разработке собственно приложения с графическим пользовательским интерфейсом. Для этого выбрал бы язык C# и какой-нибудь тип приложения - тебе наиболее понятным и близким будет Windows Applications (хотя этот тип проектов устаревший, другие типы, например WPF, концептуально значительно отличаются и могут быть сложны для понимания, хотя в VS 2010 попытались максимально упростить описание форм). В C# можно также импортировать функции и прочее из DLL.


Это план вкратце. Естественно, здесь масса ньюансов, с которыми ты столкнёшься.


Что касается литературы, я лично посоветовать ничего не могу. Ибо уже даже не помню, когда в руках держал книжку, хоть как-то касающуюся Visual Studio. Могу лишь сказать, что официальным, почти исчерпывающе полным справочником по всем языкам и технологиям Microsoft является MSDN (либо сайт msdn.microsoft.com, либо вместе с Visual Studio ставится оболочка, которая в том числе отрабатывает нажатие F1 в Visual Studio и обеспечивает контекстно-зависимую помощь).


Также советую в свой проект не перетаскивать всё подряд из имеющихся исходников, а разбираться, что именно нужно для дела. И ни в коем случае не экспортировать из DLL всё подряд - стараться минимизировать количество экспортируемых элементов.

[DGrees]

Шикарно! Вот прям именно то, что я хотел... ээээ... прочитать
Спасибо за развернутый ответ!
Начинаю претворять твой алгоритм в жизнь
С# кстати знакомые хвалят, говорят классный очень)) Ну это вкратце, в подробностях пока еще не смыслю.

Круто, кнопочка "изменить" появилась)
Вопрос возник. А как звучит окончание пункта 2.1?
Я так понял в эту библиотеку мы соберем все функции, нужные для работы непосредственно "с железом".
Потом в тестовой программе отрабатываем вызывания функций из DLL.
Потом делаем приложение на Сишарпе, которое уже "конечное". То есть в нем уже делаем полноценный GUI, который будет взаимодействовать с функциями из DLL.

Таким образом, как я понял, библиотеку мы создаем для того, чтобы не делать огроменный проект с описанием всех функций, а так сказать "отделить мух от котлет". И плюс получается, что длл-ка может быть написана на языке исходника, то есть VC++, а сама программа будет написана на более удобном Сишарпе. Так?

------
Нашел классный мануал на msdn, делаю по нему: http://msdn.microsoft.com/ru-ru/library/ms235636.aspx
------
По msdn программа hello World! на Win32 API (C++) занимает около 90 строк кода без учета комментов   

[Dimka]

Вопрос возник. А как звучит окончание пункта 2.1?

Опечатка - убрал. Дальше шёл текст, вынесенный в заголовок раздела 2.

Я так понял в эту библиотеку мы соберем все функции, нужные для работы непосредственно "с железом". Потом в тестовой программе отрабатываем вызывания функций из DLL. Потом делаем приложение на Сишарпе, которое уже "конечное". То есть в нем уже делаем полноценный GUI, который будет взаимодействовать с функциями из DLL.

Да.

Таким образом, как я понял, библиотеку мы создаем для того, чтобы не делать огроменный проект с описанием всех функций, а так сказать "отделить мух от котлет". И плюс получается, что длл-ка может быть написана на языке исходника, то есть VC++, а сама программа будет написана на более удобном Сишарпе. Так?

Совершенно верно. В принципе есть C++.NET и "мух от котлет" отделять необязательно, но для .NET основным языком является C#, и его синтаксис проще, чем у C++, кроме того, C++.NET отличается от C++ расширением синтаксиса, поэтому его использование для людей неопытных и начинающих по сути мешает им овладеть чистым C++, а перегруженность синтаксиса становится, наверно, одной из самых высоких среди языков программирования, и ещё масса ньюансов сочетания native и managed участков кода.

[DGrees]

Сижу, ковыряюсь.
Сделал солюшен с длл-кой, сделал приложение тест.
Для начала в длл-ке сделал простенькую функцию, которая принимает два аргумента и делает с ними математическую операцию, которая указана в методе вызова функции.
Потом сделал сначала консольное приложение, которое обращается к ДЛЛ, потом сделал уже оконное приложение.
Потом глянул в проект исходник, а там оказывается также и сделано - исполняемый файл подгружает нужную длл-ку с функциями  
Теперь я хотя бы разобрался с созданием классов окна, отрисовками, созданием и использованием ДЛЛ. Буду ковыряться дальше.

Пытаюсь разобраться в коде, убивают комментарии типа
...
 ASSERT(0); //WTF...
...

[Phodopus]

судя по secu3man / sources / secu3man / Application / StdAfx.h           

Код:

#pragma once

#define VC_EXTRALEAN  // Exclude rarely-used stuff from Windows headers

#include <afxwin.h>         // MFC core and standard components
#include <afxext.h>         // MFC extensions
#include <afxdisp.h>        // MFC Automation classes
#include <afxdtctl.h>       // MFC support for Internet Explorer 4 Common Controls
#ifndef _AFX_NO_AFXCMN_SUPPORT
#include <afxcmn.h>         // MFC support for Windows Common Controls
#endif // _AFX_NO_AFXCMN_SUPPORT

//---------------------------------------------------------
#ifdef _DEBUG  //'identifier' : identifier was truncated in the debug information
 #pragma warning (disable: 4786)
#endif
#include <atlconv.h>
#include "common\LangLayer.h"

там используется MFC

[Dimka]

Phodopus, там приложение, а нужны лишь функции работы с устройствами, потому что приложение будет другим.

[DGrees]

Написание GUI на винапи мне пока кажется жутким выносом мозга. И пока не разобрался как работать с функциями в событийно-ориентированном программировании, где нет постоянно вертящейся функции main.

[Алексей++]

DGrees, именно поэтому придумали MFC

[Dimka]

DGrees, функция WinMain, конечно, есть. И цикл в ней есть - это главный цикл приёма и обработки сообщений системы. Полученные сообщения дальше перераспределяются по окнам системным диспетчером. Поэтому внутри окна, конечно, цикла нету, а есть только WindowProc - процедура приёма и обработки сообщений окну. Как правило, она представляет собой длинный switch, который по виду сообщения определяет, какую функцию-обработчик вызвать. А весь полезный для решения прикладной задачи код пишется именно внутри этих обработчиков.

[DGrees]

Жизнь весёлая штука
Так повернулось, что я теперь в Питере работаю программистом на C#

[Dimka]

DGrees, и что ты теперь скажешь про эту задачу?

[DGrees]

DGrees, и что ты теперь скажешь про эту задачу?

Проект еще не закончен. Но решил сделать с нуля, т.к. для работы с ком-портом и так есть подходящие классы, а разбираться в чужом коде - те еще забавы. Делаю с использованием WPF.
Хоть и работаю уже программистом, но пока всё равно учусь.
Ну и понял что нафиг я себе такой проект выбрал. Сделал бы за пару дней типовой и не сношал моск. А так и денег и времени немеряно уже потратил.

[Dimka]

DGrees, для GUI - разумно. Но при работе с устройствами смотри внимательно, поскольку .NET - не среда реального времени. Правда, если ты работаешь с COM-портом на типовой скорости 9600 бод, то это не важно - быстродействия любого современного компьютера (и даже компьютера 10-илетней давности) за глаза хватит.

[DneprSMV]

DGrees,
Извини, читать всю ветку времени нет.
Во-первых, неясно, ты делаешь локальную систему или удаленно-контролируемуя (телемеханика).
В любом случае, смотри промышленные протоколы - рекомендую MODBUS-RTU.
В качестве выбора ср-в разработки я после QNX где-то год назад решал подобную задачу.
выбор был как Borland - MS  (С, C++ - без вариантов) так и уровня - Win32, MFC/WTL итд
Остановился на эконом-вариант - VC6 уровня MFC. Сильно рекомендую использовать ++ не только для интерфейса пользователя, но и для основного алгоритма.
MFC не очень удачная для старта платформа (4.2) ввиду того что многое надо держать в голове и додумывать-дописывать руками. Но я это считаю даже в плюс.
Приложение получается с меньшими прослойками и легче отлаживать в конечном итоге.

[Dimka]

Извини, читать всю ветку времени нет.

А писать, значит, время есть.

Он уже определился с инструментами.

Остановился на эконом-вариант - VC6 уровня MFC.

Да, ведь некоторые до сих пор с Fortran 77 расстаться не могут. Особенно "хорош" такой инструментарий в последних версиях Windows.