задержка

← →
Miko (2010-09-09 08:58) [0]

t=GetTickCount(); while (GetTickCount()-t<delay);
делаю таким образом нужную задержку, только вот программа дальше цикла не идёт, цикл получается бесконечным подскажите, что не так?

← →
И. Павел © (2010-09-09 09:01) [1]

У меня прекрасно идет дальше. Чему у вас delay равен? Может быть он слишком большой?
Поставьте после while например звуковой сигнал - может быть идет дальше, и зацикливается уже в другом месте?

← →
И. Павел © (2010-09-09 09:05) [2]

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

← →
Miko (2010-09-09 09:07) [3]

да нет, delay=25 , ну 25 миллисекунд задержка мне и нужна

← →
_Юрий (2010-09-09 09:09) [4]

Sleep(25);

← →
И. Павел © (2010-09-09 09:12) [5]

У меня вот это вперкрасно работает:

procedure TForm1.Button1Click(Sender: TObject); var t: Cardinal; delay: integer; begin t:=GetTickCount(); delay := 25; while GetTickCount()-t < delay do; Caption := "OK"; end;

Посмотрите в отладчике - какие значения имеют GetTickCount(), t, delay на каждой итерации. Лучше прямо считайте GetTickCount() в цикле, записывая его в отдельную прееменную и смотрите - чему он равен. А потом проходите while с этой переменной, и тоже анализируйте результат:

t=GetTickCount(); do { t2 = GetTickCount(); rez := t2-t<delay; } while (rez)

Чудес не бывает... Может быть у вас в цикле меняется значение для t. Может быть у вас t не cardinal (хотя не уверен, что меньший тип тут на что-то повлияет, разве что byte).

← →
Miko (2010-09-09 09:13) [6]

> Ну и еще есть один тонкий момент: кажется, GetTickCount
> может вернуть две одинаковые цифры, если долго не выключать
> систему

ребутнулся :) принудительно(спасибо ГорСвет - у) , не помогло

← →
Miko (2010-09-09 09:14) [7]

вообще я в си пишу длл-ку, потому отладку не пущу :(

← →
Дмитрий Тимохов (2010-09-09 10:22) [8]

Sleep(25) штука не очень адекватная примеру с tickcount.
скорее всего это будет много больше 25 мс, т.к. управление скорее всего будет отдано другому потоку.

я думаю, что с tickcount получится более точно отмерить 25 мс, хотя тоже не точно.

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

← →
Ega23 © (2010-09-09 10:35) [9]

> кажется, GetTickCount может вернуть две одинаковые цифры,
> если долго не выключать систему

Поскольку GetTickCount возвращает количество миллисекунд, прошедших со старта ОС в виде DWORD, то имеем
0xFFFFFFFF/1000/3600/24 = 49.7 (.....)
Т.е. через 49.7 суток значение GetTickCount дойдёт до 0xFFFFFFFF, после чего сбросится в ноль и начнёт расти заново.

← →
12 © (2010-09-09 10:45) [10]

http://habrahabr.ru/blogs/delphi/75234/

← →
Kerk © (2010-09-09 10:45) [11]

Для таких случаев придумали GetTickCount64

← →
Ega23 © (2010-09-09 11:00) [12]

> Для таких случаев придумали GetTickCount64

Всё авно не застрахован - через 585 миллионов лет опять сбросится. Нужно техническую перезагрузку делать будет.

← →
12 © (2010-09-09 11:11) [13]

> через 585 миллионов лет опять сбросится. Н

- .. и возможно вся Вселенная взорвется...
- !?!?!!!
- .. ну а возможно, не вся, а только наша галлактика...
- ну слава богу!

← →
И. Павел © (2010-09-09 11:12) [14]

> через 585 миллионов лет опять сбросится

Ну пусть жалуются. Только сначала им придется меня откопать :)

← →
Ega23 © (2010-09-09 11:14) [15]

> Ну пусть жалуются. Только сначала им придется меня откопать :)

Вот так вот и получается индусский код - ненадёжный и беспощадный.

← →
Anatoly Podgoretsky © (2010-09-09 11:16) [16]

> Miko (09.09.2010 08:58:00) [0]

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

← →
Anatoly Podgoretsky © (2010-09-09 11:16) [17]

> Ega23 (09.09.2010 11:00:12) [12]

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

← →
Miko (2010-09-09 11:25) [18]

к сожалению в моё случае, значение до сих пор одно и тоже :)
ныне попробую на VS2010.

← →
Miko (2010-09-09 11:34) [19]

> По заголовку темы я подумал, что речь про задержку месячных.

я думал что такой исход возможен))

← →
И. Павел © (2010-09-09 11:38) [20]

> Вот так вот и получается индусский код - ненадёжный и беспощадный.

За 585 миллионов лет существенное влияние на работу системы начнут оказывать ошибки, связанные с транзисторами и прочим железом. Индусы тут уже будут ни при чем.

← →
Anatoly Podgoretsky © (2010-09-09 12:26) [21]

> И. Павел (09.09.2010 11:38:20) [20]

Индусы всегда будут при деле, будут писать обходы. Обходы на обходы.

← →
Ega23 © (2010-09-09 12:34) [22]

> За 585 миллионов лет существенное влияние на работу системы
> начнут оказывать ошибки, связанные с транзисторами и прочим
> железом. Индусы тут уже будут ни при чем.

