Total Commander

Skif_off
Может плагин ждет %temp% с слешем а у тебя слеша нету.

Alextp писал(а):Может плагин ждет %temp% с слешем

И это странно, вроде дефолтное значение тоже без слеша. Запускал set - только в значении PowerShell'овской переменной есть конечный слеш. Непонятно...


А нет ли в планах научить OdfToTxt юникоду (UTF-8)? Или что-то подобное уже есть?

ВИжу исходник и там ошибка- нет слеша правда, просто
клеится c:\temp + Txtsrch.txt. Поправить надо.

Какую именно версию XDoc2txt мне взять?

Alextp
Наверное, до WinVista это не было проблемой, а после в корень системного раздела так просто не напишешь?

Насчёт xdoc2txt не знаю, что сказать, выше Mailk писал, что с 2.x у него работает.
2.х в отличие от 1.х поддерживает юникод и развивается (в 1.х автор правил только несколько критических багов), но поддерживает только Win2k и выше + требует Runtime-библиотеки Visual C++ 2010 (до 2.12 - Visual C++ 2008).
Наверное, лучше 2.х, совместимость с 1.х для желающих ведь никуда не денется? К тому же можно будет использовать один exe'шник и две dll'ки совместно с PCREsearch.

Добавлено спустя 2 минуты:

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

Тогда это все -надо брать 2.х, раз развивается. todo.

Добавлено спустя 2 минуты:

Винду7 счас будут забывать, вон новость, что на нее патчи ставятся но не помогают уже.

Alextp
Спасибо, будем ждать.

Все эти предостерегающие вопли о Win7 производят впечатление скорее маркетинга... И MS наглядно демонстрировали и свои возможности, и беспардонность.

все это переписано (еще не все) на Лазарус.
Лаз я уже отлично знаю...
В процессе какие-то куски кода которые были кровью и потом написаны и трудно отлажены на низком уровне ВинАпи - выкинуны нафиг,в Лазе есть уже. Например "читать файл в строку" есть просто как обычная ф-ция в лазе. Но тут вылезает то что в Лаз другая кодировка имени файла. А была ansi.Но все равно переделать нетрудно.Х64 в Лазе легко.

Beta1.50
http://uvviewsoft.com/bb/wdx_TextSearch.zip

Хотел было использовать плагин для переименования текстовых файлов в ИГП, используя данные плагина, но увидел, что нету возможности, поля просто нет. Нет ли в планах добавить?

Alextp
Файл на сервере по указанной ссылке не найден.

BeardFury78
Как можно использовать плагин, если, грубо говоря, плагин возвращает только true или false?

Avada
И не должен быть найден, т.к. уже зарелизен, а в http://uvviewsoft.com/bb/ всегда лежали временные бета- и тестовые версии.

Может кто-то подскажет в чём проблема...
Надо найти в файле xps (Ссылка) слово, например, Примечание

В TextSearch.ini пишу код: Произвожу поиск:

и ничего не находит.

Пробую найти слово,например, My Folder

и слово находится.
Проблема поиска латиницы.
Внутри файла xps, находятся файлы fpage (xps.xps\Documents\1\Pages\1.fpage) и в них находится искомый текст. Кодировка файла 1.fpage UTF-8, без BOM.

Проблема поиска в utf8. В коде идет возврат типа FT_FULLTEXT.
вопрос - если сделать _еще_ и возврат FT_FULLTEXT_W (есть такой тип? где дока?)
то тогда юникод должен искаться?
Надо удалить поддержку FT_FULLTEXT?

Добавлено спустя 10 минут:

в доке Content-Plugin Guide
2.1se 2011/09/07
инфы не нашел.

Alextp
Есть ft_fulltextw, на оффоруме обсуждалось. ЕМНИП, то же, что и ft_fulltext, но только в UTF-16LE, как ft_stringw. Кажется, первым добавил автор xPDFSearch, milo1012 ещё участвовал в дискуссии.

Так понимаю, если использовать только вместо ft_fulltext, то будет сломана совместимость с предыдущими версиями, будет работать с TC9+?

И как делать, заменять поле ft_fulltext --> ft_fulltextW ?
или как.

Добавлено спустя 2 часа 16 минут:

заменил на тип fulltextW.
Бета 1.6, попробуйте, у меня ищет рус буквы, китайские не тестил.
http://uvviewsoft.com/bb/wdx_TextSearch.zip