Проблема... с TStrings.

← →
TankMan © (2002-10-14 21:21) [0]

Я тут уже читал в FAQ, про то, что при создании компонента TStrings появляется ошибка - там ответ, что TStrings абстрактный класс, что нужно испльзовать TStringList, но понимаете в чем проблема, мне нужно использовать компонент TStrings для работы с ини файлами например ReadSection - ему нужно указывать компонент этого типа... я знаю впринципе как это сделать.. нужно использованть динамический ListBox ,но вот проблема...щас о ней долго разговаривать, ну вобщем очень гиморно будет там использовать этот ListBox, может скажет,всетаки, как-то можно использовать этот TStrings? Всетаки как -то же получается использовать его в Listbox, ведь items, как раз TStrings типа, и никаких ошибок нет... может я что-то не понимаю или не знаю.. раскажите. Вобщем вопрос - возможно ли какнибудь использовать этот TStrings не через ListBox?

← →
TTCustomDelphiMaster © (2002-10-14 21:24) [1]

В программе замените все TStrings на TStringList. Если будет ругаться используйте приведение типов TStrings(Переменная)

← →
down (2002-10-14 21:41) [2]

var
Strings: TStrings;
begin
Strings := TStringList.Create
или
Strings := THashedStringList.Create

← →
Юрий Зотов © (2002-10-14 22:05) [3]

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

Объявление

procedure ReadSection (...; Strings: TStrings);

означает, что вторым параметром должен быть ЛЮБОЙ TStrings. А все потомки TStrings - это ТОЖЕ TStrings. В том числе, и TStringList.

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

TStrings - это общий класс, базовый предок целого семейства. Он для того и сделан абстрактным, чтобы везде реально использовался не он сам, а его наследник, обладающий конкретной функциональностью. А в объявлениях пишут TStrings тогда, когда в этом месте допускается не только какой-то конкретный класс, а вообще ЛЮБОЙ TStrings.

← →
TankMan © (2002-10-15 03:38) [4]

>>Юрий Зотов
Я знаю, что TStringList - потомок, но я потому и спрашиваю, потому что когда я не знал, что TStrings - нельзя использовать, я описал переменную buf типа TStrings и пытался записать в нее данные функцией Ini файлов inifile.ReadSection("Название_раздела",buf)
Он мне выдавал ошибку, я прочитал потом, что нужно использовать TStringList и просто исправил в описании тип buf на TStringList. И он мне выдал что TStrings и TStringList не совместимы.
Так что...

← →
Юрий Зотов © (2002-10-15 05:21) [5]

В ОПИСАНИИ ничего не правьте, оставьте TStrings. А вот при реальном СОЗДАНИИ используйте TStringList.Create. И все будет ОК. Это я и пытался объяснить - уж как сумел.

← →
Opuhshii © (2002-10-15 08:46) [6]

2TankMan ©
"что при создании компонента TStrings"
TStrings не есть компонент,...

← →
MrZeRo (2002-10-15 10:31) [7]

Почитайте Delphi VCL исходники, например, реализацию свойства SQL у TQuery - очень познавательно в плане освоения работы с TStrings.

← →
Zemal © (2002-10-15 11:38) [8]

