Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

ожидание выполнения процедуры [D7, XP]

nord © (2011-02-24 21:10:00)
Здравствуйте!
Как можно узнать выполнилась ли вызываемая процедура и ожидать пока она этого не сделает?
Просто в обычном варианте расчеты в процедуре не успевают полностью "просчитаться" и программа идет дальше по тексту, что нарушает ход работы...
Пробовал поставить флаг, но походу он тоже игнорится самими расчетами..

Спасибо

abb777 (2011-02-26 22:44:00) [1]
свои 2 коп позволю снбе вставить:

str:=str+chr(kk);

Так никогда не надо делать, если заранее известно, какой длины в конце концов будет строка. Как в данном случае.

Надо:

SetLength(str, length(memoLogg2.Text))
.................
str[i] := chr(kk);

А вылететь недоработав до конца, может только по исключению. Попробовать окружить вызов процедуры try...except и посмотреть, что будет. Хотя, откуда там исключения...

Anatoly Podgoretsky (2011-02-25 13:34:00) [2]
> KilkennyCat (25.02.2011 13:03:16) [16]

Пусть ждет когда включат, или пусть UPS купит, а не жалуется.

KilkennyCat (2011-02-25 13:03:00) [3]

> Anatoly Podgoretsky © (25.02.11 10:28) [15]

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

Anatoly Podgoretsky (2011-02-25 10:28:00) [4]
Приведеный текст не может выполниться не полностью.

nord (2011-02-24 23:22:00) [5]
понятно, спасибо)

Юрий Зотов (2011-02-24 23:12:00) [6]
> nord (24.02.11 21:10)

> Как можно узнать выполнилась ли вызываемая процедура и ожидать пока
> она этого не сделает?

Если не порождаются вторичные потоки, то ничего специального не требуется.
вызов_процедуры; следующая_строка_кода;
Когда начнет выполняться следующая_строка_кода, то это и будет означать, что выполнение процедуры полностью закончилось.

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

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

nord (2011-02-24 23:01:00) [7]
=)))))
ну простите)) программа не какая не ответственная - чисто пример для себя же.. шифрование чисто условное.. текст не предполагается большой - буквально один абзац.. в общем все чисто условное.. я согласен что код хреновый, да! цель на данном этапе минимальна, поэтому код не вылизывался.. а я просто спросил про возможную проблему в ожидании выполнения процедуры.. если и правда в этом проблемы быть не может, то спасибо, буду смотреть в других местах, хотя уже и так вроде все пересмотрено..

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

KilkennyCat (2011-02-24 22:58:00) [8]

> sniknik © (24.02.11 22:49) [10]

да, наверное. я вообще наошибался. неудобно читать, неформатно.

sniknik (2011-02-24 22:49:00) [9]
> str - лишняя.
да как сказать... скорее лишнее все остальное...

Игорь Шевченко (2011-02-24 22:37:00) [10]
шифровальщики недоделанные

Игорь Шевченко (2011-02-24 22:37:00) [11]
ужос

не прще ли взять строку и работать с ней, а не дергать каждый раз memo.text ? Или хотя бы представлять, что за этим вызовом стоит.

KilkennyCat (2011-02-24 22:23:00) [12]

> так как они есть гораздо хуже моего,

не в данном случае.

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

str - лишняя.

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

KilkennyCat (2011-02-24 22:19:00) [13]

> for i:=1 to do
> begin
> if i mod 2 =0

я бы заменил на
ln := length(memoLogg2.Text);
i := 0;
if ln > 2 then
repeat
inc(i,2)
.....
until ... i >= ln;

nord (2011-02-24 22:18:00) [14]
ну я так понимаю это зависит от производительности компьютера, а так как они есть гораздо хуже моего, хотелось бы обеспечить правильную работу, пусть и с задержкой, а то у меня так файл коряжиться...
над оптимизацией я согласен, надо поработать основательно, но все же хотелось бы исключить саму возможность неправильного просчета и вывода..

KilkennyCat (2011-02-24 22:14:00) [15]

> заметна задержка

ну еще бы:

> for i:=1 to length(memoLogg2.Text)

это:

> repeat
> if kk>255 then kk:=kk-255;
> if kk<1 then kk:=kk+255;
> until (kk>0)and(kk<256);

тоже упрощается.

nord (2011-02-24 22:03:00) [16]
в этой части программы происходит загрузка текстового файла, обработка его и запись обратно
обработка и осуществляется процедурой и представляет собой простейшую шифровку вида
str:=''; for i:=1 to length(memoLogg2.Text)do begin if i mod 2 =0 then kk:=ord(memoLogg2.text[i])+(i mod 7)*2 else kk:=ord(memoLogg2.text[i])+i mod 10; repeat if kk>255 then kk:=kk-255; if kk<1 then kk:=kk+255; until (kk>0)and(kk<256); str:=str+chr(kk); end; memoLogg.Text:=str;
и эта конструкция в коде не успевает полностью выполняться.. как-то глючно получается... стоит искать проблему в другом месте? просто если вместо этих преобразований записать просто не обработку, а копирование текста из одного мемо в другое:
memoLogg.Text:=memoLogg2.Text
то все идет без проблем, причем текст может быть внушительных размеров, тогда как при шифровании происходит сбой очень быстро...
сама функция шифрования верна, написана в отдельной программе для проверки и работает замечательно, разве что заметна задержка при большом объеме информации..

KilkennyCat (2011-02-24 21:16:00) [17]
вообще-то, управление программе передается по завершению вызванной процедуры, в точку вызова.

что-то не договариваешь.

Palladin (2011-02-24 21:15:00) [18]
Какие ваши доказательства?

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »