Есть куча ворд документов для каждого сотрудника.
Пример верхней части в приложении.
Нужно достать фоксом содержание 3 объектов
фио, дата рождения, паспорт.
Не пойму, что это за объекты, те как их определить и опознать программно в фоксе
Это не букмарки. Пробовал понять по макросу, изменяя содержание одного
из объектов, ничего не дало
Пишет
selected.texttype text = мои изменения.
Показывал системщику
Вроде объект фамилии дает
selectted.name .... text box 11
Вроде теплее, но внутри activedocument
коллекции textbox не видно.



Исправлено 1 раз(а). Последнее : boba, 10.05.17 10:59

application.ActiveDocument.Shapes(3).TextFrame.TextRange.Text && Умная Василиса...

Откуда зялось Shapes(3).?
и как брать адрес других двух обхектов-дня рождения и паспорта?

Что значит откуда Shapes? Кто-то создал... их там 7: (1), - ИНН (2) - СНИЛС, (3) - ФИО, (4) - д/р, (5) - сер.ном.док, (6) - тип док. ...
Если что, то это просто результат экспериментов в окошке Immediate

Вордовые документы создает чужое приложение на Дельфи-Оракл.
Каждый документ создается на базе одного и того же шаблона Word.
Я раньше имел с таким дело, но там в отчетах нужные для вбивки выражения помещались в букмарки. Поэтому всегда однозначно можно было определить, что и где лежит просто по
имени букмарки. Здесь нужно обработать целую директорию вордовых документов от упомянутого внешнего приложения в обратном направлении в фоксовый курсор. Собственно это нужно потому, как появились сомнения в том, все ли люди обработаны.
Я не понимаю, где гарантия того, что shape с конкретным номером содержит именно то поле,
а не другое. И как вы узнали номер этого shape

Если эти надписи именованы (например, Shapes(3).Name = "Text Box 11"), то можно обращаться так:
? application.ActiveDocument.Shapes("Text Box 11").TextFrame.TextRange.Text
Но разработчик шаблона документа должен сказать, что имена полей всегда будут вот такими.
"Узнал" путем экспериментов в окне Immediate )

Спасибо за ответы.
К моему сожалению все оказалось гораздо хуже.
В одном вордовом реальном документе, а не том, что мне дали посмотреть сначала,
не один, а несколько человек ( до 100). Для одного человека после его общих данных идут куча таблиц
с разными платежами.
Потом уже другой человек итд.
Фактически нужно идти циклом в поиске на
Фамилия, Имя, Отчество ( это просто часть текста не shape).
Потом каким-то образом определять номера последующих 4 shapes,
где сидят страховой номер, фамиляи имя отчество, день рождения и паспорт.
К сожалению, от отдного человека до другого не существует постоянного
шага, коорый дает вычислить номер shape для
фаммилии одного человека по номеру shape
другого. Сами shapes внутри ни в каком свойстве не
имеют пометки типа имени тега, который позволет по
нему определить, что там именно лежит- фио
или паспорт или день рождения или что-то другое.
Даже не обратная задача.

Можно вот так поступить:
- прочитать последовательно все Shape документа (в таблицу с C-полем, и полем ТИП)
- проанализировать каждое значение на предмет: ФИО, дата, № паспорта, СНИЛС
(например, 2-4 слова, причем только буквы и тире - значит ФИО,
цифры и точки в количестве 8(6) и 2 - значит дата...)
проставить результат детектирования в поле ТИП
- посмотреть в BROWSE на получившуюся табличку, может будут видны стабильные группы (последовательности содержащие ФИО) - значит данные можно считывать вокруг каждого поля ФИО, не вычисляя шаг между группами

Так и делаю.
Ничего не выходит
В документе на 100 человек число шейпов за 8000
Там полно относящихся к деньгам, таблицы, где есть шейпы итд
Такой перебор, как вы пишете , пробовал еще вчера.
Работает жутко медленно. Цикл по всем шейпам до shapes.count идет больше часа. А файлов таких штук 100
Сегодня пытался как с екселом прочитать сразу диапазон
шейпов в массив фокса чтобы как-то это ускорить.
Не выходит. Толи вообще это невозможно, толи я диапазон пишу как-то не так.
Файл явно получен в Дельфи с помощью какого-то генератора отчетов на шаблоне ворда.
Сам файл шаблона ворда доступен. Но толку от этого ноль.
Если бы заготовки под поля из шаблона перенесли хотя бы в коменарии шейп или какое-то другое доступное свойство, это бы решило задачу. В шаблонах никаих шейпов нет, текст типа //varname/. Но увы. Все просмотрел, никаких признаков поля родителя в шаблоне. Скажем, shape(10).lternativetext = 'полпись Премудрая Василиса..
Все это относится к налоговой отчетности. Сам софт куплен, но на деле для этого отчета практически висел сутками или вылетал по памяти уже в ворде. Народ переделывал его на скоку чуть ли не ночами чтобы успеть в срок.
Конечно не догадались в месте вывода в ворд кинуть еще в какую -нибудь временную таблицу на Оракл. Пересчитывать сейчас нереально, расчеты с выводом в ворд заняли больше недели с вечерами. Эту же отчетность сдавали в xml. На хрена были нужны ворды, которые в налоговой сможет прочитать только человек, непонятно.

