Замораживание таймера при нажатии мышью на скроллбаре

[Хакер]

Proxy
Почему ты думаешь, что в фотошопе нельзя сделать такие же выноски?

Рисую редактором, входящим в состав скриншоттера SnagIt.

[Proxy]

Можно-то можно, да вот только не слишком это удобно там.

[Хакер]

Смотря как делать. Я и там и туд делаю их одним и те же образом -- с помощью многоугольника.

[Proxy]

А готовых выносок как в мелкософт офисе нет нигде?

[Денис]

Ну, раз уж вы тут оффтопик развели, спрошу вдогонку: Чем SnagIt лучше PrtScr?
__________________

А готовых выносок как в мелкософт офисе нет нигде?

Сделай себе шаблоны в формате psd или png и юзай.

[Хакер]

Stop offtopic, people.

[Twister]

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

Ни куда они не ушли. Клава, мышь, некоторые другие устройства обслуживаются прерываниями. Еще стоит заглянуть в IDT и посмотреть - там куча заюзаных векторов. Многие из них постоянно используются как программистами, так и самой системой:
int 3
int 2Eh
int 2Dh
(эти можно юзать из ринг3).

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

[Хакер]

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

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

[Twister]

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

[Arkadia]

Что в данном случае принимать за таймер?

аппаратный таймер, производящий прерывания. То, что 20 лет назад называлось 1810ВИ54.

Ерунда. Если один таймер (т.е. внутри Timer1_Timer'а работает бесконечный цикл), то ничего кроме этого цикла в рамках потока вообще не работает.

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

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

По сути, у тебя происходит примерно следующее:

спасибо за картинку, изучаю.

Убрал из программы щедро расставленные doevents - всё заработало как надо: перемещения ползунка вызывают то, что и должны: индикацию функции от положения этого ползунка. Просто смысл работы - функцию надо читать по таймеру, поскольку она приходит снаружи компа, через DLLку принимающей железяки.

[arthur2]

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

Раз уж мой ник всплыл в этой теме - да, мой таймер (точнее - обычный апи-таймер) скорее всего тебе бы помог.

Хакер
А чтобы не появлялась "бесконечно растущая рекурсия", достаточно в процедуре тика объявить статический флаг, устанавливать его на входе и снимать на выходе. А если на входе флаг уже стоит (предыдущий тик ещё работает), выходить из процедуры сразу.

Странно, но мне казалось, что в той теме мы-таки сошлись во мнении? Или ты снова возражаешь?

[Хакер]

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

Это и есть вышеописанная КРБ. Если сделать КРБ, твой таймер ничем (для автора) не будет отличаться от VB-шного.

Да, ты хотел, чтобы отсчёт следующего тика был не таким, как у VB-шного, но автору плевать на осчёт следующего тика, -- у него проблемы с другим.

[arthur2]

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

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

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

[Хакер]

arthur2
Тебе неверное кажется. По крайне мере, тебе кажется, а для меня совершенно очевидно, что проблема не решится.

У автора код "зависает" внутри DoEvents и там спинится пока таскают ползунок. VB-шный таймер, который, сделан не на базе эфира, а на базе того же WinAPI-таймера, на время "зависания" не обрабатывает тики из-за КРБ.

Если ты сделаешь API-шный таймер...
... без КРБ — будет рекурсия, притом, последствия будут ещё более гадкими — скролбар, с очень большой вероятностью будет неадекватно себя вести. Т.е., даже возможно, что визуально он будет работать нормально, но события он будет выкидывать очень и очень странным образом.

... с КРБ — будет то же самое, что и сейчас со стандартным таймером.

[arthur2]

Но можно сделать КРБ "наизнанку" - если второй тик сработал, а первый ещё не закончился, прерывать не второй, а первый, подвешенный тик.

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

[Хакер]

Но можно сделать КРБ "наизнанку" - если второй тик сработал, а первый ещё не закончился, прерывать не второй, а первый, подвешенный тик.

Это полная чушь.

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

И первый не завершится, прока:
1) не завершится второй,
2) не вернёт выполнение в петлю в нутри SBProc,
3) потом та будет циклиться,
4) потом она верёт управление в DoEvent-ную петлю,
5) и только та вернёт управление в первый тик.
6) Тогда тогда первый тик завершится.

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

[arthur2]

И первый не завершится, прока не завершится второй

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

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

[Хакер]

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

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

Я твои красивые иллюзии разобью, сказав что:
Всё работает линейно и по принципу LIFO.

Обработчик второго тика запускается не из пустого места, а из цикла, который работает внутри WindowProc-а скроллбара. Это WindowProc скроллбара вызван из функции DispatchMessage. А она вызвана из цикла, работающего внутри DoEvents. А DoEvents вызван из обработчика первого тика.

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

Т.е.:

Код: Выделить всё

Sub A
    Call B
End Sub



Sub B
    ' А вот тут ты хочешь "завершить" работающую в этот момент процедуру A.
End Sub


Только у тебя не A и B — а один и тот же Timer1_Timer.

[arthur2]

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

Ну в общем, мне так казалось. Я вообще часто использую таймер именно затем, чтобы вызвать процедуру, но не возвращаться туда, откуда вызвал.

