goldmi45Андрей Игоревичпропущено...
Так вродеж тем и хороши записи, что добавив уровни не надо ничего переписывать. В общем надо подумать.
Ошибаетесь. Необходимо будет в записи добавить ещё одну переменную, необходимо дописать поиск, вывод. Перекомпилить наконец. А это не всегда возможно (потеря исходников, например, может случиться).
Не, ну как бы любые корректировки подобного масштаба к чему-то подобному приведут, доживем - подумаем :)
Андрей Игоревичпропущено...
Андрей ИгоревичСейчас у меня просто поиск по имени узла и имени родителя происходит, который сверяю с сохраненными данными и вывожу форму. Всё прекрасно работает, но мне не нравится, вообще нечитабильно.
При таком подходе - грабли слегка прикрыты сеном. Может ли случиться такая ситуация, когда будет два разных узла, у которых наименование их и их родителей совпадут? Если это не случится сегодня, может ли такой сценарий реализоваться в будущем?
Могут, тоже одна из причин почему не очень нравится.
DimaBrВылетает с ошибкой на ошибку чтения из памяти, при том вылетает при завершении процедуры в которую вложен
Думаю что это происходит из-за
1.
node.data:=Pointer(Indx[IndexTree]);
Логично :), после добавления этого кода и начало вылетать.
DimaBr
Попробуйте хранить так
1.
node.data := Pointer(IndexTree);
Ну это ничем не будет отличатся от обычного индекса узла, что вызывает некоторые сложности к обращению к данным.
DimaBrЯ так и не понимаю, что вы храните в
1.
2.
3.
4.
5.
6.
TIndex =record
lv1:byte;
lv2:byte;
lv3:byte;
lv4:byte;
end;
Индексы для узла. Суть в том, что я структурировал данные в виде записи так же, как они выглядят в дереве TreeNode, поэтому обращаться к конкретной ячейке памяти по таким индексам можно напрямую, без поисков и прочего.
BeltarавторКак всё-таки корректно работать с Data?
Просто преобразовывать тип.
Например.
1.
2.
3.
4.
5.
6.
7.
8.
TNodeDescr=class
F1:Integer;
F2:Integer;
end;
Node.Data:=TNodeDescr.Create;
TNodeDescr(Node.Data).F1;
Ну это не особо отличается от "своего узла" с индексами предложенного выше :).
BeltarЯ не очень понимаю, чем вас не устраивает простой перебор нодов?
1.
2.
3.
4.
5.
6.
7.
8.
for i:=0 to TreeView.Items.Count-1 do
begin
if TNodeDescr(Items[i].Data).F1=Something then //Ну или любой критерий отбора, хоть функцию сложную напишите, например, можете по тексту узла искать.
begin
ShowMessage('Индекс узла равен '+IntToStr(i));
Break;
end;
end;
Если у вас даже тыща-другая узлов, это все равно будет работать быстрее, чем вы сможете почувствовать.
Ну пока так и работает, и даже быстро, просто из-за кучи мелких нюансов (разного формата данных из файлов) в коде возникает огромное количество условий, циклов проверок на всё подряд, при возникновении ошибки в которых у меня начинает кипеть мозг.
Как я уже писал выше, сами данные в программе я структурирую так же, как они будут отображены в дереве, потому обращение по индексам/уровням позволит сразу обращаться к нужной ячейке данных минуя переборы и проверки. Вот поэтому я вел разговор про индексацию с учетом уровней.
Beltarавторесть файлы где по 200+ настроек, разбитые на разделы.
А вы загрузить это сможете? Задача как бы не совсем примитивная, я как-то делал аналог проги DelphiWorld с загрузкой и сохранением в бинарник своего формата, но там я как захотел, так и сделал, у меня просто с узлом хранилось число дочерных и все делалось через стек родительских узлов (деревья вообще любят стековые алгоритмы). А как у вас в файле всё это организовано.
Смогем, и не такое грузили (не без помощи товарищей с этого форума), даже пол сотни гигабайт грузил :).
В данном случае объемы данных исчисляются от силы парой гигабайт, даже на 64 бита не придется переходить :).
