forum.clarionlife.net

Ну да, самый простой и самый надёжный путь -> шаблон.

Губин Игорь писал(а): 18 Ноябрь 2019, 10:54но разве keycode() как-то должен реагировать?!
Он же отрабатывает в активном окне!

Это кто вам такое сказал???

vic7tar писал(а): 18 Ноябрь 2019, 15:46Ловить нажатие клавиш в другом потоке - тупик

поток - тотже самый.

ЕЩЕ раз - в 6 версии все работает.... В 10 - почему-то нет.

Я не поленился и проверил. Keycode() в idle в С6 изредка срабатывает. Это скорее баг, поскольку по логике вещей keycode() используется в связке с accept активного окна.
Можно провести простой тест. В idle процедуре ставим:
if keycode()<>0
stop(keycode())
setkeycode(0)
.
Потом открывает дочернее окно фрейма и вводим что-то в поле ввода, жмем tab. Наша конструкция в idle не срабатывает.

Кстати, а чем шаблон поможет? Все равно придется либо вешать таймер, либо сабклассить. Что в контексте MDI приложения совсем не кошерно делать для всех окон. А могут быть и фоновые процессы запущены. Когда лет 15 назад я разрабатывал себе фреймворк, то пришел к мнению, что обеспечивать блокировку на уровне приложения не есть корректно. Для этого существует блокировка на уровне винды.
Единственное, где такой функционал реализован - это кассовая программа. Там ситуация специфичная - окон мало, приложение SDI, у пользователя нестандартная pos клавиатура с ограниченным набором клавиш, действия которых надо настраивать в программе, выход в винду закрыт паролем, завершение работы с программой приводит к выключению компьютера, а после включения компьютера сразу залетаем в программу.

1. Проверял на программе, где на экране только кнопки и текст. KeyCode() стабильно равно 1, хотя я активно редактировал данные.
2. Попробовал переключиться на верхнее MDI-окно SetTarget( , SYSTEM{Prop:Active } ), KeyBoard() никак не меняется,
но можно проверить, например, заголовок 0{ Prop:Text } и собрать инфу о полях через Prop:ScreenText, примерно так
У меня значение переменной S изменяется при вводе текста ( и, само собой, при смене текущего окна). Но, возможно, у меня окна такие, надо проверять...

3. MouseX() и MouseY() - изменяются...

finsoftrz писал(а): 19 Ноябрь 2019, 10:16Кстати, а чем шаблон поможет?

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

finsoftrz писал(а): 19 Ноябрь 2019, 10:16 Кстати, а чем шаблон поможет? Все равно придется либо вешать таймер, либо сабклассить. Что в контексте MDI приложения совсем не кошерно делать для всех окон. А могут быть и фоновые процессы запущены.

Конечно, не кошерно! Поэтому и костыль с idle процедурой. А как вам вот такой вариант. Из дочерних окон генерить какое-нибудь пользовательское событие во фрейме. А во фрейме уже всё отрабатывать.

kreator писал(а): 19 Ноябрь 2019, 11:56Из дочерних окон генерить какое-нибудь пользовательское событие во фрейме

Большое красивое окно "Отправлять данные в налоговую? Да/Нет"
Можно ещё мееееедленно проявляющееся фото Нормы Джин Мортенсон в пикантном виде...


По идее - вешаем на все поля ввода IMM и получаем событие по любому изменению. Ну и таймер. Если, скажем, за 10 секунд не обновился счётчик - пользователь уснул. Реализация в шаблоне - дело пары часов с отладкой. Можно, наверное, даже и IMM шаблоном вешать

Губин Игорь писал(а): 19 Ноябрь 2019, 11:37

finsoftrz писал(а): 19 Ноябрь 2019, 10:16Кстати, а чем шаблон поможет?

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

Я не про это. Что будет этот шаблон размещать в оконных процедурах? Там все равно в accept упрешься. Если не сабклассить и не вешать таймер. Даже в этом случае не все гладко будет, так как клавиатурный буфер еще чистить надо не понятно в каких ситуациях. Я хочу сказать, что сам подход с использованием keycode() для определения активности пользователя в mdi не корректен. В то время, как задача решается с пол пинка на уровне винды.

finsoftrz писал(а): 19 Ноябрь 2019, 12:17Там все равно в accept упрешься.

И что? Шаблон тем и хорош, что может, практически, всё. А остальное - дело алгоритма. Тут напредлагали массу всего. Пусть думает

Губин Игорь писал(а): 19 Ноябрь 2019, 12:21

finsoftrz писал(а): 19 Ноябрь 2019, 12:17Там все равно в accept упрешься.

И что? Шаблон тем и хорош, что может, практически, всё. А остальное - дело алгоритма. Тут напредлагали массу всего. Пусть думает

Выражаясь шахматной терминологией, в таких случаях надо вначале оценить позицию, а уж потом намечать ходы-кандидаты. То есть вся эта тема концептуально сомнительная. Блокировать отдельное mdi приложение, а нафига? Определять бездействие пользователя нужно на уровне ОС. И блокировать доступ к компьютеру, а не к отдельному запущенному приложению. Мне кажется, это очевидно. Поэтому обсуждение данной темы из разряда "скучно, почему бы не поболтать".

А кто-то говорил про блокирование? У меня, например, выход из окна. Ещё, например, заказчик просит, чтобы был автоматический выход из программы при неактивности пользователя. Мы пока отбиваемся, т.к. это он (заказчик) хочет на лицензиях сэкономить.

Губин Игорь писал(а): 19 Ноябрь 2019, 12:12 По идее - вешаем на все поля ввода IMM и получаем событие по любому изменению. Ну и таймер. Если, скажем, за 10 секунд не обновился счётчик - пользователь уснул. Реализация в шаблоне - дело пары часов с отладкой. Можно, наверное, даже и IMM шаблоном вешать

IMM даже не нужно, если только на большие контролы ТЕКСТ. Проверять в акцепте ивенты и всё. А вот с мышкой без таймера не обойтись, наверно.

kreator писал(а): 19 Ноябрь 2019, 14:21А кто-то говорил про блокирование? У меня, например, выход из окна. Ещё, например, заказчик просит, чтобы был автоматический выход из программы при неактивности пользователя. Мы пока отбиваемся, т.к. это он (заказчик) хочет на лицензиях сэкономить.

И как он это себе представляет? У пользователя могут быть открыты разные отчеты в разных нитях. Взять и вырубить все, пусть потом заново формирует?
Тогда уж надо изменять логику работы приложения, чтобы оно не держало постоянного подключения к серверу.

kreator писал(а): 19 Ноябрь 2019, 14:21 IMM даже не нужно, если только на большие контролы ТЕКСТ. Проверять в акцепте ивенты и всё. А вот с мышкой без таймера не обойтись, наверно.

Не все действия пользователя сопровождаются генерацией эвентов.