Блин!!! Геморой ищете сударь!!! Уже ли не знаете, что там где требуется тип TStrings возможно передавать любой класс наследник, например тот же TStringList!!! А там где ожидается объект типа TObject вы тоже будете создавать именно экземпляр TObject?! А я вам скажу, сударь, что ещё ниразу не сталкивался с ситуацией, когда мне требовалось бы приведение типа при передачи как параметра в функцию, когда там требуется к примеру TStream, а я передаю TFileStream!!! Никогда!!! Там где требуется TObject, можно передавать любой объект-наследник от этого класса!!! Нихрена вы не усвоили основных принципов Объектно Ориентированного Программирования (ООП). Читайте литературу, сударь!!! И повнимательнее!!! Это полный бред использовать абстрактный класс!!! Абстрактный класс тем и отличается, что имеет абстрактные методы, которые обязательно (!!!), подчёркиваю, ОБЯЗАТЕЛЬНО, должны быть перекрыты в потомках этого класса!!! А дело всё в том, что эти самые АБСТРАКТНЫЕ методы не имеют реализации (!!!), т.е. неописаны (!!!) и использование их приведёт к ошибке!!! Да вообще чего я тут распаляюсь... :( Видно, что вам сударь нехватает знаний, чтобы садиться и "брать в руки шашки"!!! Берите-ка литературу!!! И пока не усвоите принцыпы ООП, такие как инкапсуляция, деллигирование и др. не садитесь даже за Делфи! Вот мой вам совет!

← →
Scorp © (2002-10-15 14:42) [9]

М-да, вот єто загнул. А чево там Вы говорили о ListBox ?
Тут одно слово - учите ООП, тоесть Дельфи.

← →
Zemal © (2002-10-15 15:09) [10]

>>Scorp
ООП - это не Делфи. А без основ ООП, все твои знания процедур и функций сводятся к нулю... без понимания структуры классов, типов и общих понятий только в Turbo Pascal дорога... да и то условно... без знания основ ООП вообще нечего садиться чего-то делать, если только копировать куски рабочего кода и глупо смотреть как это работает. Без ООП и в Си++ делать нечего... и даже VB. ООП - это первый шаг. Без этого всё остальное теряет смысл, потому что всёравно мимо ушей. Вот даёшь советы, пишешь код, а его просто копируют в буфер и вставляют в процедуру и если неработает, то опять в форум, потому что сам непонимает как это всё работает. Так не лучше ли сначало основы понять, только не пробежаться глазами как по неинтересному месту и акцентировать внимание на функциях перезагрузки виндов (это первое на чего обычно обращают внимание новички), а именно подойти серьёзно, чтобы понять!!! И советовал бы перечитать несколько раз с некоторым интервалом времени (по мере накопления опыта). Иногда даже продвинутому программеру открываются новые горизонты, потому что у каждого есть свои любимые способы и зачастую не лучшие. Я сам иногда перечитываю... во многом помогает :). Кстати, ты сам понимаешь что такое деллигирование? А полеморфизм? Ответь прям сейчас себе!!! Можно неписать в форум... А чем отличается динамический метод от виртуального? Сможешь прям на вскидку? Чисто для себя... попробуй... эти вопросы должен себе задавать каждый программист и если сможет ответить на них не заученными фразами из книги, а дать понятие, тогда он настоящий программист, а не "дизайнер форм". Понятно объяснил?

> (!!!), подчёркиваю, ОБЯЗАТЕЛЬНО, должны быть перекрыты в потомках

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

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

>>Юрий Зотов
Полностью согласен! :) Не так выразился :). Я имел ввиду, что вызов неперекрытого абстрактного метода приведёт к ошибке в рантайме, причём это может повлечь даже крах ОС. А как можно использовать класс, основные методы которого абстрактные и без которых он просто бесполезен? Например TStream имеет абстрактные методы получения и записи, без которых он просто "нежилец" :)... как говориться "слеп и глух" :), куда такого "порождать"? :) Кстати, по идее надо бы в потомках всё-таки перекрывать абстрактные методы хотябы "заглушками", но это конечно "по идее", на практике это размножение мёртвого кода, в этом ты, также, безусловно прав! :) Спасибо за уточнения! :)

Кстати, на счёт краха ОС я что-то загнул... припомнилось что-то недоброе из другой совершенно оперы... просто возникнет Exception (типа EAbstractКакойТоТам :) )

Спасибо за ответ... я просто не знал что можно создавать так.
А основы ООП я знаю, так что не волнуйтесь.. я не просто копирую :)... (но еще и вставляю и удаляю, если не работает ;) )

Пример приведения типов: TField
производные от него TADTField TDateField TMemoField
которые присваиваются Fields[Index: Integer]: TField; DataSet"ов

Проблема... с TStrings. Найти похожие ветки