На чем писать приложения для виндоус

[74LS00]

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

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

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

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

[Мурик]

Суть в том что под винду есть некий жёсткий WinAPI и это объединяет все софтины.
Суть в том что ниодин язык программирования его не умеет.

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

Мне хватает Autoit, там все эти кнопочки есть.

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

В винде есть 2 типа прог, консольные и оконные.

Забыли про службы, дрова, различные библиотеки (DLL, OCX) и т. д.

Оконные не умеют ничего выводить в консоль.

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

[roman.com]

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

[nds]

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

[ARV]

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

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

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

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

[BlackKilkennyCat]

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

[ARV]

многопоточность

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

[BlackKilkennyCat]

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

[ARV]

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

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

[nds]

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

[ARV]

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

[nds]

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

[BlackKilkennyCat]

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

[ARV]

Покажи хоть скриншот форм

так вот же ж: https://radiokot.ru/forum/viewtopic.php ... 7#p3779927

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

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

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

[BlackKilkennyCat]

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

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

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

[ARV]

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

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

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

[Мурик]

(тем более, что гуй всё равно из другого потока недоступен

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

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

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

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

так вот же ж: https://radiokot.ru/forum/viewtopic.php ... 7#p3779927

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

[BlackKilkennyCat]

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

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

[nds]

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

[ARV]

если речь о WinAPI или библиотеках базирующихся на нем

я же указал библиотеку, которой пользуюсь

Тогда будет асинхронно

не факт, но как вариант. вопрос в том, как это сделать в VCL

Вам шашечки или ехать?

оба

Не заметил

бывает

Имеет место быть непродуманность

возможно. поэтому я и спрашивал совета, как это сделать получше.

Путем нехитрых манипуляций с заменой динамических строк на статические массивы я повысил быстродействие на пару порядков

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