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

← →
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. Трупов вокруг не видно, да и патронов не хватит :)

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

← →
Rouse_ © (2011-10-15 17:53) [68]

> 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 сделан так, чтобы канвас инвалидом не стал, ага.

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