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

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

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

Узнать Top предыдущего элемента в списке TList [D7]

Страницы: 1 2 3 >
Vass © (2010-05-19 18:57:00)
Здравствуйте! У меня такой вопрос. Создал список типа TList и "кидаю" в него компоненты типа TImage, как узнать свойство Top предыдушего Image-а ? Например, мне нужно устрановить следующий блок ровно под предыдущем.
... pimage^.Top := List.Items[i-1]^.Top + List.Items[i-1].Height; ...
Что то типа такого, но именно так нельзя Items[i] это типа Pointe, Тор-это типа integer. Заранее спасибо!!! Этот сайт и форум мне уже не раз помог!!! ))

Германн (2010-07-23 16:59:00) [1]

> Так что указатели в этом смысле от других переменных не
> отличаются ничем.

Кроме нетипизированных указателей, имхо.

Юрий Зотов (2010-07-23 09:49:00) [2]
> igrif (23.07.10 09:25) [42]

> Ошибки в коде, не связанном с указателями в большинстве случаев
> найдет сам компилятор

Если бы. Присвоили переменной неверное значение - и привет. И тоже замучаешься искать.

> п.1. включает п.2.,

П.1. НЕ включает п.2. П.1, если он выполнен, автоматически приводит и к выполнению п.2. Ведь если в любом месте кода я всегда знаю, на что указывает указатель (п.1.), то это значит, что я всегда знаю и те места кода, где он не указывает ни на что. Поэтому специально обнулять убитый указатель и потом проверять его на nil (п.2) уже не нужно.

igrif (2010-07-23 09:25:00) [3]

> Юрий Зотов © (23.07.10 06:53) [41]

> Не осторожное, а аккуратное. Как и вообще весь кодинг -
> он должен быть аккуратным. Так что указатели в этом смысле
> от других переменных не отличаются ничем.

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

> Достаточно только п.1. Если он выполнен, то п.2 автоматически
> становится лишним.

п.1. включает п.2., я бы даже не выделял здесь пунктов, это просто пояснение.

Юрий Зотов (2010-07-23 06:53:00) [4]
> igrif (23.07.10 06:08) [40]

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

Не осторожное, а аккуратное. Как и вообще весь кодинг - он должен быть аккуратным. Так что указатели в этом смысле от других переменных не отличаются ничем.

1. > Ты всегда должен знать на что он указывает в данный момент,
2. > пустые указатели держать в NIL и проверять перед использованием

Достаточно только п.1. Если он выполнен, то п.2 автоматически становится лишним.

igrif (2010-07-23 06:08:00) [5]
ну под правильным подходом здесь понимается очень осторожное обращение с указателями. Ты всегда должен знать на что он указывает в данный момент, обязательно пустые указатели держать в NIL и проверять перед использованием... Вообще, откровенно говоря, с точки зрения Вирта правильная работа с указателями - это отсутствие указателей. Но это уже, по-моему, бред. Так что не замарачиваяся, к концу написания своей программы поймешь как надо-было сделать правильно :)

today (2010-07-22 19:34:00) [6]
перечитал. А где ТОТ САМЫЙ ПРАВИЛЬНЫЙ ПОДХОД??

Юрий Зотов (2010-07-17 21:30:00) [7]

> igrif (17.07.10 20:53) [37]

Естественно, не поспоришь - это же азбука. И одновременно - ПРАВИЛЬНЫЙ подход к программированию.
:o)

igrif (2010-07-17 20:53:00) [8]

> Юрий Зотов

Хмм... с этим и не поспоришь :)

Юрий Зотов (2010-07-17 19:10:00) [9]
> igrif (17.07.10 14:53) [35]

Я думаю, что и в качестве профессионального софта, и в качестве тренировок о каждом своем указателе программист просто всегда должен совершенно точно знать, что это такое и куда оно указывает.

igrif (2010-07-17 14:53:00) [10]
to Юрий Зотов:

Вероятность мизерная. Но, вы, конечно правы - вполне может возникнуть такая ситуация. По большому счету в проф деятельности таким пользоваться нельзя конечно, но в качестве тренировок (я сомневаюсь что уважаемый Vass пишет коммерческую софтину) самое оно :)

