Подскажите, как реализовать следующую задачу, нужно открыть XML файл и из него вывести в memo нужную информацию
структура файла:


Нужно что  бы создавалась 3 колонки с unitTypeActual identificationCode serialNumber
с XML не работал, даже не представляюс с помощью какого компонента это можно сделать

Посмотри внизу на похожие ссылки... если там не найдёшь, то накидаю тебе программу на регулярках.

TXMLDocument с закладки Internet. В хэлпе всё хорошо описано и с примерами.

ПРобую но ни чего не получается (((
Единственное получилось загрузить в TDGrid с помощью XML Mappera, но мне такой вариант не подходит т.к. у меня около 5 тысяч XML файлов и мне надо из них построить одну базу

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

Действительно........ просто запарился  ((((
можешь накидать примерчек как с помощью XMLDocument можно вывести в мемо (в моем случае)
все UNIT с атрибутами unitTypeActual и serialNumber
Вот XML Файл



Это сообщение отредактировал(а) Erfolg - 23.9.2006, 14:01

Добавь на форму контрол ListView, установи компонент TregExpr(поищи по форуму):



Если unitTypeActual всегда 4 буквы, а serialNumber 12 символов, то работать будет... 
Можно было бы попроще сделать, без всяких StringReplace, но оказалось, что TregExpr не поддерживает опережающих проверок, которые в парсинге XML очень полезны.

BUGOR, вобще ничего страшного что для разбора xml существует специальный парсер. 
Война как говорится ...., главное маневры.


стакими ограничениями .... 
А потом ищи откуда в юзера глюки полезли.


Так и зачем тогда это нужно.

Работа с XML на форуме расписана вдоль и поперек. Зачем велосипед с квадратными колесами изобретать?


Erfolg, File->New->Other->XMLBuilder
и будет счастье.

drkot, читай внимательно топик, я же написал в своём первом сообщении: "Посмотри внизу на похожие ссылки... если там не найдёшь, то накидаю тебе программу на регулярках.", человек стукнул ко мне в icq и попросил накидать пример потому, что у него не получилось что-то с готовыми компонентами, что касается условий, то всё вполне рационально т.к. данные шаблонны если тебя не устраивают ограничения, то нужно просто поправить регулярное выражение и всё. 
Я не считаю нужным юзать огромные библиотеки и компоненты, когда задача стоит всего-лишь в том, чтобы вытащить некоторые данные из документа, целиком его парсить вовсе ненужно. Вообще можно решить это с помощью двух-трёх стандартных функций и решение не будет громоздким, просто оно будет менее элегантным, нежели при использовании TRegExpr. 

К тому же я не вижу смысла в этом споре, ты предложил своё решение проблемы - я своё, пусть человек выбирает, есть по меньшей мере две причины по которым я выбрал собственную реализацию(в данном случае):
1. Собственная реализации будет быстрее.
2. Программу не так раздует. 

Это сообщение отредактировал(а) BUGOR - 24.9.2006, 14:46

TRegExpr да это маленикая библиотека на 150 кил чистого кода + по скорости уступает стандартному парсеру раз в 10. 
Спецификация  XML "нестрогая": тоесть есть огромное число допущений по синтаксису и форматированию документа (даже в одном документе одни и теже поля могут быть сформатированы по разному - разделены #10#13 например) и учесть все это в регулярках сложно и нецелесообразно.
Из собственного опыта: в процессе конвертации из HTML(база) в XML(база) из примерно 2000 страниц не было автоматически разобрано порядка 150. Хотя эти страницы генерировались одним PHP скриптом, а регулярки предварительно хорошо оттестировались.


Если Вы считаете что реализация в виде классов и интерфейсов менее элегантна то позволю с Вами несогласится.

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


Если Вы незнаете или не владеете средствами работы с XML (тема так и звучит) то наверное стоит почитать 

или послушать что люди скажут, а не подставлять 5-е колесо к телеге.
А потом такие "наученые" приходят на работу и валят перво еже задание, да и реализация получается такая, что вдрож кидает.
Нихочу никого обидеть, но культура в программировании должно присутствовать иначе будет как в чизни. 
Если я неправ то готов выслушать критику в свою сторону (но конструктивную).

Добавлено @ 15:08 
Да и вдовесок.
Я нисколько не посягаю на Ваши знания в области регулярных выражений и их(выражений) ценности в решении поисковых задач.

В данном случае её использование не прибавляет к проекту и 20 кило, какой же прирост мы получим, если будет использовать метод предложенный вами? Я думаю это далеко не 20 Кб.  Насчёт скорости, это слова с неба или Вы их можете подкрепить доказательствами? Или давайте сравнивать, или про скорость работы TRegExpr не упоминать. 



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



Ну так скажите, что-нибудь по делу лучше, не поленитесь, возьмите и сравните по скорости и размеру(а что ещё важно клиенту? Красота кода или реализации? Не думаю.) несколько реализаций и покажите нам всем, что лучше, к чему попусту учить меня культуре программирования? Я признаю, что с XML дело не имел, поэтому если Вы мне докажите, что преимущество готовых классов очевидны(в контексте именно этой задачи, а не в целом, потому что я всё это говорю относительно данной темы), то я соглашусь, что в данном случае лучше использовать их.



Я со своими задачами в этой области справляюсь, поэтому оставьте намёки при себе. 

Это сообщение отредактировал(а) BUGOR - 24.9.2006, 15:47

Исходни весит 10-20кб в зависимости от сложности файла (полнофункциональная работа в XML базой), если только чтение то -20%, урезка по ненужным полям тоже пропорционально снижает; dcu примерно в 1-2 раза больше исходника (чем больше исходник тем относительно меньше dcu); вносимый в проект код 5-10кб.
Беблиотека TRegExpr: 150кб исходник; 60кб dcu; размер кода в проекте не мерял.

Цифры косвенные. Мерялось время загрузки и формирования в оперативке некоторой структуры записей. Так при использовании TRegExpr процесс занимал порядка 40-45сек, на стандартном делфяшном (микрософтовском) парсере укладывались в 3 сек. (при использовании парсера из поставки Jedy процесс разбора XML файла 25Мб занимал 120сек.)
Универсальный алгоритм не может работать быстрее специализированного.

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

А это не в Вашу сторону сказал. Это скорее просто сотрясание воздуха. Просто часто попадаются программисты коротые решают поставленные задачи такими методами, что слов нехватает остается только молчать.
По поводу описания и разъяснений я подумаю о написании статьи. Если тема актуальна конечно.

PS: я знаю далеко не все (точнее сказать пости ничего), но стараюся прежде чем задавать вопросы (или советовать) изучить проблему.
Если чем обидел то приношу свои извенения.

Интересно, неужели универсальны класс для разрбора xml весит так мало? Судя по структуре XML он должен вешать не меньше TRegExpr.



Зато я померил и говорю, что это 18 Кб) 



ВОТ, именно поэтому-то я и предложил инвидиальную реализацию, просто не думал, что TRegExpr даст проигрышь(хотя опять же в данном случае не факт). 



Но опять же универсальность будет тормозить весь этот процесс. 

Здесь нет юниверсальности, структура классов и интерфейсы генерируются под конкретную структуру файла.

Положа руку на сердце скажу: "В данной конкретной задаче победит pos + copy + delete." 
Конкретная ситуация, конкретное решение, максимум скорости (особенно если оптимизированные функции использовать).