Это пустые отговорки.
Кое-кто тоже говорил, что 100 миллионов долларов - слишком большая цена за Microsoft

← →
LL (2010-09-09 14:13) [23]

> к сожалению в моё случае, значение до сих пор одно и тоже
> :)

А ты не стесняйся, приведи весь код. Ну и где определяешь переменную тоже.

← →
Miko (2010-09-09 14:39) [24]

void Play() { int delay; DWORD t1,t2; Ptr=fopen("1.vid","r"); while(fread(&delay,sizeof(BYTE),1,Ptr)==1) { //fread(&delay,sizeof(BYTE),1,Ptr); for(int i=0;i<1024*1024;i++) { fread(&image[i],sizeof(BYTE),1,Ptr); image[i]=image[i]+25; } play=true; UpdateImage(image); UpdateOverlay(); t1=GetTickCount(); t2=GetTickCount(); while ((t2-t1)<delay) t2=GetTickCount(); } play=false; fclose(Ptr); }

← →
Miko (2010-09-09 14:41) [25]

в общем как и говорил раньше за пределы while не выходит, даже если писать так, как писал выше

t1=GetTickCount(); while (GetTickCount()-t1<delay);

← →
Ega23 © (2010-09-09 14:45) [26]

А где инициализация delay?

← →
Anatoly Podgoretsky © (2010-09-09 15:28) [27]

> Miko (09.09.10 14:39) [24]

Это Си к Дельфи отношения не имеет

← →
И. Павел © (2010-09-09 15:29) [28]

> А где инициализация delay?

тут:
> fread(&delay,sizeof(BYTE),1,Ptr)

в итоге delay = код последнего байта в файле.

А вот что означает:

> t1=GetTickCount();
> t2=GetTickCount();
> while ((t2-t1)<delay)

Я так и не понял. Т.к. delay, t2 и t1 не меняются, то цршду либо не прйдет ни одной итерации, либо зациклится.

← →
И. Павел © (2010-09-09 15:29) [29]

цршду -> цикл

← →
И. Павел © (2010-09-09 15:34) [30]

> в итоге delay = код последнего байта в файле.

Оказывается, не последнего...

> fread(&image[i],sizeof(BYTE),1,Ptr);

> Miko

Попробуйте написать:

t1=GetTickCount(); t2=GetTickCount(); while ((t2-t1)<15)

А то уж больно delay мудрено считывается.

← →
Anatoly Podgoretsky © (2010-09-09 16:03) [31]

Попробуйте написать:

t1=GetTickCount(); t2=GetTickCount(); while ((t2-t1)<15)

Это бесконечный цикл, писать надо

while ((GetTickCount()-t1)<15)

Я что-то не догоняю.
fread(&delay,sizeof(BYTE),1,Ptr)
По адресу delay записать первые 255 байт из Ptr, так что-ли?

sizeof(BYTE) - это ищется, сколько байт занимает переменная типа byte. Т.е. 1 байт.

Хотя сомневаюсь, что byte когда-нибудь будет занимать другой размер :) Так что можно было просто поставить единицу.

А, не. Наврал.
Но тогда, судя по описанию, где обявление
FILE *Ptr; ?

В общем, есть подозрение, что в delay сидит мусор. Если старший байт ещё как-то инициализируется (хотя чему равен Ptr?), то что с остальными тремя - вообще

ВО!
А не может ли быть, что delay - отрицательное число? Оно же как int объявлено?

> И. Павел (09.09.2010 16:52:34) [34]

Можно, но идеологически неправильно.

← →
Miko (2010-09-10 07:08) [38]

да, замена delay на конастанту дала результат :)
удивительно, что если в delay был мусор, а эта переменная типа int, то выход из цикла должен был наблюдаться :)

← →
Miko (2010-09-10 07:25) [39]

зы ещё сменил дистрибутив с VS2005 на VS2010 :)

> удивительно, что если в delay был мусор, а эта переменная
> типа int, то выход из цикла должен был наблюдаться :)

Вот смотри. Ты в старший байт записал что-то. Например - 1. Но это - старший байт. Т.е. delay равен (даже если мы его предварительно нулями затёрли) 0x1000000. Или 16777216 в десятичной системе. Это - 4 часа.

← →
han_malign (2010-09-10 11:41) [41]

> fread(&delay,sizeof(BYTE),1,Ptr)

VS - в режиме отладки(с включенным режимом проверки инициализации - /RTCu) инициализирует память патерном 0xС6, соответственно после fread(...) - delay == 0xC6C6C619 - ждать 38 дней...
Не в отладке - как повезет - от 0 до 49 дней(шанс что проверка попадет в промежуток 0xFFFFFF19-0xFFFFFFFF = 231мс довольно большой), смотря что там в стеке было...

З.Ы. DLL прекрасно отлаживается если указать хост-приложение...

← →
han_malign (2010-09-10 11:45) [42]

> Но это - старший байт

- но это не Mac, мы с Intel принадлежим к лагерю остроконечников...

← →
6x8 (2010-09-10 12:15) [43]

> да нет, delay=25 , ну 25 миллисекунд задержка мне и нужна

25 так не получить, квантовка планировщика не даст.
http://www.rsdn.ru/forum/delphi/3950127.all.aspx

← →
Miko (2010-09-10 18:49) [44]

> 25 так не получить, квантовка планировщика не даст.

так придётся на разных машинах снова квантовку делать?

задержка Найти похожие ветки