Это справка 2-НДФЛ, вероятно. Зачем было делать в верде действительно непонятно. Обычно ее сдают в электронном виде, в файле XML. Может есть этот файл XML?

of63
Это справка 2-НДФЛ, вероятно. Зачем было делать в верде действительно непонятно. Обычно ее сдают в электронном виде, в файле XML. Может есть этот файл XML?

Так DOCX и есть XML. Переименуй в ZIP, распакуй и анализируй. Только в налоговую не посылай, не примут.

Нет, не 2 ндфл.
Нечто, называющееся налоговый регистр.
Ужасный монстр с итоговой таблицей в верху, по несколько
промежуточных таблиц на каждого человека, где данные есть и помесячно,
и еще как-то в зависимости от вычета или возврата.
Ворд, оказывается, был нужен живым проверяющим людям из налоговой для печати
и просмотра.
Это независимо от xml, который электронно сдавался в налогувую за прошлый год.
А тут была нужна печатная отчетность за 5 прошлых лет.

Да, действительно, в папке DOCX->ZIP в разделе word\document.xml комплект фИО и шейп вроде бы обьединены в один блок. Структура только заморочная

я сделал тоже самое для реального файла (xml)
Студия просто открывала его 8 минут,
xml editor показал просто черное окно без ничего
Ворд пад открыл, но толку в этом никакого,
фоксовая читалка начала читать и
до сих пор не кончила. Слишком уж большой файл.



Исправлено 1 раз(а). Последнее : boba, 11.05.17 11:09

Штатный открыватель XML (который в эксплорере тоже используется) больше 5-10МБайт не "откроет" практически. Надо что-то попроще, типа "SAX" который будет последовательно читать файл на низком уровне, и "поставлять наружу" только нужные тэги. "Фоксовая читалка" - это такая? или тоже сделана на XML-адаптере?

Доб. Видно по памяти, занимаемой процессом - если за 0.5Г лезет, значит DOM строит, можно дальше особо не ждать )



Исправлено 1 раз(а). Последнее : of63, 11.05.17 11:27

xml фоксовых самописных читалок у меня несколько
Две по хелпу через strextract . Код из хелпа только чуток поправил на раздрай вннутренних тегов типа < aaa фамилия ="Неизвестный"
Первая просто пишет курсор из двух полей- имя тэга и его содержание
Потом уже идет программа вторичной декодировки такого курсора на нужный широкий курсор
Так читал пенсионный и справочник банков с вэбсервиса ЦБ
Еще частыне виды читалок на той же функции, которые написаны под выдирание
частных тегов из выбранных файлов.
Такие каждый раз пишу по-новой .
И наконец, через dom
Упомянутый файл все долго читают, даже просто
едят его в память очень долго.
xmladapter со схемой , сделанной Студио или sql server
раньше тоже пробовал, делает прорву курсоров ( 16 и более)
без общего ключа связки. Поэтому для пенсионной и налоговой отчетности не
пользую.
С упомянуым в самом начале файлом xml никакого выигрыша по скорости не дал.
Так и не понял, почему через shapes.range не могу вытащить на фокс нужную область прямо в массив, как делаю это в екселе.

А если сначала средствами верда сначала удалить явно ненужные элементы (таблицы, например), а потом читать получившийся файл. Может так будет быстрее...

Какого размера файл documentXML получается?
Как вы читаете в массив Shapes.range ?

так?
DIMENSION A(100)
A = .Shapes.Range(?).Value

на value вообще вылетае оле ошибка
Пробовал по-разному, .alternativetext
Удаление таблиц наверное поможет отчасти, но и без таблиц там других шейпов полно
размер documnents.xml 105198 kb
Прямое чтение шейпов из ворда явно быстрее чтения и разборки xml



Исправлено 1 раз(а). Последнее : boba, 11.05.17 15:07

boba
Прямое чтение шейпов из ворда явно быстрее чтения и разборки xml

Это смотря как их читать...

Для тех файлов, что мне нужно обработать, это так
Речь не идет о прямом xml , а о том, что получен из ворда
анзипом. У меня таких файлов сотни, нужно было написать конвеер, чтобы разархивировать их в отдельные
директории, иначе файлы накрывали друг друга.
Дальше банальный хронометраж показал, что команда открытия файла в ворде после createobject(word.application)
быстрее, чем filetostr xml от этого ворда, аналогично и с курсорадаптером со схемой loadxml
еще тише. Далее, разборка такого xml ничуть не выгоднее, так как там нет смысловых тегов, так же, как и в исходном
документе ворда.