Таймер и поток

← →
Rouse_ © (2015-03-10 19:45) [40]

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

← →
Кто б сомневался © (2015-03-10 20:00) [41]

Я чет ЦВС расшифровать не могу :)

← →
Кто б сомневался © (2015-03-10 20:01) [42]

ЦОС - могу, а ЦВС ...?

← →
Rouse_ © (2015-03-10 20:06) [43]

Семен-Семеныч :)
Цикл Выборки Сообщений

← →
Дмитрий С © (2015-03-10 22:10) [44]

Сань, можно пример работы setTimer без цвс? Поток займи, например, sleep-ом? Я с ходу написал - калбек не вызывается.

← →
Кто б сомневался © (2015-03-10 22:17) [45]

> Дмитрий С © (10.03.15 22:10) [44]

Дык в SetTimer можно колбэк фукнцию указать

lpTimerFunc [in, optional]

Type: TIMERPROC

A pointer to the function to be notified when the time-out value elapses. For more information about the function, see TimerProc. If lpTimerFunc is NULL, the system posts a WM_TIMER message to the application queue. The hwnd member of the message"s MSG structure contains the value of the hWnd parameter.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms644906(v=vs.85).aspx

← →
Дмитрий С © (2015-03-10 22:52) [46]

Так а кто это калбэк вызовет? Он как раз и вызывается одной из функцией цвс. Нет?
А иначе получится либо ещё один поток, либо прерывание.

← →
Кто б сомневался © (2015-03-10 23:02) [47]

> Он как раз и вызывается одной из функцией цвс. Нет?

Ну да.
WM_TIMER и колбэк вызывается в GetMessage и PeekMessage.

When you specify a TimerProc callback function, the default window procedure calls the callback function when it processes WM_TIMER. Therefore, you need to dispatch messages in the calling thread, even when you use TimerProc instead of processing WM_TIMER.

← →
Rouse_ © (2015-03-10 23:04) [48]

Давай угадаю, ты вызвал в execute, после чего нить завершилась?

← →
Rouse_ © (2015-03-10 23:20) [49]

Дам намек, в сервисах окон и цвс нет, таймеры есть ;)

← →
Eraser © (2015-03-11 04:35) [50]

> Кто б сомневался © (09.03.15 02:35)

посмотри как сделаны TJvTimer и TJvThreadTimer из JEDI VCL, но или вообще их и используй.

← →
Кто б сомневался © (2015-03-11 15:04) [51]

> Eraser © (11.03.15 04:35) [50]

Спасибо. Надо глянуть.
DVM тоже спасибо.
И вообще всем спасибо за помощь. Всем лучи добра! :)

Решил все таки через sleep. Т.к. там еще будет учитываться время работы кода + таймер.
Оптимальный вариант как с точки зрения производительности так и для чтения кода программистом - последнее время я на это часто обращаю внимание - т.к. много времени уходит на разбор чужого запутанного кода.
Причем народ умудряется совершенно банальные вещи запутывать. Типа передавать что-то через события в местах, где лучше использовать сообщения или ссылку на метод через стэк. В итоге из за вложенности ненаследованных классов одно и то же событие передается через 6-7 классов цепочкой через класс ядра и в каждом классе дублируется OnEventBlablabla и путаешься откуда что идет.

← →
Кто б сомневался © (2015-03-11 15:45) [52]

> Eraser © (11.03.15 04:35) [50]
>
>
> > Кто б сомневался © (09.03.15 02:35)
>
> посмотри как сделаны TJvTimer и TJvThreadTimer из JEDI VCL,
> но или вообще их и используй.

Ниче интересного.
Там тоже sleep используют. Наследуют от TThread + sleep (причем без timeBeginPeriod) + Synchronize. А TJvTimer это обычный TTimer почти точь в точь.

← →
DVM © (2015-03-11 22:56) [53]

Вот, кстати, вспомнил давнишнюю статью про таймеры:

http://www.delphikingdom.com/asp/viewitem.asp?catalogID=434

← →
Дмитрий Белькевич © (2015-03-12 22:16) [54]

>посмотри как сделаны TJvTimer и TJvThreadTimer из JEDI VCL, но или вообще их и используй.

могу кинуть свою реализацию таймера. работает с помощью FEvent.WaitFor(FInterval);

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

← →
Дмитрий Белькевич © (2015-03-12 22:17) [55]

перепробовал с пяток сторонних, в конце концов плюнул - сам написал (впрочем, как часто и бывает :) )

← →
Кто б сомневался © (2015-03-15 16:55) [56]

> из фич - работает в параллельном потоке сам и может вызывать
> параллельный поток,

Мне не нравиться идея что таймер создает отдельный поток. Это слишком затратно.
+ Имхо вообще лучше код не привязывать к конкретному классу потока, это только путает, а делать напр. так:

TWorkThread.RunInThread(DoSmthThread, DoOnTerminate);

← →
Кто б сомневался © (2015-03-15 16:57) [57]

class procedure TWorkThread.RunInThread(aProc: TProc; const aOnTerminate: TNotifyEvent = nil); begin with TWorkThread.Create(true) do begin FreeOnTerminate := true; fProc := aProc; OnTerminate := aOnTerminate; Start; end; end;

> Кто б сомневался © (15.03.15 16:57) [57]

> class procedure TWorkThread.RunInThread(aProc:

Напр. так делать не надо, бо есть конструкторы (вирт.)

--
Regards, LVT.

> Leonid Troyanovsky © (17.03.15 10:47) [58]
>
>
> > Кто б сомневался © (15.03.15 16:57) [57]
>
> > class procedure TWorkThread.RunInThread(aProc:
>
> Напр. так делать не надо, бо есть конструкторы (вирт.)

Не понял, какие конструкторы?
И как они пересекаются со статичной процедурой в этом случае?

Это все делается для того, чтобы человеку (а не компилятору) было проще.
Вообще я даже формы так вызываю - TMyForm.ShowModal - и на выходе результат. Всего одна строчка, а вся реализация в модуле формы.
Очень удобно, а главное не запутывает.

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

> TMyForm.ShowModal -

Поправочка:

* TMyForm.ShowMyForm

> Кто б сомневался © (15.03.15 16:55) [56]
>
>
> > из фич - работает в параллельном потоке сам и может вызывать
> > параллельный поток,
>
>
> Мне не нравиться идея что таймер создает отдельный поток.
> Это слишком затратно.
> + Имхо вообще лучше код не привязывать к конкретному классу
> потока, это только путает, а делать напр. так:
>
> TWorkThread.RunInThread(DoSmthThread, DoOnTerminate);

Есть же TThread.CreateAnonymousThread() или даже TTask.Run()

> Кто б сомневался © (17.03.15 15:19) [59]

> Это все делается для того, чтобы человеку (а не компилятору)
> было проще.Вообще я даже формы так вызываю - TMyForm.ShowModal
> - и на выходе результат. Всего одна строчка, а вся реализация
> в модуле формы. Очень удобно, а главное не запутывает.

Надо повесить на стену (на ^J) шаблон:
with TMyForm.Create(nil) do try .. ShowModal; finally Free; end;
Очень удобно и не запутывает.

--
Regards, LVT.

> Очень удобно и не запутывает.

Запутывать он будет когда смешается с другим кодом. Плюс пройдет пару лет.
Это ж очевидно: много текста = больше времени на его чтение. Меньше текста = меньше времени.

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

Много по малу = много.

Да и логичней это как то - когда код для работы формы написан в модуле этой формы.

> Кто б сомневался © (17.03.15 18:12) [63]

> и вы частенько будете на него попадать при чтении и разработке
> проекта, так почему бы его не спрятать?

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

> Да и логичней это как то - когда код для работы формы
> написан в модуле этой формы.

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

--
Regards, LVT.

Таймер и поток Найти похожие ветки