Отдельные окна, а не внутри окна.

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

Нда, как все запущено. Синтаксис ЯП учится за 1-3 дня в обьеме достаточном для программировиния. Тот же "сложный" c++ в полном обьеме знает пара программистов из сотни, но это не мешает ос альным писать на плюсах. Это касается почти любого ЯП.

А вот дальше идут ОС и библиотеки. Их изучение займет недели. И с ними и будет основной секс у новичка. Я выше советовал QT. Это конечно тяжело для новичка. Однако у qt одна из лучших документаций - можно как книгу читать, а можно как справочник. И не требуются знания ОС для 90% задач. Т.е. учить в итоге надо меньше. Видел даже видео уроки, для тех кому набо быстро чего нибудь наговнокодить.

Всякие красивости, прилипающие окна и т.п. штука удобная, но нужна ли,если есть более понятные для новичка инструменты?

Питон очень логичный язык, не сложный. Можно с qt работать. Я конечно совсем не новичек. Но из всех языков и фреймворков qt понравился больше всего. На 10 из 5 баллов.

Всякие .net ЯП имхо что то среднее. Не туда и не сюда, хотя в целом годные.

А больше всего паскаль и его разновидности у меня не прижились. Х.з. почему. Несколько раз начинал учить, но не хочет он в моей голове жить рядом с десятком других ЯП

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

противопоставление "красивые или понятные" некорректно
у меня с Qt, как и со всеми другими Visual C и иже с ними, так и не зашло по одной причине: после изобилия и гибкости Delphi 7 все остальное выглядело УГ. а когда я выяснилось, что Delphi и рядом не стоит (в плане изобилия и удобства) с Code Typhon, то и подавно. и все минусы паскаля, среды и GDB-отладчика отходят не на второй план, а на 33-й.

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

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

Подробнее>>

За время, пока вы спорили, можно было бы написать на C++ в Visual Studio нужную софтину.

Вот моё


Написано в Visual Studio с использованием Dialog based MFC всего за неделю.
Причем, интерфейс динамический и перестраивается при изменении размеров окна.
Туда же входит и написание API для встроенной поддержки скриптов на языке Lua.
Тестировал на 100 тысячах датчиков. Только тогда при перестройке интерфейс задумывается на 10 секунд,
так как все вкладки и их содержимое пересобираются в новые структуры. В остальном работает так же.
Правда, для новичков скорее всего предложенная мною связка не пойдет,
хотя я раньше лабал на MFC окна, зная C++ на уровне начинающего Сишника.

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

То есть вы неделю назад не имели ни малейшего представления о разработке программ. И за неделю смогли изучить C++, работу в VS и написали программу?
Прочитайте первое сообщение темы.

Этим сейчас не удивить.

На экране отображаются одновременно информация из 100 тысяч датчиков? Если нет, зачем в не отображаемые выводить информация и перестраивать? Их же не видно.

Мурик человек вроде имеет представление, так как пишет ПО для МК на ассемблере. Или я что-то не так понял?
Я в свое время с помощью гугла и сайта First Steps написал на этой платформе две программы, работающие с COM и LPT
портами. При этом я даже Си почти не знал. Я тогда только учился программировать железо. Написал за неспешные полторы недели.
Потому опираюсь на свой опыт 10-летней давности.

На MFC часть динамики интерфейса имеется в виде встроенного функционала, основную же часть нужно писать руками.

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

имхо, попытка сделать то,что никогда никому не будет нужно - пустая трата сил. поскольку программа отображает данные для человека, а средний человек не в состоянии следить более чем за 7-ю параметрами одновременно, и даже особо тренированный (типа авиадиспетчера или персонала АЭС) может уследить лишь за парой десятков параметров, даже попытка реализовать вывод 100 тысяч параметров абсолютно, дико, безумно глупа.

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

ARV Так оно так и реализовано. 100 тысяч - это ради замера производительности и оценки ее запаса.
При выборе вкладки, создаются окна датчиков и в каждом из них заводится таймер,
который берет данные от привязанного к окну датчика и выводит их в окно. При переключении вкладки,
глушатся таймеры и уничтожаются все окна. На новой создаются окна и заводятся таймеры.
На дешевый монитор 720р как раз и вмещается 20 штук. Под это разрешение оно и подгонялось.
На предприятии 350 емкостей с термодатчиками. Их нужно мониторить. Но не все сразу и не круглосуточно,
а только когда идут определенные технологические процессы.
В разделе "Контроллеры" можно выбрать, что будет отображаться во вкладках. У каждого датчика есть параметры,
типа имени, калибровочного значения, записи значений в график, величины диапазона отклонений от нормы и оповещения в случае выхода
за пределы диапазона. Причем, если где-то это произошло, программа отмечает вкладку другим цветом и переключается на первую же,
где произошло это отклонение.

Например старенький Визуал Бейсик 6 спокойно подключает API-функции. А это позволяет делать хер знает что - и окна (фреймы) в виде баранки, и окна с изменяемой прозрачностью (до невидимости), и плавное открытие-закрытие фрейма, и тд и тп.
Я считаю язык программирования просто инструментом. И чем проще инструмент, тем лучше. В деле надо сосредотачиваться на цели, а не бороться с инструментом.

Недавно обнаружил, что Фортран до сих пор поддерживается, притом Интелом. А почему? Потому что для многих пользователей при решении определенных задач это простой и удобный инструмент.

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

Которые нужно ручками декларировать... Со структурами и константами тоже самое. Из коробки не поддерживается. Другими словами VB6 не поддерживает WinAPI. Он поддерживает вызов функций из DLL. Но работа с WinAPI затрудняет концепция безопасного программирования согласно которой - никаких указателей и работы с памятью.
Вообще VB6 устарел. x64 не поддерживает. Многопоточность не поддерживает. Создание нативных DLL не поддерживает.

Да. Я вот, в каждом приложении использую х64, многопоточность и нативные длл. Ага.

У всех задачи разные. Примерно в каждой второй моей проге используется многопоточность.
x64 приложения тоже создаю. Особенно часто это в случае x64 DLL, для x64 приложений (на заметку - разрядность DLL должна быть такой же как у приложения).

Да, с Питона начать будет вполне правильно, по своему опыту говорю.

на чем привык... делфи например... (это графический паскаль)

Есть не плохой Бэйсик компайлер, называется PureBasic.
Старый, довольно таки простой и очень мощный компайлер.
Для наших любительских дел то что надо.
Конечно на вкус и цвет....... но для тех кому не уютно с С, PureBasic самое то.

Успехов.

Его уже рекомендовали. Жаль, платный.

Skalkin, обозвать делфи графическим паскалем - это мощно....

Цена символическая.
Не всегда бесплатные продукты имеют хорошую поддержку. Я столкнулся с этим в IDE для STM32. Ее автор много лет не выпускает обновлений потому что из-за бесплатности у него нет стимула. Он занимается более прибыльными проектами.