Хм, задачка...

← →
Rouse_ © (2011-10-14 23:31) [0]

Сия задача была озвучена в Августе 2004-го года в парке, находящимся рядом с кинотеатром Пушкинский, на скамейке, где сидели два, похмеляющихся после тяжкой работы, тела - Зотыч и Розыч :)

... и навеяло данной веткой: http://delphimaster.net/view/2-1318507172/

Задача выглядит просто, есть два варианта кода:

procedure TForm1.Button1Click(Sender: TObject);
var
DC: HDC;
S: String;
begin
DC := Canvas.Handle;
S := Memo1.Lines[0];
TextOut(DC, 10, 10, PChar(S), Length(S));
end;

procedure TForm1.Button2Click(Sender: TObject);
var
DC: HDC;
S: String;
begin
S := Memo1.Lines[0];
DC := Canvas.Handle;
TextOut(DC, 10, 10, PChar(S), Length(S));
end;

Нужно определить, какой из них отработает не верно и почему.

← →
Бездомный (2011-10-14 23:36) [1]

DC := Canvas.Handle;
S := Memo1.Lines[0];

DC теперь недейстивтельный.

← →
Rouse_ © (2011-10-14 23:46) [2]

> Бездомный (14.10.11 23:36) [1]
> DC теперь недейстивтельный.

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

← →
Jeer © (2011-10-14 23:47) [3]

Другими словами - "слепок" с канвы действителен только до момента обращения к другим элементам на "канве".
Ибо он и был предназначен изначально лишь для целей вывода канвы на печать или в "изображение".

← →
Rouse_ © (2011-10-14 23:51) [4]

> Jeer © (14.10.11 23:47) [3]
>
> Другими словами - "слепок" с канвы действителен только до
> момента обращения к другим элементам на "канве".

Ответ не верный, наглядно это демонстрирует следующий код, где оба обработчика работают нормально:

procedure TForm1.Button1Click(Sender: TObject); var DC: HDC; S: String; begin DC := Canvas.Handle; S := Button1.Caption; TextOut(DC, 10, 10, PChar(S), Length(S)); end; procedure TForm1.Button2Click(Sender: TObject); var DC: HDC; S: String; begin S := Button2.Caption; DC := Canvas.Handle; TextOut(DC, 10, 10, PChar(S), Length(S)); end

← →
Jeer © (2011-10-14 23:52) [5]

Оба отработают верно, но каждый - в своем контексте.
Если о "наблюдении вывода" - то второй.

← →
Rouse_ © (2011-10-14 23:54) [6]

> Jeer © (14.10.11 23:52) [5]
>
> Оба отработают верно, но каждый - в своем контексте.
> Если о "наблюдении вывода" - то второй.

Переведи...

← →
Jeer © (2011-10-14 23:55) [7]

> Ответ не верный,

"Верность" - понятие относительное.
Батоны - надстройка.
Мемо - принадлежность канве.

← →
Jeer © (2011-10-14 23:57) [8]

Берем пэйнтбокс - это вообще часть канвы изначально, всего лишь crop ее части.

← →
Rouse_ © (2011-10-14 23:58) [9]

> Jeer © (14.10.11 23:55) [7]
>
>
> > Ответ не верный,
>
>
> "Верность" - понятие относительное.
> Батоны - надстройка.
> Мемо - принадлежность канве.

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

← →
Rouse_ © (2011-10-14 23:59) [10]

> Jeer © (14.10.11 23:57) [8]
>
> Берем пэйнтбокс - это вообще часть канвы изначально, всего
> лишь crop ее части.

Не ну это все понятно, а ответ то на вопрос будет?

← →
Jeer © (2011-10-15 00:02) [11]

:)
Ну как - кнопка же выше канвы :)
Отрисовка своими силами.

P.S.
Да ладно, не бери в разум - я тут изгаляюсь после свадьбы дочки :)

← →
Rouse_ © (2011-10-15 00:06) [12]

да я примерно так и понял - кстати еще раз поздравляю :)

ЗЫ: но ответ так и не дан пока что ни кем.

← →
Jeer © (2011-10-15 00:10) [13]

> ЗЫ: но ответ так и не дан пока что ни кем.

Ну так, использование мемо в данном примере принципиально же ?
Или подобных "вырезок" в канве ?

← →
Rouse_ © (2011-10-15 00:11) [14]

> Jeer © (15.10.11 00:10) [13]
> Ну так, использование мемо в данном примере принципиально
> же ?
> Или подобных "вырезок" в канве ?

Не принципиально, можно воспользоваться другими контролами...

← →
Германн © (2011-10-15 00:22) [15]

> Нужно определить, какой из них отработает не верно и почему.

Хм. Интересно будет в конце-концов узнать при чём тут современный ассемблер для Intel & AMD? Или не современный, а тот что Дельфийский компилятор использовал в 2004-м, когда вышеназванные опохмелялись "в парке, находящимся рядом с кинотеатром Пушкинский" :)

← →
Eraser © (2011-10-15 00:31) [16]

Удалено модератором

← →
Rouse_ © (2011-10-15 00:38) [17]

> Хм. Интересно будет в конце-концов узнать при чём тут современный
> ассемблер для Intel & AMD?

Ну если ты хочешь увидеть задачу по асму, то их есть у меня.
Данный код выводит строчку "Test" на консоль от одного до нескольких раз.
Задача - выяснить сколько раз и почему, без компиляции.
Впрочем "сколько" я думаю и так понятно - полюбому скомпилите, тогда вопрос - как?

program Project1; {$APPTYPE CONSOLE} uses SysUtils; procedure tst; begin writeln("Test"); end; begin asm call tst lea eax, tst lea ecx, @1 push ecx push eax push eax call eax ret @1: end; Readln; end.

← →
Eraser © (2011-10-15 00:38) [18]

Удалено модератором
Примечание: Бинго...

← →
Rouse_ © (2011-10-15 00:56) [19]

> Eraser © (15.10.11 00:38) [18]

Абсолютно верный детект ошибки - мои респекты...

← →
Rouse_ © (2011-10-15 01:16) [20]

> Eraser © (15.10.11 00:38) [18]

Вторую задачку с 17-го поста одолеешь?

← →
Бездомный (2011-10-15 01:17) [21]

Что за произвол?=))

← →
Rouse_ © (2011-10-15 01:21) [22]

> Бездомный (15.10.11 01:17) [21]
>
> Что за произвол?=))
>

В плане?

← →
Kerk © (2011-10-15 01:23) [23]

Три раза по-моему. Мог сбиться, поздно уже.
Суть в том, что ret на выходе из функции берет адрес возврата из стэка. Дальше сами считайте :)

← →
Rouse_ © (2011-10-15 01:27) [24]

> Kerk © (15.10.11 01:23) [23]

Почти верно и стэк правильно озвучил...

← →
Kerk © (2011-10-15 01:30) [25]

А, ну я call tst вначале прозевал :)
Про стэк - я ж в молодости вирусняками увлекался, там это азбука :)

← →
Rouse_ © (2011-10-15 01:33) [26]

> Kerk © (15.10.11 01:30) [25]
> А, ну я call tst вначале прозевал :)

Промахнулся :)
Там нюанс в изымании рет-калбэка вызываемой функцией, т.е. хинттрик на двойном RET-RET применяемом при переполнении стэка...

← →
Rouse_ © (2011-10-15 01:36) [27]

блин, хреновый из меня партизан :)

← →
Kerk © (2011-10-15 01:41) [28]

А разве этот ret вообще выполнится? Там же последний прыжок пойдет на ECX, который указывает на @1 после этого ret.

← →
Rouse_ © (2011-10-15 01:47) [29]

> Kerk © (15.10.11 01:41) [28]
>
> А разве этот ret вообще выполнится?

:)

← →
Kerk © (2011-10-15 01:49) [30]

А, прости, туплю. Ведь этот ret и запускает всю цепочку.
Пойду спать, чтоб еще глупостей не нагородить :)

← →
Rouse_ © (2011-10-15 01:59) [31]

Скажем инициирует, а не запускает - но вывод верный :)

← →
Бездомный (2011-10-15 03:06) [32]

call tst // 1 раз lea eax, tst lea ecx, @1 push ecx push eax // "стек1" push eax // "стек2" call eax // второй раз ret // тут заход на третий раз, а ret из tst сделает заход на 4 раз, т.к. будет думать что адрес возврата то, что в "стек1". ret из tst 4ого раза вернется на @1 @1:
правильно?

← →
Германн © (2011-10-15 03:07) [33]

> Ну если ты хочешь увидеть задачу по асму, то их есть у меня.

У меня тоже их есть. Только АСМ другой.
Вот думаю как 8-ми байтное число представить однозначно 13-ти значным десятичным числом. И понимаю что никак. :(

А куды тогда бедному крестьянину, пардон разработчику, податься? Если ему задали разработать преобразователь "микролан" -> штрихкод.

← →
Бездомный (2011-10-15 03:08) [34]

"стек1" и "стек2" надо местами поменять =)

← →
Kerk © (2011-10-15 03:13) [35]

> Бездомный (15.10.11 03:06) [32]

У меня так и получается, но Розыч говорит, что не 4

← →
Rouse_ © (2011-10-15 03:17) [36]

> Бездомный (15.10.11 03:08) [34]
>
> "стек1" и "стек2" надо местами поменять =)

Правильно :)

> Германн © (15.10.11 03:07) [33]
> Вот думаю как 8-ми байтное число представить однозначно
> 13-ти значным десятичным числом.

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

← →
Rouse_ © (2011-10-15 03:19) [37]

> Kerk © (15.10.11 03:13) [35]
> У меня так и получается, но Розыч говорит, что не 4

я сказал что ты чутка ошибся, а не о количестве :)

← →
Германн © (2011-10-15 03:19) [38]

> Германн © (15.10.11 03:07) [33]
>
>

И это нужно реализовать на самых "крошечных" процессорах :(
Ибо места для"больших" микросхем просто нет!

← →
Германн © (2011-10-15 03:27) [39]

> Rouse_ © (15.10.11 03:17) [36]

> > Германн © (15.10.11 03:07) [33]
> > Вот думаю как 8-ми байтное число представить однозначно
> > 13-ти значным десятичным числом.
>
> Ну это действительно тяжко, бо восмибайтовое число представляется
> максимум в виде десятизначного без запятой, если о целочисленном
> типе речь ведется...
>

Саш, а если посчитать?
Ну или ты меня не понял.

← →
Rouse_ © (2011-10-15 03:30) [40]

Ну можно и посчитать: восемь байт FFFFFFFF вмещают в себя десять знаков 4294967295.

← →
Германн © (2011-10-15 04:42) [41]

> Rouse_ © (15.10.11 03:30) [40]
>
> Ну можно и посчитать: восемь байт FFFFFFFF вмещают в себя
> десять знаков 4294967295.

Саш, пить надо меньше! Или спать больше!
Восемь байт это FFFFFFFFFFFFFFFF :(

← →
Inovet © (2011-10-15 06:02) [42]

> [38] Германн © (15.10.11 03:19)
> И это нужно реализовать на самых "крошечных" процессорах:(
> Ибо места для"больших" микросхем просто нет!

Ну так не 8 байт отведи, кто тебя держит.

← →
alexdn © (2011-10-15 07:25) [43]

> Rouse_ © (14.10.11 23:31)
label.visible нужно использовать!)

← →
Игорь Шевченко © (2011-10-15 11:24) [44]

> есть два варианта кода:

Намудрили Борланды в VCL

> наглядно это демонстрирует следующий код, где оба обработчика
> работают нормально:

Пример некорректный

← →
_Юрий (2011-10-15 11:43) [45]

> Намудрили Борланды в VCL

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

← →
vuk © (2011-10-15 11:46) [46]

to _Юрий (15.10.11 11:43) [45]:

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

А вот нефиг "строчку выводить" в таком месте.

← →
oldman © (2011-10-15 12:04) [47]

> Нужно определить, какой из них отработает не верно и почему.

каждый из них работает ВЕРНО!
что хотел, то и получил.

← →
vuk © (2011-10-15 12:11) [48]

to oldman © (15.10.11 12:04) [47]:

> каждый из них работает ВЕРНО!

Я п сказал, что с точки зрения получения корректно функционирующего приложения оба варианта - бред.

← →
oldman © (2011-10-15 12:27) [49]

> vuk © (15.10.11 12:11) [48]

Хм... Алгоритм работает верно.
А что хотел автор с точки зрения - его проблемы!

← →
vuk © (2011-10-15 12:33) [50]

to oldman © (15.10.11 12:27) [49]:

> А что хотел автор с точки зрения - его проблемы!

Эт да. Если аффтар хочет с(т)ра(н)ного, то кто ж ему доктор? :)

← →
Inovet © (2011-10-15 13:21) [51]

> [42] Inovet © (15.10.11 06:02)
> Ну так не 8 байт отведи, кто тебя держит.

Или выоди не в 13. Выоди в миллионах, а по кноке скорлл организуй с визуальным отличием. Например, число 8765432109876543210 будет выглядеть
8765432109876
нажали на кнопку
_09876543210_

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

← →
vuk © (2011-10-15 13:27) [52]

to Inovet © (15.10.11 13:21) [51]:

> Или выоди не в 13. Выоди в миллионах, а по кноке скорлл
> организуй с визуальным отличием.

Ему же в штрихкод надо. И видимо в такой, в который не влезает. Кнопки там не прокатят. Короче - впихнуть невпихуемое. Тут либо стреляцца либо тип штрихкода менять (ежели оно возможно).

← →
картман © (2011-10-15 13:49) [53]

> И видимо в такой, в который не влезает.

хэш?

← →
vuk © (2011-10-15 13:53) [54]

to картман © (15.10.11 13:49) [53]:

> хэш?

И что потом с ним делать?

← →
картман © (2011-10-15 13:56) [55]

это и будет штрихкод

← →
vuk © (2011-10-15 13:59) [56]

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

← →
Inovet © (2011-10-15 14:00) [57]

> [52] vuk © (15.10.11 13:27)
> Ему же в штрихкод надо. И видимо в такой, в который не влезает.

Вон что. Ну тогда

> [42] Inovet © (15.10.11 06:02)
> Ну так не 8 байт отведи, кто тебя держит.

Вот для чего 8 байт? Упаковать в 5.

← →
Inovet © (2011-10-15 14:01) [58]

> [57] Inovet © (15.10.11 14:00)

Только при чём сдесь ассемблер непонятно.

← →
картман © (2011-10-15 14:04) [59]

> Ага, а если таки нужны исходные данные - ищем методом перебора.

ну, там не много перебирать

> В случае коллизий - вешаемся.

да

← →
vuk © (2011-10-15 14:05) [60]

to Inovet © (15.10.11 14:00) [57]:

> Вот для чего 8 байт? Упаковать в 5.

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

← →
Inovet © (2011-10-15 14:11) [61]

> [60] vuk © (15.10.11 14:05)

Код сменить - это понятно. А 5 байт как раз в 13 десятичных цифр укладываются. Может данные позволяют упаковку 8 байт в 5 сделать.

← →
Игорь Шевченко © (2011-10-15 14:54) [62]

> Нужно определить, какой из них отработает не верно и почему.

у меня оба варианта выводят строку на форму

← →
vuk © (2011-10-15 17:14) [63]

to Игорь Шевченко © (15.10.11 14:54) [62]:

> у меня оба варианта выводят строку на форму

У меня работал только один вариант. От чего зависит, работают оба или нет, я того не знаю, но они все равно оба - неправильные. На остальное пофиг. :)

← →
Игорь Шевченко © (2011-10-15 17:35) [64]

vuk © (15.10.11 17:14) [63]

> У меня работал только один вариант

У меня сначала тоже работал только один вариант. Дело не в том, что они оба неправильные (с этим полностью согласен), дело в том, что поиск причин подобного поведения оказывается полезным. Например, при анализе чужого глючного кода.

← →
vuk © (2011-10-15 17:43) [65]

to Игорь Шевченко © (15.10.11 17:35) [64]:

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

За такой код надо убивать, без поиска причин. А потом переписывать - так как работает. Что характерно, если этот код тупо перетащить туда, где эти вещи делать правильно, то оба варианта становятся рабочими.

← →
знайка (2011-10-15 17:43) [66]

вы еще пишете с ошибками?

← →
Игорь Шевченко © (2011-10-15 17:46) [67]

vuk © (15.10.11 17:43) [65]

> За такой код надо убивать, без поиска причин

По поводу убивать - подобного рода фрагменты кода регулярно появляются в блоге Gumsmoker-a. Трупов вокруг не видно, да и патронов не хватит :)

Кроме всего, на свете есть еще масса фрагментов кода, авторы которых заслуживают кары.

> vuk © (15.10.11 17:43) [65]
> За такой код надо убивать, без поиска причин.

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

зы: вспомнил задачу автора. Он график выводил формулы введенной в TMemo и столкнулся с тем что канвас невалиден...

to Rouse_ © (15.10.11 17:57) [69]:

> и столкнулся с тем что канвас невалиден...

Это потому, что рисовать надо там, где канвас валиден по определению. Сюрпрайз, да? ;) Поэтому если видим, что рисуют где попало, надо не разбираться почему канвас не валиден, а переписывать.

> vuk © (15.10.11 18:05) [70]
> Это потому, что рисовать надо там, где канвас валиден по
> определению. Сюрпрайз, да? ;)

Спасибо, кэп :) А ты знаешь что при определенных параметрах вызова MessageBox можно получить БСОД. Сюрпрайз, да? ;) Даш рекомендацию по запрету использования данной АПИ? ;)

to Rouse_ © (15.10.11 18:21) [71]:

> Спасибо, кэп :)

Всегда пожалуйста. :)

> Даш рекомендацию по запрету использования данной АПИ? ;)

Не, не дам. А это имеет отношение к делу?

> vuk © (15.10.11 18:26) [72]
> Не, не дам. А это имеет отношение к делу?

Самое непосредственное, и там и там недокументированное поведение кода.

to Rouse_ © (15.10.11 18:30) [73]:

> и там и там недокументированное поведение кода.

Какое нафиг недокументированное поведение кода? У формы специально для того, чтобы что-то там рисовать есть специальный обработчик - OnPaint. Там всен будет работать. А если хочется большего - оработка WM_PAINT с соблюдением всех правил.

> vuk © (15.10.11 18:41) [74]
> Какое нафиг недокументированное поведение кода?

Ок, дай-ка мне пруфлинк на документацию, в которой указано что при выполнении Memo1.Lines[Index] произойдет реинициализация канваса формы...

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

Впрочем, для особо настойчивых есть Canvas.Lock

> vuk © (15.10.11 19:15) [76]
> Сначала ты дай мне документацию, где написано, что правильно
> - рисовать где попало.

Ну собственно с тобой все ясно, пруфа нет, зачем тогда вообще в спор влез?
По поводу документации - смотри MSDN, правильно рисовать там, где есть канвас. Там где нет канваса - рисовать не правильно, нес па?

to Rouse_ © (15.10.11 19:41) [77]:

> По поводу документации - смотри MSDN, правильно рисовать
> там, где есть канвас.

А еще есть из документации по VCL:

Forms.TForm.OnPaint
Any special painting on the form should be done in this event
...
If you use the form"s Canvas property outside the OnPaint event, it will be erased and drawn-over by the next OnPaint event.

Ааа, по видимости где-то тут написано, что рисовать вне OnPaint не правильно :)
ЗЫ и вообще при чем тут отрисовка, когда изначальный вопрос совершенно другой?

to Rouse_ © (15.10.11 19:55) [79]:

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

Изначальный вопрос - какой вариант кода неверный и почему. Мой ответ - неверные оба (даже если канвас блокировать), потому, что написаны не там, где надо. Если писать там, где надо, они оба нормальные. Потому, что OnPaint сделан так, чтобы канвас инвалидом не стал, ага.

> Мой ответ - неверные оба

А ты ТЗ видел чтобы данное утверждать ? :)

> Потому, что OnPaint сделан так, чтобы канвас инвалидом не
> стал

Угу, это есть, однако WM_PAINT так не сделан...

to Rouse_ © (15.10.11 20:40) [81]

> А ты ТЗ видел чтобы данное утверждать ? :)

Не, не видел. Если в ТЗ написано - сделать, чтобы был баг, то к программе вопросов нет. Но тогда есть к ТЗ. :)

> Угу, это есть, однако WM_PAINT так не сделан...

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

> vuk © (15.10.11 20:48) [82]
> Не, не видел. Если в ТЗ написано - сделать, чтобы был баг,
> то к программе вопросов нет. Но тогда есть к ТЗ. :)

Ну вот задача была реализовать код показывающий недокументированное поведение контрола TMemo. Напиши другой вариант кода, более правильно по твоему мнению реализующий данную задачу.

> Ну вот задача была реализовать код показывающий недокументированное
> поведение контрола TMemo

С какого тут боку TMemo ?

procedure TForm1.Button3Click(Sender: TObject); var DC: HDC; S: String; begin DC := Canvas.Handle; S := Button3.Caption; SendMessage(Button2.Handle, WM_NULL, 0, 0); TextOut(DC, 10, 10, PChar(S), Length(S)); end;

Не рисует

procedure TForm1.Button4Click(Sender: TObject); var DC: HDC; S: String; begin S := Button4.Caption; SendMessage(Button2.Handle, WM_NULL, 0, 0); DC := Canvas.Handle; TextOut(DC, 10, 10, PChar(S), Length(S)); end;

рисует

Приваильно, только Мемо вместо вот этого
SendMessage(Button2.Handle, WM_NULL, 0, 0)
шлет сообщение
SendMessage(Memo.Handle, EM_GETLINE, Index, Longint(@Text))
что собственно получается те-же яйцы...

to Игорь Шевченко © (15.10.11 21:03) [84]:

> С какого тут боку TMemo ?

Вот-вот. Тут не TMemo виноват, а цикл обработки сообщений внутри VCL. Ну так никто и не обещал, что если в процессе обработки одного сообщения отправлять другое и ждать его обработки, не будет никаких побочных эффектов.

Rouse_ © (15.10.11 21:06) [85]

Я полагаю, что любое обращение к TWinControl.MainWndProc в промежутке между Canvas.GetHandle и использованием полученного DC для рисования будет давать подобный эффект.

А теперь, внимание, вопрос - как сделать, чтобы и в этом случае рисовало ?

to Игорь Шевченко © (15.10.11 21:13) [87]:

> А теперь, внимание, вопрос - как сделать, чтобы и в этом
> случае рисовало ?

Я уже упомянул Canvas.Lock. Ну и Unlock к нему. В OnPaint как раз все залочено, поэтому там все работает.

> А теперь, внимание, вопрос - как сделать, чтобы и в этом
> случае рисовало ?

Помимо того что перечислил vuk, через TextOut(Canvas.Handle, есественно...

vuk © (15.10.11 21:17) [88]

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

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

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

P.S.
Фокусы подобного рода информативно бессмысленны.

> [80] vuk © (15.10.11 20:09)

В обещм случае обращение к TCanvas может быть не только для того, чтобы что-то на ней наприсовать. Возможно, к примеру, срисовать или замерить ) но это уже частности )

> vuk © (15.10.11 14:05) [60]
>
> to Inovet © (15.10.11 14:00) [57]:
>
> > Вот для чего 8 байт? Упаковать в 5.
>
> Не все типы штрихкодов позволяют работать с символами, отличными
> от цифр. Я почему и говорю - тут либо стреляться либо тип
> кода менять.

Прошу прощения за оффтоп.
У заказчика дорогая "мерканская" система доступа. По всем признакам используется некие карты со штрих-кодом в стандарте EAN-13. Так что изменить формат я не властен. Но вроде DallasSemiconductors и фирма, которая перекупила права на сей продукт у DS, ведут себя "грамотно". И 5-ти байт кода ключа более чем достаточно. Ибо более старшие байты пока нулевые, т.е. одинаковые для всех ключей.
Ещё раз прошу прощения за оффтоп. Больше я на эту тему в этой ветке высказываться не буду.

> EAN-13

ean-13 можно свести к 12 байтам
13й - check-digit, его можно расчитывать
может поможет

Хм, задачка... Найти похожие ветки