Вверх ↑
Этот топик читают: Гость
Разработчик
Ответов: 25489
Рейтинг: 2072
#61: 2009-08-17 12:18:08 ЛС | профиль | цитата
Galkov писал(а):
Если судить по кодам новых элементов

А поточнее можно, каких
карма: 19

0
Ответов: 9821
Рейтинг: 340
#62: 2009-08-17 12:31:23 ЛС | профиль | цитата
Assasin писал(а):
а вот чтоб и можно было изменить тип работы

Глупость это, как мне кажется
Возьмем нейтральный пример - Math
Может найтись автор с такими тараканами, что захочет изменить операцию во время работы ???
Легко - это автор какого-нибудь кнопочного калькулятора, которому надо реагировать на нажатие пользователем кнопки с операцией.
Чего надо отвечать ему на запрос "а вот чтоб и можно было изменить тип работы" - посылать куда по-дальше. Пусть использует какой-нибудь IndexToChanel и много элементов - не боярин.

Причина: он такой один нашелся, а пользователей, использующих константное значение св-ва - много. И у этих пользователей в кодах - только один метод. А если согласиться с вышеупомянутым - будет весь спектр, у всех пользователей, даже если им все это нафиг не упало...
Оптимальность и рациональность - ничего лишнего, как говорится.

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

карма: 8

0
Администрация
Ответов: 15273
Рейтинг: 1501
#63: 2009-08-17 12:59:28 ЛС | профиль | цитата
Galkov писал(а):
И у меня такое ощущение, что кроме меня это никто и не знает.

о чем именно? об использовании 14 типа в выражениях doMethod%PropName%?
карма: 23
0
Ответов: 9821
Рейтинг: 340
#64: 2009-08-17 13:24:43 ЛС | профиль | цитата
Да, мне кажется, и 4-го - тоже.... Не, о тебе речь не идет, естественно - это было бы глупо

Имеется ввиду пользователь, который перешел на изготовление элементов. Безусловно, есть примеры кодов существующих элементов.
С формализацией всех существующих приемов "изготовления" в справке, в разделе "Разработка/Файл конфигурации" - было бы еще лучше
------------ Дoбавленo в 13.26:
Нет там такого, вроде
карма: 8

0
Администрация
Ответов: 15273
Рейтинг: 1501
#65: 2009-08-17 14:03:02 ЛС | профиль | цитата
внес описание
карма: 23
0
Разработчик
Ответов: 4668
Рейтинг: 420
#66: 2009-08-17 15:27:57 ЛС | профиль | цитата
Никак не пойму, что я неправильно сделал Как заставить функцию вернуть полученное значение в
#pas
eFrg := Frg - Argument(0);

Функция:
#pas
function THIRunText.Argument(Value:Integer):integer;
var dt:TData;
begin
case _prop_Kind of
0: _var_TextWidth(dt,0);
1: _var_TextHeigh(dt,0);
end;
end;
карма: 10
0
Администрация
Ответов: 15273
Рейтинг: 1501
#67: 2009-08-17 15:31:21 ЛС | профиль | цитата

#pas
...
Result := ToInteger(dt);
...

Galkov писал(а):
Вообще-то, вызывать точку из другого метода - садизм....
Правильнее завести отдельную ф-ю типа TextWidth

карма: 23
1
Голосовали:Assasin
Разработчик
Ответов: 4668
Рейтинг: 420
#68: 2009-08-17 15:36:25 ЛС | профиль | цитата
Спасибо, компонент готов, хорошо, придется сделать функцию, по вашим натиям, да и не хочу быть садистом
карма: 10
0
Гость
Ответов: 17029
Рейтинг: 0
#69: 2009-08-17 16:49:01 правка | ЛС | профиль | цитата


Редактировалось 3 раз(а), последний 2017-06-14 19:17:54
карма: 0

0
Разработчик
Ответов: 4668
Рейтинг: 420
#70: 2009-08-17 16:49:36 ЛС | профиль | цитата
Это был я
карма: 10
0
файлы: 1rt.rar [2.8KB] [125]
Администрация
Ответов: 15273
Рейтинг: 1501
#71: 2009-08-17 16:59:33 ЛС | профиль | цитата
34.60.lks-tv.ru писал(а):
да и значение как-то криво возвращается с функций

судя по варнингам я бы сказал, что оно никак не возвращается. Возврат значения ф-ции это присваение чего бы то ни было переменной Result. См. сообщение 4мя постами выше
карма: 23
0
Разработчик
Ответов: 4668
Рейтинг: 420
#72: 2009-08-17 17:01:34 ЛС | профиль | цитата
Dilma, в том-то все и дело :
#pas
function THIRunText.Argument:integer;
var dt:TData;
begin
case _prop_Kind of
0: Result := TextWidth(dt);
1: Result := TextHeigh(dt);
end;
end;
#pas
function THIRunText.TextHeigh(_Data:TData):integer;
var SizeFont: TSize;
s: string;
hOldFont: HFONT;
dt:TData;
begin
TRY
if not ImgGetDC(_Data) then exit;
s := ReadString(_Data,_data_Text,_prop_Text);
hOldFont := SelectObject(pDC, GFont.Handle);
GetTextExtentPoint32(pDC, PChar(s), Length(s), SizeFont);
SelectObject(pDC, hOldFont);
dtInteger(dt, SizeFont.cy);
FINALLY
ImgReleaseDC;
END;
Result := ToInteger(dt);
end;
карма: 10
0
Администрация
Ответов: 15273
Рейтинг: 1501
#73: 2009-08-17 17:16:46 ЛС | профиль | цитата
might be undefined переводится как "может быть не определено". Это значит, что компилятор не в состоянии проверить действительно ли значением поля _prop_Kind могут быть только числа 0 и 1, и поэтому выдает предупреждение. В TextHeigh значение будет не определено тогда, когда сработает условие not ImgGetDC(_Data). С TextWidth видимо аналогично.
карма: 23
0
Разработчик
Ответов: 4668
Рейтинг: 420
#74: 2009-08-17 17:41:13 ЛС | профиль | цитата
А в чем же тогда тайна runtimeerror в том же что ли?
карма: 10
0
Администрация
Ответов: 15273
Рейтинг: 1501
#75: 2009-08-17 17:58:46 ЛС | профиль | цитата
Assasin писал(а):
А в чем же тогда тайна runtimeerror

в обращение к "левому" полю ldata

#hws
0: Result := TextWidth(dt);
1: Result := TextHeigh(dt);
...
dtInteger(_Data,TextWidth(dt));
...
dtInteger(_Data,TextHeigh(dt));
-> именно это одна из главных причин, по которой использование TData в качестве аргументов вызова методов внутри элемента не рекомендуется.

Собственно вся логика элемента не продумана до конца. Поскольку имеется зависимость от внешнего контекста, то нужно было делать процедуру doInit(или что-то вроде), в которой получать этот самый контекст и сохранять его для использования во всех остальных методах(в частности в TextWidth и TextHeigh). Сегодня в качестве контекста передается неинициализированный dt, что очевидно работать никогда не будет.
карма: 23
0
Сообщение
...
Прикрепленные файлы
(файлы не залиты)