> Записки из мертвого дома.??????????

Leonid Troyanovsky (2010-07-17 12:45:00) [11]

> igrif (16.07.10 20:51) [32]

> Немного наврал по-моему. Вот специально по случаю: http:
> //www.igrif.org/programmizm/kak-uznat-klass-obekta/

Записки из мертвого дома.

--
Regards, LVT.

Юрий Зотов (2010-07-17 12:43:00) [12]

> igrif (16.07.10 20:51) [32]

Создаем новый проект и к абсолютно пустой форме добавляем вот такой обработчик события OnClick:
procedure TForm1.FormClick(Sender: TObject); var PClassName: PShortString; PClassType: Pointer; PSelf: PPointer; begin GetMem(PClassName, 6); try PClassName^ := 'TEdit'; PClassType := Pointer(Integer(@PClassName) - vmtClassName); PSelf := @PClassType; try ShowMessage('Объект класса: ' + TObject(PSelf).ClassName) except ShowMessage('Не объект') end finally FreeMem(PClassName) end end;
Запускаем, кликаем по форме - и видим что изложенный в статье метод срабатывает неверно: обычный указатель он определяет, как ссылку на объект класса TEdit. Так и должно было быть - значения всех переменных в программе специально установлены именно такими, чтобы возникло ложное срабатывание. Но кто может поручиться, что и в реальной программе в результате случайных совпадений не возникнет такая же ситуация? Никто.

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

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

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

igrif (2010-07-16 20:51:00) [13]

> Указатель указывает не на Label и не на Edit. Указатель
> указывает на адрес в памяти.

Немного наврал по-моему. Вот специально по случаю: http://www.igrif.org/programmizm/kak-uznat-klass-obekta/

today (2010-07-09 12:27:00) [14]
а если оставить все как есть?

Leonid Troyanovsky (2010-07-09 07:50:00) [15]

> today (09.07.10 07:38) [29]

> Есть scrollbox в который добавляются панели с контролами
> (Edit, Memo, ComboBox). Панели меняют свое положение (сортируются)
> в зависимости от номера который вводится в Edit...

Чего-то слишком наворочено.
Проще немного поработать над TDrawGrid.

--
Regards, LVT.

today (2010-07-09 07:38:00) [16]
Значит так:
Есть scrollbox в который добавляются панели с контролами (Edit, Memo, ComboBox). Панели меняют свое положение (сортируются) в зависимости от номера который вводится в Edit... Также есть TList в который добавляются указатели на эти панели, в приципе (пока) только для сортировки этот List мне и нужен. Сортировка проходит так:
List.Move(1,3); for i := 0 to List.count-1 do TPanel(List.items[i]).Top := {ширина панели}*i;
Сначало было по другому, но так стало короче. Критикуй пожалуста

Ega23 (2010-07-09 06:33:00) [17]

> А как надо? Направь :)

А это смотря что ты хочешь получить.

today (2010-07-09 05:46:00) [18]
А как надо? Направь :)

Deltas (2010-07-08 19:52:00) [19]
Такая запись в свойство объекта
TEdit(r).Text := 'f';
приведет к выполнению точно того же кода, который выполняется при
Label1.Caption := 'f';
или
TLabel(r).Caption := 'f';
И, несмотря на то, что это не приведет к сбою программы, это очень плохой стиль программирования.

Deltas (2010-07-08 19:45:00) [20]
Указатель указывает не на Label и не на Edit. Указатель указывает на адрес в памяти.

> var r: Pointer;
> ...
> r := pointer(Label1);
> TEdit(r).Text := 'f';
> r := nil;

Это неправильный подход к программированию. В общем случае это приведет к ошибке доступа к памяти. Но в данном случает работает, и ответ на вопрос "почему?" кроется в классе TControl, который является предком для TEdit и TLabel:

TControl = class(TComponent)
...
property Caption: TCaption read GetText write SetText stored
IsCaptionStored;
...
property Text: TCaption read GetText write SetText;
...
end;

Причем очень важно, что SetText() не является виртуальным методом и не вызывает другие виртуальные методы.

Страницы: 1 2 3 >

Наверх

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