Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Нужен совет по выбору инструмента  (Прочитано 27428 раз)
0 Пользователей и 1 Гость смотрят эту тему.
DGrees
Интересующийся

ru
Offline Offline

« : 22-06-2011 22:03 » 

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

ru
Offline Offline
Пол: Мужской

« Ответ #1 : 23-06-2011 03:31 » 

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
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #2 : 23-06-2011 06:16 » 

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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Алексей++
глобальный и пушистый
Глобальный модератор

ru
Offline Offline
Сообщений: 13


« Ответ #3 : 23-06-2011 06:49 » 

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

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

Записан

DGrees
Интересующийся

ru
Offline Offline

« Ответ #4 : 23-06-2011 07:19 » 

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 платформе обычно такое можно, а тут кнопочку изменить не нашел....
--
кнопка изменить появилась после нескольких сообщений

* план стенда-Model.jpg (394.43 Кб - загружено 2672 раз.)
« Последнее редактирование: 24-06-2011 09:29 от DGrees » Записан
Джон
просто
Администратор

de
Offline Offline
Пол: Мужской

« Ответ #5 : 23-06-2011 07:49 » 

Подошел в институт на кафедру программирования к преподавателям, которые типа знают 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.

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

Я вам что? Дурак? По выходным и праздникам на работе работать. По выходным и праздникам я работаю дома.
"Just because the language allows you to do something does not mean that it’s the correct thing to do." Trey Nash
"Physics is like sex: sure, it may give some practical results, but that's not why we do it." Richard P. Feynman
"All science is either physics or stamp collecting." Ernest Rutherford
"Wer will, findet Wege, wer nicht will, findet Gründe."
DGrees
Интересующийся

ru
Offline Offline

« Ответ #6 : 23-06-2011 08:42 » 

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

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

ru
Offline Offline
Пол: Мужской

« Ответ #7 : 23-06-2011 09:09 » 

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

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

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


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

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
DGrees
Интересующийся

ru
Offline Offline

« Ответ #8 : 23-06-2011 09:48 » 

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

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

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

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

ru
Offline Offline
Пол: Мужской

« Ответ #9 : 23-06-2011 10:04 » 

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

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

ru
Offline Offline
Пол: Мужской

« Ответ #10 : 23-06-2011 10:44 » 

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

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
DGrees
Интересующийся

ru
Offline Offline

« Ответ #11 : 23-06-2011 11:26 » 

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

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

ru
Offline Offline
Пол: Мужской

« Ответ #12 : 23-06-2011 14:17 » 

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 всё подряд - стараться минимизировать количество экспортируемых элементов.
« Последнее редактирование: 24-06-2011 10:41 от Dimka » Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
DGrees
Интересующийся

ru
Offline Offline

« Ответ #13 : 23-06-2011 18:42 » 

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

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

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

------
Нашел классный мануал на msdn, делаю по нему: http://msdn.microsoft.com/ru-ru/library/ms235636.aspx
------
По msdn программа hello World! на Win32 API (C++) занимает около 90 строк кода без учета комментов   Должен же быть выход!!!
« Последнее редактирование: 24-06-2011 10:58 от DGrees » Записан
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #14 : 24-06-2011 10:48 » 

Цитата: DGrees
Вопрос возник. А как звучит окончание пункта 2.1?
Опечатка - убрал. Дальше шёл текст, вынесенный в заголовок раздела 2.

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

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
DGrees
Интересующийся

ru
Offline Offline

« Ответ #15 : 27-06-2011 09:41 » 

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

Пытаюсь разобраться в коде, убивают комментарии типа
...
 ASSERT(0); //WTF...
...
« Последнее редактирование: 27-06-2011 10:30 от DGrees » Записан
Phodopus
Интересующийся

ru
Offline Offline

« Ответ #16 : 02-07-2011 11:16 » 

судя по 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
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #17 : 02-07-2011 14:30 » 

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
DGrees
Интересующийся

ru
Offline Offline

« Ответ #18 : 05-07-2011 20:54 » 

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

ru
Offline Offline
Сообщений: 13


« Ответ #19 : 06-07-2011 03:18 » 

DGrees, именно поэтому придумали MFC Улыбаюсь
Записан

Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #20 : 07-07-2011 06:32 » 

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
DGrees
Интересующийся

ru
Offline Offline

« Ответ #21 : 10-09-2011 17:17 » 

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

ru
Offline Offline
Пол: Мужской

« Ответ #22 : 10-09-2011 21:36 » 

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
DGrees
Интересующийся

ru
Offline Offline

« Ответ #23 : 11-09-2011 09:30 » 

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

ru
Offline Offline
Пол: Мужской

« Ответ #24 : 11-09-2011 09:58 » 

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
DneprSMV
Помогающий

kz
Offline Offline
Пол: Мужской

« Ответ #25 : 08-10-2011 20:20 » 

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

"Не слушайте никаких советов, в том числе и этот" (Сократ ?)
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #26 : 08-10-2011 23:35 » new

Цитата: DneprSMV
Извини, читать всю ветку времени нет.
А писать, значит, время есть.

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

Цитата: DneprSMV
Остановился на эконом-вариант - VC6 уровня MFC.
Да, ведь некоторые до сих пор с Fortran 77 расстаться не могут. Особенно "хорош" такой инструментарий в последних версиях Windows.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines