cnc-club.ru

michael-yurov писал(а):Я так и не понял, ответ.

Михаил, как там работа над программой PathMaster движется?

MX_Master писал(а):Михаил, как там работа над программой PathMaster движется?

Никак не движется. Даже не вспоминаю о ней. Чтобы существенно продвинулась нужно несколько месяцев поработать, а у меня этих нескольких месяцев нет, и не будет в этом году. Я ведь так и говорил, что система будет, но ооочень не скоро. Нет смысла ждать и надеяться.

michael-yurov писал(а):Нет смысла ждать и надеяться.

Оптимистичненько так

Дом наверное строит...

Наконец, появилось время, чтобы заняться пафмастером. Потихоньку продолжаю работу:

не смог пройти мимо, заплакал. 1245 строк кода (только то что видно)! Это... как листать в одном файле??? Чего не разбить на куски?
Я не опытный программист, но так наверное не смогу
И не надо про монитор 3840х2100, все равно неудобно )

uralpt писал(а): ↑ не смог пройти мимо, заплакал. 1245 строк кода (только то что видно)! Это... как листать в одном файле??? Чего не разбить на куски?
Я не опытный программист, но так наверное не смогу
И не надо про монитор 3840х2100, все равно неудобно )

Нет никаких проблем, просто нужно изучать доступные возможность и пользоваться ими.
И большие проекты в одно лицо не проблема - всё дело в правильном структурировании и повторном использовании ранее написанного кода.

я в среде маньяков-программистов
не-не-не, я лучше разобью блоками по 30-50 удобочитаемых строк.
Хотя, может я просто так листинги читать не умею -

uralpt писал(а): ↑ 1245 строк кода (только то что видно)!

Там только файл разметки главного окна на 2000 строк (только кнопочки и надписи, без функционала). Его и смысла то делить нет.
А в этом файле обработчик OpenGL окна. Всякие 3d вычисления с векторами и матрицами. Только начал писать )))
Можно сделать просто, но пользоваться будет сложно. А можно наоборот.

Serg писал(а): ↑ Нет никаких проблем, просто нужно изучать доступные возможность и пользоваться ими.

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

uralpt писал(а): ↑ не-не-не, я лучше разобью блоками по 30-50 удобочитаемых строк.

Что выбирать нужные "куски кода" не справа, а слева?

Ещё можно вот так "уменьшать" количество строк при просмотре:

michael-yurov писал(а): ↑ Там только файл разметки главного окна на 2000 строк (только кнопочки и надписи, без функционала). Его и смысла то делить нет.

Даже по фреймам окна?..

Serg писал(а): ↑ Даже по фреймам окна?..

Еще много файлов в проекте будет.
Я лучше их по функционалу разделю. Мне категорически не нравится сама идея ООП. Во всяком случае в современной реализации.

Serg писал(а): ↑ просто нужно изучать доступные возможность и пользоваться ими.

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

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

все, что после 1210 строки я бы закинул в отдельный файл, обозвал его "FitTo Screen.cpp" и в main() возвращал его результат.
А modelcentre в С++ нужно называть методом со всеми вытекающими изменениями в коде. И голове Во всяком случае, приучаю себя делать именно так.

Я для себя открыл vscode + плагины. Там все пимпачки, закладки, git, правки, outline, TODO, FIXME - удобно структурированы.

Что касается проекта.. Может, уже и советовал. Понимаю, что веб технологии - это не самая сильная область знаний Михаила. Но визуальную часть я бы советовал делать на вебе. Мультиплатформенно. Всё остальное - консольные программки на чистом С, с лёгкими правками в зависимости от платформы. Безо всякого ООП.

Размеры файлов значения не имеют.

MX_Master писал(а): ↑ Но визуальную часть я бы советовал делать на вебе.

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

Serg писал(а): ↑ А вот в эти фигульки пробовал тыкать?

Да, пользуюсь. Даже выяснил, что можно их расставить как мне нужно.
И обозреватель есть:

Serg писал(а): А ты интересовался какие ещё можно вывести?

Интересовался. Но то, что можно вывести не совпало моими предположениями.

Все запихивать в один файл в некотором смысле подталкивает сама концепция ООП с разграничением пространств имен. Очень много чего не передашь в метод / функцию вместе с набором параметров. Нужно, видимо, сделать отдельный класс (в отдельном файле), доступный из всех других частей программы, в котором будут храниться глобальные переменные с основной массой данных. И уже к нему обращаться из разных частей программы.
С компонентом окна OpenGL я вообще не понимаю, как правильно работать. Т.к. огромная часть кода должны быть в обработчике перерисовки кадра, т.к. только там у меня есть возможность доступа к элемента класса, работающего с 3d графикой. Я хоть и вынес некоторые методы наружу, но приходится им в виде параметра предавать текущий экземпляр компонента работающего с OpenGL, т.к. он существует только в пределах обработчика / метода перерисовки окна.
Прошу прощения за терминологию. Пока что у меня с этим плохо.
Еще стараюсь использовать многопоточность там, где от этого есть польза. А разграничение доступа и пространств имен категорически против этого, не зависимо от того, насколько аккуратно я стараюсь взаимодействовать с общими данными из разных потоков.
Я не прошу ответов или советов. Постепенно разберусь, и постараюсь навести порядок. Просто ответил.

Serg писал(а): ↑22 апр 2021, 18:38

MX_Master писал(а): ↑ Но визуальную часть я бы советовал делать на вебе.

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

Система ЧПУ — такая штука, которая всегда должна отображаться на экране. Там отображается текущее состояние, там важные элементы управления, там единоличное использование клавиатуры, и т.п.
А браузер, обычно, используют для кратковременного доступа к ресурсам сети. Запустил браузер, проверил почту, закрыл. Если при этом во второй вкладке будет экран управления ЧПУ станком — он тоже будет благополучно закрыт вместе с браузером.
Да, конечно, можно снова запустить, снова подключиться, и серверная часть программы должна будет продолжать работать в фоне, или вообще на контроллере, но это неправильно, когда станок у тебя сам работает, а ты его не контролируешь.
И я понимаю, что можно сделать свой минибраузер для данной конкретной задачи, но это тоже не то.
И я прекрасно понимаю, чем мне грозит выбор виндоуса. И понимаю необходимость использования легальных версий ОС на производстве. И даже предполагаю возможным, что у нас могут нафиг Виндоус запретить, или вообще запретят ввозить интелы и амд, и пересадят всех принудительно на какую-нибудь типа отечественную ось на базе линукса и какие-нибудь байкалы.

michael-yurov писал(а): ↑ Все запихивать в один файл в некотором смысле подталкивает сама концепция ООП с разграничением пространств имен. Очень много чего не передашь в метод / функцию вместе с набором параметров. Нужно, видимо, сделать отдельный класс (в отдельном файле), доступный из всех других частей программы, в котором будут храниться глобальные переменные с основной массой данных. И уже к нему обращаться из разных частей программы.

Именно так и делается - публичное объявление класса отдельно, приватные объявления отдельно, реализация методов отдельно. Методы и без передачи имеют доступ ко всем ресурсам класса. Общие для методов переменные/данные за пределами класса - это крах ООП.

michael-yurov писал(а): ↑ Я хоть и вынес некоторые методы наружу, но приходится им в виде параметра предавать текущий экземпляр компонента работающего с OpenGL, т.к. он существует только в пределах обработчика / метода перерисовки окна.

Сделать класс с ним и наследовать другими.

michael-yurov писал(а): ↑ Еще стараюсь использовать многопоточность там, где от этого есть польза. А разграничение доступа и пространств имен категорически против этого, не зависимо от того, насколько аккуратно я стараюсь взаимодействовать с общими данными из разных потоков.

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

Serg писал(а): ↑ Естественно в методах должна быть поддержка диспетчеризации

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