Подпрограммы и окна.

[ann_nef]

Предположим есть проект Pr , исп. диалог PrDlg, в нём описана подрограмма РР1 ,кот. исп. вложенную пп
РР2, а та в свою очередь вызывает РР3. В основном диалоговом окне PrDlg эта конструкция работает.
Из основного окна вызывается ещё один диалог NewDlg , из кот. я обращаюсь к РР1.
Выглядело это примерно так:
 PrDlg Wmain;
 Wmain.PP1(...);

Всё было бы хорошо, но пп PP1 выдает не тот результат, кот.получается, если вызывать её в основном окне.

 Что-нибудь понятно из моего вопроса?
А спросить я хотела: Используется ли множественное вложение пп ,как в Си?
(я переписываю ДОСовскую необъятную чужую программу с прибором,подкл. к СОМ-порту, поэтому проект прикреплять смысла нет)

Или это в С++ совсем не так делается?

[Алексей++]

Ань, что есть "вложение пп"? Что есть "пп"?

Ну а так, в С++ можно всё, что можно в Си

[Джон]

Весь проект - нет, но часть кода поясняющую: "Используется ли множественное вложение пп ,как в Си?", было бы неплохо.

[ann_nef]

пп - это подпрограмма.
Попытаюсь создать минимальный проект, который смогу вам послать.

[Джон]

Я думаю тут явное непонимание терминологии. Ни в С++, ни в С нет никаких пп. Есть ф-ции. Определять ф-цию, внутри другой ф-ции (локальные функции) нельзя. Всё-таки, ещё раз, что же такое "множественное вложение пп"?

[ann_nef]

Джон, наваяла минимальный кусок из своего проекта. Результат такой же.
Если идти по пути
1. Работа с ПЛИС-> чтение-> окно Ввод адреса ПЛИС <ввод> , то рез-т НОРМ, те читается содержимое ячейкм, адрес кот. ввели и на экран выводится buf_otv

2. Работа с АСО-> АСО -> окно АСО <чтение> , то результат Ошибка..., те прибор не отозвался.

Мне кажется, что дело не в приборе, а в моём плохом знании Visual C++ 6.

У вас и в 1 варианте получится рез-т ОшибкаДоработать... Но,мб вы по коду поймёте,что я не так делаю.

[Джон]

Легче не стало. Папку "res" забыла. Но это не главное.

Проблему всё-равно не видно. Ща ещё раз прочитал твоё первое сообщение. Понял примерно след.:

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

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

Твои ошибки сводятся не к незнанию шестёрки, а к непониманию структуры программы (в код-скобки не беру, чтобы сохранить выделения):

Смотри что получается. В основном диалоге CPrDlg ты создаёшь объект-диалог типа Maco и показываешь его модально:

void CPrDlg::OnMENUaco()
{
  Maco WinACO;
  WinACO.DoModal();
}

Теперь в нём ты создаёшь НОВУЮ ИНСТАНЦИЮ основного диалога без какой бы то ни было инициаллизации!!!, но тем не менее вызываешь ф-ции требующие эту инициаллизацию RDPLIS -> REC_RS -> inbyte ->  Inp32(comm ? ? ?:

void Maco::OnBreadAco()
{
    int i;
    byte al,ah,dan;
    WinAdr WinAdr1;
    CPrDlg Wmain;

    UpdateData(true);
   if((i=WinAdr1.vvANDtest(m_adrACO,0,0xffff))!=NULL)
   {
      al = i&0xff;
      ah = (i&0xff00)>>8;
      dan=Wmain.RDPLIS(al,ah);
      m_danACO.Format("%2x",dan);
      UpdateData(false);
   }   
}

Но ведь по сути ты хочешь работать с уже открытым в CPrDlg портом. Или другими словами, тебе нужна не новая инстанция, а уже существующий объект типа CPrDlg. Родитель этого самого Maco.

Короче, тебе надо сначала на бумажке нарисовать все взаимодействия частей твоей программы друг с другом. Определить интрефейсы общения между ними. Те занятся собственно программированием. После этого уже переходить к кодингу. Тем более, что проект по твоим словам огромный. И если с самого начала не делать правильно, чётко и ясно, то в будущем тебе придётся с ним очень туго.

И лучше разделить, как я выше сказал. Один объект отвечает за порт, а окошки пользуются этим объектом. Что не понятно? Спрашивай.

[ann_nef]

Ты прав, что дело не в функциях, я просто не знала,как спросить.
Интуитивно понимала, что так нельзя:вызвать ф-цию из родителя Maco.
Один объект отвечает за порт, а окошки пользуются этим объектом.
Вот это и непонятно,как сделать.

Боюсь,что ответ будет: "Учи мат.часть".
Книг накупила много, но всё не о том.
Страуструп не пошёл совсем.

Мне бы какой-либо конкретный пример про объект, отвечающий за порт, и окошки,кот.им пользуются. Или любой другой,только не круги рисовать.

[Джон]

Ну не совсем. Учить матчасть придётся по-любому. Хочешь ты того или нет. Тут проблема даже не в матчасти, а понимании сути происходящего. Ибо ты уже практически всё сделала, но сама не поняла что (см. ниже). Поэтому сначала немного теории:

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

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

Мне бы какой-либо конкретный пример про объект, отвечающий за порт, и окошки,кот.им пользуются. Или любой другой,только не круги рисовать.

Ладно, круги рисовать не будем. Я начинал с дроби,  с объекта типа "дробь". Тоже неплохо, есть два поля данных - числитель и знаменатель, есть операции - сложение, умножение, вычитание и деление...

Но и этим не будем заниматься (хотя для лучшего понимания ООП всё-таки стоит, оставим это на домашнее задание). Возьмём то, что у тебя уже есть (то самое "см. ниже"). На самом деле всё очень просто. У тебя уже есть такой объект! Только он у тебя является генетическим уродом, сиамским близнецом. Диалог-Порт. Это две сути. Два разных объекта, которые ты в результате многочасовой операции таки скрестила в один. Сложно? Посмотри на свой CPrDlg. У него есть куча ф-ций, которые не имеют к диалогу абсолютно никакого отношения.

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

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

Код:

void CPrDlg::OnopenCOM() 
{
 // îòêðûòèå, èíèöèàëèçàöèÿ ïîðòà ÑÎÌ
 if (InitOpenPort(0, 38400) != 0)
 {
	MessageBox("Ïðîãðàììà çàâåðøàåòñÿ:ïîðò íå áûë îòêðûò!");
	OnOK();
 }	
}

то значит твой объект MyCOMPort получит точно такую же (по смыслу) ф-цию, но только возвращающую статус, а не показывающую сообщение об ошибке. Откуда этот объект знает, что должен быть показан именно MessageBox? Ведь его надо закрывать, те подразумевается участие человека. А если этот объект будет использоваться в каком-нить автоматическом модуле? А сообщения об ошибке должны заноситься в спец. файл-журнал? Ещё одна святая истина - КАЖДЫЙ ОБЪЕКТ ДОЛЖЕН ВЫПОЛНЯТЬ ТОЛЬКО СВОЮ РАБОТУ! Ну и сообщать о результатах ессно. Это позволяет делать такие объекты легко заменяемыми. Без изменения остальных частей программы. Итак в данном случае будем иметь след картину:

Код:

void CPrDlg::OnopenCOM() 
{

 if (!theApp.m_myCOMPort.OpenPort() )
 {
	MessageBox("Ïðîãðàììà çàâåðøàåòñÿ:ïîðò íå áûë îòêðûò!");
	OnOK();
 }	
}

...

BOOL MyCOMPort::OpenPort()
{
     return (BOOL) (InitOpenPort(0, 38400) == 0);
}

Заметь где находится инстанция объекта МyCOMPort.  

Идея ясна?

[ann_nef]

Джон, спасибо. Буду переваривать, попробую на Pr, а потом к своему монстру вернусь.
О программировании и языках, как ни странно,если судить по моим вопросам, я знаю вполне достаточно,тк имею большой опыт в функциональных языках  и средний в Delphi.
А по поводу матчасти:
1.В самоучителе по С++ достали cout и cin, примеры иллюстрирующие элементарные возможности С и полное ощущение, что всё это не том.
2.Visual Studio C++ и MFC помогает разбираться с кнопками, меню и всякой
хренью, знакомой по Delphi, но не помогает понять язык.
Туда же "Использование Visual C++ 6"
3.Страуструп даже для справочника не использую.
Все они круги рисуют.

Мб Лафоре и ваши советы помогут понять С++.
Если у вас есть совет по книгам, приму с благодарностью.

[Алексей++]

Если у вас есть совет по книгам, приму с благодарностью.

Страуструпа всё-таки надо почитать

[Sla]

Читать книги и учить по ним - суть разная.
Умение абстрагироваться о описанного в книге - главное.
Невозможно описать все мыслимые и немыслимые приложения в одной или нескольких книгах.

Вот Джон тебе и привел пример.
Круги, Окна (диалоги), Порты.

Ты вот пишешь - имею большой опыт в функциональных языках (структура)  и средний в Delphi (ООП).
Структурное программирование. Заключается в том что каждая ПП занимается своим делом.
Если отойти от объектов(классов), то на начальном этапе  структурное программирование ничем не отличается от ООП.
По сути и твоя задача не требует ООП (имхо)
В некоторых случаях это может даже навредить, например, в скорости обработки информации.

С другой стороны, можно объединить и ООП и структурный подход.

Есть классы диалогов, они уже написаны с применением ООП, их задача - визуализация.
Структура - обработка данных.

Вот твоя задача объединить все в одно целое ПО.


В твоем примере

Окно - класс(объект)
Порт - набор ПП (функций).
Можно, конечно сделать  Порт объектом, тогда ПП (функции) будут называться методами.

Теперь пример:

Функция ЧтениеПорта (НомерПорта){
  return ДанныеИзПортаНомерПорта
}

Объект
Порт {
   НомерПорта;
   Init(НомерПорта); //метод - конструктор
   Read (); //возвращает прочитанные данные
   Write (Данные); //записывает данные

//Описываем методы
   метод Read(){
     return ДанныеИзПортаНомерПорта;

}

}

Показан минимальный функционал.

теперь Приступаем к решению задачи
//Структура
InitДиалог;// не забываем - это объект
Диалог
  Чтение(235);
  Запись(235, Данные);

//ООП
InitДиалог;// не забываем - это объект
potr235 new InitPort(235); //это тоже объект
Диалог
  Port235.Read();
  Port235.Write( Данные);

Разницу чувствуешь? Что более читабельно, что более производительно?
Кстати, производительность в данном примере лучше не рассматривать.

[ann_nef]

Да. Потихоньку проясняется...

[Джон]

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

ann_nef, сорри, ни в коем разе не хотел обидеть. Если есть такое ощущение, то оно ошибочно. Я сужу не по вопросам, а по коду. Умение задавать вопросы - это целое искусство, поэтому на формуе большей частью всегда требуется прилагать код, ибо этот язык более однозначен и понятен программерам. Ну и плюс ко всему я всегда говорю как вижу и понимаю, часто это приводит к недоразумениям. Это ещё и на будущее. Я думаю мы нескоро расстанемся.  

Понимаешь, в принципе даже необязательно программировать в ООП. Ведь раньше люди как-то обходились без этого. Я тоже начинал с Паскаля. Дело не в этом. А в структуре программы, построении алгоритма. Даже в твоём случае - свалилась на тебе грандиозная переделка чужого проекта. Всё-равно, сначала надо заняться проектированием. На бумажке. Нарисовать структуру программы БЕЗ КОДА!!! Простыми словами и линиями. Затем, по этой схеме из существующиего кода выделить основные функциональные модули (это может быть просто набор ф-ций и глобальных переменных). Отделить функциональные модули от пользовательского интерфейса. Это первоначальное и необходимое условие успешного развития проекта. Далее уже можно определять какие модули нужно заменить/изменить. Заметь, о языке программирования ни слова. И уж тем более о специальных системных ф-ях (в твоём случае это inpout32.dll). Для программы в целом совершенно неважно, КАК будет осуществлён обмен данными с портом. Это забота отдельного модуля, который просто обязан быть легко заменямым. Даже в твоём примере-проекте достаточно было бы вместо вызова ф-ций этой длл просто делать трассировку обращения к ф-ции, а в случае необходимости ответа - возвращать некие постоянные числа или строки. Это быстро дёшево и сердито. Работу программы уже можно отслеживать и настраивать.
Для реальной работы останется только заменить "болванки".

Теперь про язык. И в С++ можно программировать функционально, даже под виндой с GUI. Это чистый Win API. Ну а уж переход с Дельфи на С++ вобще не должен представлять трудностей, ибо программирование под виндой ты уже знаешь. Единственное, что нужно будет выучить - новые названия ф-ций и классов. Тут тебе MSDN (от себя добавлю: И ТОЛЬКО MSDN) в помощь. А

1.В самоучителе по С++ достали cout и cin, примеры иллюстрирующие элементарные возможности С и полное ощущение, что всё это не том.

и goto's в коде, прости меня, но это просто детский лепет. cout и cin - это простейший способ обеспечить минимальную коммуникацию программы с пользователем. Ведь как-то это должно работать? Это всё-равно что говорить: "блин как надоели эти if-ы и for-ы!". Ну про гоуту ты наверняка и сама знаешь.

3.Страуструп даже для справочника не использую.

Плохо, лучше всё-таки использовать.

Как у тебя с аглицким? Есть очень хорошая бесплатая книжка: "Thinking in C++". Её полно в инете. Может быть это будет то?

[ann_nef]

Джон, ни в кое случае обиды нет и не будет.
Мой первый начальник говорил: "Ум хорошо, а 1.5 лучше". Я-то думала, хорошо что за мной 0.5 числится, а оказалось , что все все 1.5 - его. Но,научил он меня многому.
Код беспомощный, сама знаю.
Была бы моя программа(или даже часть большого проекта) с нуля, ессно,
нарисовала бы блок-схему, структуру программы и тд. И всё было бы моё: и глупости и умности.
Здесь я ковыряюсь
1. в огромном исходнике, где очень много затрачено на элементарные менюшки и псевдографику!!!(описаны прообразы кнопок,линейных регуляторов и тд), нет ТЗ на прибор и на любой вопрос разработчик прибора отсылает меня к старому коду. Вот где goto используется повсеместно!
2. по началу билась с портами, оказалось. что кроме того,что Виндоза закрыла прямое обращение к ним(это я изначально знала), так ещё доблестные сисадмины !  Пока не поставила несетевой комп, у меня прибор совсем не отзывался.  Использование библиотеки inpout32 тоже не выход.
С этим придётся ещё разбираться.
3. а знание, даже понимание с++ чуть больше 0.

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

[Sla]

на правильные вопросы будут правильные ответы.
Что касается работы с портами, у нас есть статья по работе с COM портами
https://club.shelek.ru/viewart.php?id=208
И автор здесь постоянно зависает

У тебя сейчас две задачи

GUI
Работа с портами

Обе могут решаться и писаться параллельно

[ann_nef]

Ага. Эту статью нашла самостоятельно и буду изучать.
А пока очень простой вопрос:
если    CSpinButtonCtrl   m_spinWin4;
...
Mwin4::OnInitDialog:
         m_spinWin4.SetBase(16); // нужна именно эта система счисления
   m_spinWin4.SetRange(0,0xff);
...
Spin щелкает по 16-тиричной системе, но при вводе 0x0001 выдает сообщение: Введите положительное целое число.
Что опять не так сделала?

[Алексей++]

Наверное, "0x" ему не требуется

[Джон]

1. Ну так и тем более. Ты шефу так и объясни, что сначала надо вытащить из старого кода логику, а затем спроектировать всё с нуля. У меня аналогичная ситуация была лет десять назад. Куча кода 50% /50%  С/Ассемблер, ДОСовская прожка. Кстати она тоже работала с портами COM, LPT. Надо было сделать функциональный аналог под Винду.

2. На эту тему вобще не беспокойся, на форуме уже сто раз обсуждалась и разжёвывалась эта возможность. Никаких inpout32 не понадобится.

[ann_nef]

Дык, это же он сам так щелкает.
1 съест, а вот 0х00аа(AA) или просто аа(AA) нет, в том числе 0x0001.

получается, что 16-тиричная система работает ,когда измен. с помощью Spin, но при вводе он же понимает только цифры, буквы ( a...f) нет, те уже 10тичная.

[Джон]

ann_nef, дело в том, что сам спин это ещё полдела. Он цепляется к Edit. И свойства этого контрола определяют параметры ввода. У тебя наверняка у него стоит Int (или как там в шестёрке?). Те такой Edit понимает только цифры.

[ann_nef]

Да, Джон, ты прав.
Я уже это определила, надо ставить CString в Edit, тогда вручную любую ерунду можно вводить, типа kdkdowqzz. Значит, контроль введённого адреса надо на себя брать,как у меня и было.

Добавлено через 4 дня, 5 минут и 16 секунд:
С вашей общей помощью дело сдвинулось: поняла,как сделать,чтобы получить искомый результат, и стало с классами проясняться.
Долго возилась со статьёй Алексея 1153 о менеджере сом-порта. Всё это мне пригодится.
Но, не поняла : "А почему так сложно класс вписывается?" Я пару раз запуталась и до сих пор с сомво-боксами не получилось. Разберусь и с этим.
Обычным путём нельзя???: создаём диалог, прописываем ф-ции и переменные. Или я опять чего-то не понимаю?

[Алексей++]

"А почему так сложно класс вписывается?"

а про что речь? Не совсем понял

[ann_nef]

Не суть важно.

[Алексей++]

Как это не важно! Когда что-то непонятно - нужно задавать вопросы.

[Джон]

ann_nef, это наверное крик души? Надеюсь, что не отчаяния. Если честно, то я тоже ничего не понял.

[ann_nef]

Неа, не крик.
 
Просто,вставляя тексты из CComPortManager_h_class.txt  в ... и тд , получала не тот результат,как
у автора статьи. Поскольку знания пока слабые...
А на самом деле это же можно описать,как в книгах? Таскаем элементы диалога типа Edit, ComboBox,
Static и тд. Связываем их с переменными, описываем структуры PORTPROPERTY и др, добавляем ф-ции
 Copy_controls_to_property и др. В результате ведь получится такой же класс CComPortManager?
Вопрос дурацкий. Тем более,что одного и того же можно добиться разными путями.
Статья было не о том и предназначалась не начинающим.
I am so sorry!

[Алексей++]

Ань, версии студий, наверное, отличаются ) Там писалось в 6-й версии. А насчёт диалога - можешь его вообще выкинуть, он как бесплатное приложение. Сделай свой

