Суть в том что под винду есть некий жёсткий WinAPI и это объединяет все софтины.
Суть в том что ниодин язык программирования его не умеет. Надо приделывать ко всему костыли. Софтины на своём движке большая редкость.
Из опенсорса иногда используются никсовые API, видок у них странный, но свой.

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

А теперь осталось найти список всех возможностей интерфейса и демку на выбраном языке.
Мне хватает Autoit, там все эти кнопочки есть. Но я не програмист, так что не люблю это дело и ничего не помню об этом и не пишу.
Хотел им к порту подключится, да забил, дело не дошло.

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

Не умеет вызывать WinAPI функции?

Кнопочки это типа все WinAPI?

Забыли про службы, дрова, различные библиотеки (DLL, OCX) и т. д.
С чего такие выводы? Нет деления на консольные и оконные. В приложении может быть то и другое. В библиотеках тоже.

Интересная тема...
И кто на чём пишет приложения для виндоус ? Весь чат не читал...
Сейчас пишу на Java.
Интересно... а есть ещё что-нибудь подобное ? А может быть даже лучше ?

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

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

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

подобное java?
.net же

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

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

Подробнее>>

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

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

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

проблема в том, что в VCL главный поток отвечает за все окна приложения...

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

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

Подробнее>>

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

проблема в том, что VCL однопоточная: все формы рисуются в одном потоке. данные-то я принимаю в отдельном потоке, но он "невизуальный". а вот когда до визуальности дело доходит, тогда и проблема всплывает...

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

среда-программа CodeTyphon, freepascal. но основа - библиотека VCL, которую Borland в своё время придумала в Delphi/CBuilder

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

Другие есть
Bgr controls к примеру

есть-то, может, и есть, да не получается съесть... уж лучше костылить на том, что уже освоено, чем с нуля осваивать новое бесконечно
просто нет идей, как скостылить...

Покажи хоть скриншот форм
Может там и костылить ненадо

Но если компонент тратит времени слишком много, то в итоге очередь забьётся перерисовкой, и ничего путного не выйдет.
Создать свой компонент.

так вот же ж: https://radiokot.ru/forum/viewtopic.php ... 7#p3779927
дело не столько в том, что он тратит много, как в том, что второе окно в этот момент не обновляется. когда мы знаем, что в окнах выводятся одни и те же данные, мы ждем, что и появление их будет одновременным в обоих окнах. но если в одном окне мы выводим 'abc' (три символа), а во втором - их HEX-коды с пробелами, это по определению займет разные ресурсы... а если в одном коне выводим шрифтом по умолчанию, а в другом - жирным красным, то и подавно.

а что забьется, так не страшно, если забиваться будет ОДНОВРЕМЕННО в обоих, а не как сейчас вразнобой.

да, но если бы он отрисовался быстро, и другое быстро, то глаз бы не заметил.
А вразнобой оно будет обязательно. Пока не отрисуется одно окно, управление другому не будет передано.

я правильно понимаю, что проблема - это на скриншотах "Привет, радиокот " и на другом окне вариант c HEX? Подобное не должно тормозить.

а опция двойной буферизации не влияет как-нибудь?

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

Добавлено after 40 seconds:
особенно плохо, когда начинается скроллинг длинного текста... в каждом окне он по-своему идет... фу, короче

В винде доступен (если речь о WinAPI или библиотеках базирующихся на нем).

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

Вам шашечки или ехать?
Естественно чем больше "красивостей" тем больше нагрузка. Решите что для вам имеет больший приоритет.

Не заметил там "красивостей" разве что кроме возможности перетаскивать контейнеры с контролами. Остальное все уровня WinAPI.

Мурик, через invoke? но это лишь поставит в очередь перерисовки. И вызов на перерисовку двух разных контролов из двух разных потоков разве не сформирует всё рано одну очередь на отрисовку? Мне кажется, да.

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

Как вариант
Если уж не хочешь менять компоненты разбивать вывод на блоки и после каждого блока давать отрисовать application.processmessages()
Программа станет объективно медленнее, а субъективно быстрее
А вообще конечно надо бы на код взглянуть. Помнится писал я одну программу для обработки текстов и долго искал чеж она так тупит.
Оказалось слишком долго выделяется память при работе со строками.Путем нехитрых манипуляций с заменой динамических строк на статические массивы я повысил быстродействие на пару порядков

я же указал библиотеку, которой пользуюсь
не факт, но как вариант. вопрос в том, как это сделать в VCL
оба
бывает
возможно. поэтому я и спрашивал совета, как это сделать получше.
даже не представляю, как в паскале можно заменить string на array и не потерять функциональность. имхо, это даст не выигрыш, а проигрыш, т.к. придется переписывать 99% функционала, которй сейчас "из коробки". тогда уж проще на голом WinAPI париться...