Выход из обработчика onclick

Добрый день! У меня есть примерно такой код в С++ builder:
как внутри бесконечного цикла организовать проверку нажатия кнопки на клавиатуре, по результатам которой будет происходить выход из цикла? Заранее спасибо.

0

Сообщение от Avazart Evg, Я чет не пойму это к чему это ты ...

Вариант с ProcessMessages - это попытка лёгкого исправления ситуации, содержащая подводные камни. Точно так же, как вариант с Lock/Unlock кажется лёгким, но на поверку оказывается содержащим подводные камни. Если взять пример из поста Анимация ожидания, запустить, во время исполнения таскать мышкой программу за заголовок, то программа подвисает, потому что где-то что-то не учли, а где и что - хз

Твою программу по ссылке запустить не могу - требует rtl170.bpl

0

Сообщение от Evg Если взять пример из поста Анимация ожидания, запустить, во время исполнения таскать мышкой программу за заголовок, то программа подвисает

Странно у меня вроде не подвисает, т.е программа не падает совсем.

Сообщение от Evg потому что где-то что-то не учли, а где и что - хз

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

Интерфейс конечно может кратковременно не отвечать, но это нормально и ожидаемо..
То что делается с применением Lock/Unlock, имеет тот же эффект что делать эти действия в основном потоке, ибо канва разделяемый ресурс и тут никак иначе.

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

Так же как с применением ProcessMessages() чередуются действия выполняемые в цикле с обработкой сообщений клавиатуры ( идр ).

Кстати можно таким же образом использовать TTimer.

Добавлено через 7 минут
Возникает вопрос когда же будет выигрыш при использовании потока ?

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

0

Сообщение от Evg Твою программу по ссылке запустить не могу - требует rtl170.bpl

Вот пересобрал

Вложения

TThread Рисование на канве.rar (1.05 Мб, 9 просмотров)

1

Сообщение от Avazart Странно у меня вроде не подвисает, т.е программа не падает совсем

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

Сообщение от Avazart Ну не особо приглядывался к тому коду, могу лишь сказать что синхронизировано не все обращения к канве. Поэтому конечно может падать, но это происходит не всегда поэтому не всегда сразу обнаруживается

А потому намного проще сразу построить механизм взаимодействия потоков и главного процесса, сразу пересадить на него все потоки и потом жить спокойно, а не сидеть на пороховой бочке и не гадать, где чего забыли сделать

Сообщение от Avazart Интерфейс конечно может кратковременно не отвечать, но это нормально и ожидаемо..

А вот когда в момент подвисания окно программы нельзя ни свернуть, ни передвинуть - это не нормально

Сообщение от Avazart з чего следует как и писал MikeSoft, выигрыша в производительности при этом нет никакого. Единственный смысл уменьшение подвисаний, и возможность чередовать некоторые действия

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

Сообщение от Avazart Вот пересобрал

Дома запущу

0

0