[Джон]

ann_nef, если хочешь разобраться с СОМ портом и у тебя шестёрка, то в MSDN задай в поиск "MTTTY" - это пример с GUI. Также задай его в поиск по форуму, найдёшь сопутствующие темы.

[ann_nef]

Алексей, вот такой вопрос возник:
Хотелось бы открыть и настроить порт в начале программы и закрыть перед выходом из неё.
Предположим есть класс
class MyComPort: public CDialog
{
 ...
private: //типа из вашей статьи не сама такая умная.
  HANDLE hCom; 
...
public:
  bool OpenInitPort();
  bool ClosePort();
  bool RDPLIS();

...
}

есть два диалога, тоже два класса :
1 Cmain: public CDialog
{
  MyComPort MCPa;
  if(!MCPa.OpenInitport)
 {
        MessageBox("Error");
        ...
  }
  else MCPa.RDPLIS(...)
  ....
  MCPa.ClosePort...;        //это надо делать???
  Maco WinAco;
  WinAco.DoModal();

}
2 Maco: public CDialog
{
 MyComPort MCPb;
  if(!MCPb.OpenInitport)
 {
        MessageBox("Error");
        ...
  }
  else MCPb.RDPLIS(...)

}

При инициализации объекта класса MyComPort надо в том и другом диалоге надо обращаться к OpenInitPort(),те закрывать предыдущий сеанс из другого диалога или иначе ?

Понятно, что я хотела спросить?