Что то туплю, как взять указатель на ссылку на объект в TStringList.Object[]
так не катит @(TStringList.Objects[i]), ошибка variable required

ъъъъъ,

типа "дерево" - указатель на ссылку нужен в другом TStringList, который строится на этом TStringList с его Objects, чтобы меняя в дочернем объекты - это отражалось на родителе без поиска по Index родителя.

*удалено

как тогда взять указатель на этот указатель?

получается мне надо в TStringList.Object[] сувать не ссылки на объекты, а сразу брать указатель на ссылку и тогда можно будет тупо присваивать

хотя не, фигня, объекты же появляются в процессе произвольно, а не сразу (

DimaBr,

да точно, логично, вместо таскание в дочерний список объектов, можно просто передавать их Index родителя

SOFT FOR YOU,

да обойдусь уж передачей Index родителя, без указателей конструкция обращения стала огромной, но полагаю что "неприличный" способ еще более громоздкий ) уже очень не хочется наследовать TStringList и там кучу всего переписывать )

ъъъъъ,

в чем бред то, двойной указатель потеря потерь в дельфах? ))

ъъъъъ,

объекты появляются в list1 в ходе работы, их там нет с общей инициализацией

если нужна конкретика, то list1 это глобальный список, который используется для заполнения и удаления объектов в других потоках, а list2 расширенный локальный список, который используется в основном потоке, где Objects "ПОЧТИ" те же самые что и в list1 + еще и дублируются.

ъъъъъ,

поэтому и хотелось получить указатель на переменную, которая хранит указатель на объект

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

ъъъъъ,

т.е. если б можно было

инициализация
list1.objects[i] := nil;
list2.objects[j] := @list1.objects[i];

затем где то
list1.objects[i] := o

и еще где то
Assigned(list2.objects[j]^) = true

alekcvp,

если выяснится, что это не потокобезопасно, то придется ))

после list2.objects[j] := list1.objects[i];

попробуйте list1.objects[i] := nil сделать (объект уничтожен), а потом проверить Assigned(list2.objects[j]) и узнаете

defecator,

да это детали, пусть будет Free сначала иль деструктор, а потом nil

можно даже не мудрить с list2, просто уничтожить O

nil мне нужен для проверки существования объекта в TStringList.Object[]

ъъъъъ,

вы не понимаете, а мне читать ))

ъъъъъ,

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

DimaBr,

)) бида пичаль, теперь в этой теме на 4 страницы холивала похоже будет

DimaBr,

да и в чем собсна удивление в вопросе? TStringList.Object[] это элементарный TStringItemList = array[0..MaxListSize] of TStringItem, что и имел очевидно ввиду SOFT FOR YOU, получать указатели на элементы которого уже можно без проблем.

ъъъъъ,

точно, тем более что вместо совета тупили страницу )))

что то со счетом у вас плохо только, совет один, выше ничего нет, "третий" ссылка по которой и переходить смысла нет

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

DimaBr,

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

Vizit0r,

)) вот чо к чему, какой велосипед, уже даже давно все переделано, хотя Бох с ним, флудите, будет что DimaBr в следующий раз запостить.

Zelius,

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

ъъъъъ,

список2 содержит множество объектов и их дубликатов списка1, работа выполняется одновременно как со списком1 так и со списком2 в разных кусках кода, объекты в списке1 могут быть, а может и нет, при этом список2 всегда знает об этом

извините, но уже не знаю как объяснить!!!

Сейчас я сделал в списке2 объекты не объектами списка1, а объектами с Index списка1 (по совету DimaBr), выглядит рабоче, просто строка обращения к объекту длинная и все, в типизированном указателе это было бы намного короче.

В чем вопрос то ваш???
Почему мне нужны именно объекты? Потому что они полностью с атрибутами и методами описывают предметную область для строки списка1/2
Почему не создать новые объекты для списка2? Потому что объекты привязаны к физическому оборудованию, их нельзя создать больше чем железок!

Ничего больше не нужно мне, спасибо! так сойдет!!!

Kazantsev Alexey,

спасибо!!! в целом уже понял, что надо обращаться через PStringItemList

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

Vizit0r,

и чем он плох? то вам почему велосипед нештатный, то этот велосипед уже какой то не такой.