Сообщение от Yurik7272 Добрый день! У меня есть примерно такой код в С++ builder: C++ 1 2 3 4 5 6 7 8 9 10 void __fastcall TForm1::Button1Click(TObject *Sender) {        while(1)      {       //тело цикла            }   } как внутри бесконечного цикла организовать проверку нажатия кнопки на клавиатуре, по результатам которой будет происходить выход из цикла? Заранее спасибо.

И без мороки.

0

Сообщение от Evg Ну ты же сам понимаешь, что программа с неинициализированными данными у кого-то будет работать, у кого-то падать. Если у кого-то программа подвисает (точнее, подвисал счётчик, а не программа), значит программа содержит ошибку. Которая ещё и плохо воспроизводится. Значит в программе что-то не так

Если программа не падает, а все же продолжает отвечать, то это проблема не синхронизации...

И я не уверенно правильно говорить что это вообще проблема вне контекста.
Все зависит от требований к программе...

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

Но к примеру 5 секунд это вполне нормально, если к примеру поток выигрывает 30 минут при расчетах, а 5 сек тратятся на вывод этих данных, почему нет ?

Не каждые же 5 секунд пользователь дергает окно программы как будто у него мышка сбесилась.

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

Сообщение от Evg Я вопросы про создание потоков с целью борьбы с заморозкой gui много раз уже на форуме задавал. Почему-то мне все пытаются доказать, что выигрыша в производительности не будет, хотя я этого не жду и вообще об этом не заикаюсь.

Ну опять же зависит от контекста, к примеру рисовать можно ( или скорее всего нужно ) в основном потоке
в событии OnPaint.
Зачем тут поток если нет выигрыша ?

Поток нужен там где можно выиграть, в том числе в том что бы дать больше времени на работу цикла обработки событий.

Сообщение от Evg Может, потому что замораживание программы люди считают чем-то само собой разумеющимся и неизбежным.

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

0

Tarasichok, ты считаешь. что return - это ответ на вопрос

Сообщение от Tarasichok как внутри бесконечного цикла организовать проверку нажатия кнопки на клавиатуре

???

0

Сообщение от Tarasichok И без мороки.

Сообщение от Lelik-pahan Tarasichok, ты считаешь. что return - это ответ на вопрос

Краткость - сестра дилетанта.

0

Сообщение от Avazart И я не уверенно правильно говорить что это вообще проблема вне контекста

Если ты о программе MikeSoft, то его программа был демонстрационный пример, как можно из потока обращаться к VCL-элементу. И эта демонстрация работает не правильно (не так, как автор задумал)

Сообщение от Avazart Но к примеру 5 секунд это вполне нормально, если к примеру поток выигрывает 30 минут при расчетах, а 5 сек тратятся на вывод этих данных, почему нет ?

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

Сообщение от Avazart Зачем тут поток если нет выигрыша ?

Выигрыш в том, что программа не тупит. А затраты на это не такие уж и большие

Сообщение от Avazart По тому что в определенных задачах GUI отступает на последний план по сравнению общей производительностью. К примеру серверу он совсем не нужен, лучше пусть лог-файл ведет, что бы синхронизация c GUI не давала проигрыш в производительности

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

0

Ну я как бы стараюсь хоть как-то поддерживать тему ТС :

Сообщение от Yurik7272 как внутри бесконечного цикла организовать проверку нажатия кнопки на клавиатуре, по результатам которой будет происходить выход из цикла? Заранее спасибо.

Ибо не известно что у него делается в цикле
Добавлено через 2 минуты

Сообщение от Evg Я всегда чётко оговаривал, что поток создаётся ради того, чтобы GUI не тупил на долгих операциях. Вообще такая реакция может говорить о двух вещах. Для этих целей используют не потоки, а что-то другое, все об этом знаю, но молчат как партизаны. Либо люди об этом не задумываются и им пофигу на то, что пользователя такое поведение программы раздражает или, чего доброго, вводит в ступор

Что-то другое это что ?

Как бы других инструментов нет, да и по сути не нужны, главное правильно распорядится существующими.

0

Сообщение от Avazart Ибо не известно что у него делается в цикле

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

Сообщение от Avazart Что-то другое это что ?

Я не знаю Просто так получилось, что я всю жизнь занимался консольными программами. GUI'вых программ я написал всего две. И при всём том у меня было стойкое мнение, что замороженный интерфейс - это вовсе не фича, а лень или незнание программиста

Сообщение от Avazart главное правильно распорядится существующими

Ну вот об том речь и идёт. В качестве одного из инструментов было предъявлено ProcessMessages. Но тут мы вроде бы с тобой сходимся во мнении, что это не лекарство, а затычка. Пример от MikeSoft я привёл как демонстрацию того, что технически лёгкие способы решения оказываются не такими уж и правильными.

0

Сообщение от Evg Я не знаю Просто так получилось, что я всю жизнь занимался консольными программами. GUI'вых программ я написал всего две. И при всём том у меня было стойкое мнение, что замороженный интерфейс - это вовсе не фича, а лень или незнание программиста

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

Единственно отличие - большее количество и более сложные разделяемые ресурсы.

0

Сообщение от Avazart Ровным счетом не чем

Неправда. Консольная программа запускается в условно однозадачном терминале. Т.е. пока программа работает, пользователь от неё больше ничего и не ждёт (потому что пользователю некуда нажать). В то время как графическое окно имеет кнопочки, окно можно перетащить, свернуть-развернуть-максимизировать и т.п. Пока у тебя программа качает данные из инета, ты имеешь возможность залезть в опции, во встроенный help или что-то ещё. А в консольной программе этого всего нет и логика консольной программы всего этого не предусматривает

Добавлено через 13 минут
Посмотрел твой пример. Это те же самые Lock/Unlock, но в таком простейшем случае всё чётко и железно работает. Правда такая программа уже несколько выходит за рамки типового GUI-приложения (т.к. в ней много динамики). Тем не менее, наконец воочию увидел работающую программу с Lock/Unlock. Вариант от MikeSoft по своей сути отличается несильно, но тем не менее глючит. Как вариант, есть какие-то хитрости и тонкости при работе с этими штуками. В своё время у меня так же не получилось надёжно задействовать Lock/Unlock и я просто забил на них, потому что непонятно было, как искать причину проблемы

0

Консольная программа запускается в условно однозадачном терминале.

Никто не мешает делать многопоточную консоль: с меню, с одновременным выполнением нескольких операций итп.

С другой стороны GUI может оповещать пользователя что необходимо ждать: изменением вида курсора, видом окна итп.

Так что это вопрос предусмотрено / не предусмотрено.

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

- опять же все определятся требованиями к программе.

Добавлено через 8 минут

Посмотрел твой пример. Это те же самые Lock/Unlock

Ну там как я помню еще вариант закоментированый с Synchronyze() за него не буду говорить ибо не уверен в том как он реализован.

А синхронизация с блокированием ресурса в Builder внешне выглядит также. как в Qt или boost.

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

0

Сообщение от Avazart Никто не мешает делать многопоточную консоль: с меню, с одновременным выполнением нескольких операций итп

Это совсем другой класс приложений. Это те же самые Gui-приложения, только вместо графики используется текстовая консоль.

Сообщение от Avazart С другой стороны GUI может оповещать пользователя что необходимо ждать: изменением вида курсора, видом окна итп

Проблема не в том, чтобы оповещать или нет, а в том, что у тебя программа никак не будет реагировать на внешние воздействия. Запустил ты свой браузер, он долго скачивает страницу. Переключился на другое приложение, потом вернулся опять к браузеру. А там - белый экран, потому что программа заморозилась. В итоге нет новой страницы, т.к. она ещё не скачалась, но уже и старая не отображается, потому что событие прорисовки позвать некому. Это явно не фича, а недоработка

Сообщение от Avazart К примеру иногда лучше организовать линейную прозрачную, предсказуемую и стабильно работающую программу нежели городить потоки и получать неизвестно что, ибо потоки это всегда дополнительные сложности

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

Сообщение от Avazart - опять же все определятся требованиями к программе.

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

Добавлено через 1 минуту

Сообщение от Avazart так же можно использовать обмен сообщениями, что иногда куда более выгоднее в плане эффективности

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

0

Сообщение от Evg Это совсем другой класс приложений. Это те же самые Gui-приложения, только вместо графики используется текстовая консоль.

Да тут только разница однопоточная / многопоточная.

Собственно задача многопоточности получить выигрыш во времени и/или перераспределить нагрузку ( что в глобальном смысле одно и тоже)

Сообщение от Evg Проблема не в том, чтобы оповещать или нет, а в том, что у тебя программа никак не будет реагировать на внешние воздействия. Запустил ты свой браузер, он долго скачивает страницу. Переключился на другое приложение, потом вернулся опять к браузеру. А там - белый экран, потому что программа заморозилась. В итоге нет новой страницы, т.к. она ещё не скачалась, но уже и старая не отображается, потому что событие прорисовки позвать некому. Это явно не фича, а недоработка

К браузеру с свои требования ...

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

Сообщение от Evg И желанием программиста. Некоторые делают по человечески, а некоторые - как получится.

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

0

Огромное спасибо всем за помощь, проблема решилась с помощью ProcessMessages, а с многопотоковостью мне пока трудновато.

0

Сообщение от Yurik7272 как внутри бесконечного цикла организовать проверку нажатия кнопки на клавиатуре, по результатам которой будет происходить выход из цикла? Заранее спасибо.

Я примерно вот так делаю во всех своих проектах.

1

maritux, keepitsimple3, еще раз увижу нечто подобное - пойдете отдыхать надолго.

Тема почищена.

1