Попробовал набросать, что имел ввиду (но не проверил - сегодня не получится). Вышло что-то вроде этого:

Код: Выделить всё

Dim cntSomething As Long, flExit As Boolean

Private Sub iTimer_Tick(ByVal idTimer As Long, tmNow As Long)
Static flKRB As Boolean

If flKRB Then' если ещё обрабатывается предыдущий тик
  flKRB = False
  flExit = True
  Exit Sub
End If

flKRB = True
Do While cntSomething < 1000000000
   DoEvents
   If flExit Then flExit = False: Exit Sub
   Call DoSomething
   cntSomething = cntSomething + 1
Loop
flKRB = False

End Sub

Private Sub DoSomething()
  Dim s As String
  s = Space(100000) & Space(100000)
 
End Sub


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

[Хакер]

arthur2
Ты не понял что-ли смысл предыдущего сообщения? Иначе почему ты вместо "Да, я был не прав" пишешь какой-то код, сопровождания его словами "вроде, всё нормально"?

[arthur2]

Я не понял, почему цикл не прервётся по флагу, установленному из другой процедуры. Мне кажется, что прервётся. Реально он конечно же прервётся после того, как закончится второй тик, ну и что? Рекурсии-то не возникнет.

В любом случае, проверю только завтра.

[Arkadia]

Ну, в принципе у меня уже нормально работает. А тот фактор, что таймер начинает считать после end sub - даже наруку: этот интервал освобождает время на другие дела.
Единственное, что плохо - если обработка и индикация очень долго длятся (полсекунды - секунду), то другие действия тормозятся - doevents вствить нельзя...

Вопрос: у меня сейчас таймер (и кое-какая первичная быстрая обработка) отделены от основной программы - в activeX dll. Когда в таймере я принимаю пакет от девайса, я его проверяю и передаю в основную программу с помощью raise event. Может, мне посмотреть в сторону многопоточности?

[Хакер]

Я не понял, почему цикл не прервётся по флагу, установленному из другой процедуры.

Потому что он прервётся только когда ког, делающий это прерывание выполнится, а выполнится он только тогда, когда к нему возвратятся из DoEvents, а к нему никогда не возвратятся из DoEvents.

Рекурсии-то не возникнет.

Возникает, блин

[arthur2]

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

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

Код: Выделить всё

Private Sub ITimer_Tick(ByVal idTimer As Long, tmNow As Long)

flExit = Not flExit
If flExit Then Exit Sub

Do 'выход из цикла вообще только по флагу. И тем не менее, он всё время нормально срабатывает
   DoEvents
   If flExit Then
      Debug.Print "flExit " & cntSomething
      flExit = False: Exit Sub
   End If
   Call DoSomething
   cntSomething = cntSomething + 1' условно - оставляем информацию для следующего тика, до куда довычислялся предыдущий
   If cntSomething > 100000000 Then cntSomething = 1
Loop

End Sub

Private Sub DoSomething()
  Dim s As String
  s = Space(1000000) & Space(1000000)
End Sub


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

Код крутился часа полтора, и ни какого переполнения стека не наблюдалось.

[Хакер]

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

А лучше (чтобы не мучался) перерисуй блоксхему (мою картинку так), чтобы и таймер тикал и рекурсии небыло.

Сумеешь?

[arthur2]

Ты возьми первый пример автора, и переделай его так

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

Это именно что то, что хотел автор - цикл крутится ровно столько, сколько отведено на один тик (у автора там в цикле проверка именно на это). Не знаю, насколько маразматична моя задача, но она не "будет", а работает.

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

[Хакер]

Ну поставь вместо дебаг.принт смену цвета шейпа.

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

Ты сможешь сказать точно: куда делась рекурсия? Почему она не возникает? Я могу точно сказать, почему она должна возникать. Ты можешь с такой же твёрдостью сказать, почему у тебя рекурсия не возникает?

[arthur2]

Ты возьми первый пример автора, и переделай его так...

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

Я не предлагаю тебе переделывать пример. Это ты предложил мне переделать пример. А я просто сообщил, что именно это и сделал.

Ты сможешь сказать точно: куда делась рекурсия? Почему она не возникает? Я могу точно сказать, почему она должна возникать. Ты можешь с такой же твёрдостью сказать, почему у тебя рекурсия не возникает?

Без понятия. Но ведь не возникает!

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

Я давно использую таймеры, чтобы прерывать циклы. Выставить флаг из обычной процедуры, чтобы цикл его увидел - действительно не получится. А вот из таймера - запросто.
[/quote]

[Хакер]

Без понятия. Но ведь не возникает!

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

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

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

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

Ну чушь это. Не надо обожествлять таймеры.

[arthur2]

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

Вероятно, я недопонял вот это:

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

Ну чушь это. Не надо обожествлять таймеры.

Код: Выделить всё

Sub A
    Call B
End Sub


Sub B
    ' А вот тут ты хочешь "завершить" работающую в этот момент процедуру A.
End Sub

Я смогу её завершить - если в ней стоит проверка флага, а флаг установить таймером.