Большое спасибо за идею .
Доработал под поиск по всем реквизитам, поиск идет по текущей колонке - то есть если в быстром поиске ввели строку и стоим в колонке имени - будет искать с таким именем, возможность выводить определенные колонки в обработке поиска, пропуск неправильных реквизитов, по которым поиск невозможен (неопределенный и тп), обработку Даты в поиске.
+работает у меня с SQL базой, поэтому для DBF нужно будет менять.

а зачем? обработочка то совместима, как раз кайф - без переделки старые места заработают быстрее. единственно, я там таблицу результата вынужден стал заполнять старым методом - через НоваяСтрока(), можно было бы по уму запрос SQL преобразовать так, чтоб он готовую уже возвращал... но на самом большом моем справочнике максимум работает 2,5 секунды в результате, так что возиться не стал

ага. ну в этих целях понятно

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

+ думаю может добавить галчонков, для подбора и Мн.Фильтра 

Версия: 1.1  

unnamed
потестируй пожалуйста на SQL 

ps
галчонки будут в 1.2

2. При открытии формы и последующем в нем поиске, а затем нажатии "Включить отбор" происходит ошибка, в тексте запроса при этом:

SELECT ,$Спр.Элемент as [Элемент $Справочник],$Спр.Наименование as Наименование,$Спр.Артикул as Артикул,$Спр.Данные as [Данные $Справочник.ДанныеТовара],$Спр.Код as Код
FROM
     $Справочник.Номенклатура as Спр
WHERE
   Спр.IsFolder = 2 AND  UPPER(Спр.Descr) LIKE '%АРИЭ%' ORDER BY Спр.DESCR
ТЗ = ОлеДБКоманда.ВыполнитьИнструкцию(ТекстЗапроса);
{E:\1CDATA\TANDEMNN\EXTFORMS\POISK.ERT(172)}: Meta name parser error: поле таблицы не найдено "$Спр.Элемент"

Если после этого нажать снова Поиск, выскочит схожая ошибка:

SELECT ,$Спр.Элемент as [Элемент $Справочник],$Спр.Наименование as Наименование,$Спр.Артикул as Артикул,$Спр.Данные as [Данные $Справочник.ДанныеТовара],$Спр.Код as Код
FROM
     $Справочник.Номенклатура as Спр
WHERE
   Спр.IsFolder = 2 AND  UPPER(Спр.Descr) LIKE '%АРИЭ%' ORDER BY Спр.DESCR
ТЗ = ОлеДБКоманда.ВыполнитьИнструкцию(ТекстЗапроса);
{E:\1CDATA\TANDEMNN\EXTFORMS\POISK.ERT(172)}: Meta name parser error: поле таблицы не найдено "$Спр.Элемент"


При первоначальном открытии и выполнении "Включить отбор" такого не происходит

Проблема была в функции ДобавитьПоля:

           Если ПКолонка="элемент" Тогда
                 ТекстЗапроса=ТекстЗапроса+"Спр.ID as [Элемент $Справочник."+ВидСправочника+"]";

заменил на мелкие буквы в алиасах.

3. Не работал поиск из формы по моим кнопкам в старом стиле, где я не заполняю глобальную переменную

4. закомментировал сигнал() на не-ошибках

я добавил в твою обработку "мои" кнопки ) и изменил ту часть где ШаблонПоиска берется непосредственно из Конт.

в этой обрабтке все что я описывал починено

PVR писал(а) 28. Мая 2008 :: 05:40:


вот 3е потому и не работало, что 4е в твоем варианте она передается кнопочкой в списке значений, а я его не передаю (я не использую глОбъект), в моей кнопочке в формуле всего лишь тескст: глПоискПоПодстроке(Контекст,"","ДопПараметр");

Да нет же. Я давно переписал гл процедуру. Как твой вариант будет работать, если ему неоткуда брать Шаблон поиска? Ты в своих кнопках его передаешь через список значений, а в моих кнопках этот список значений не используется, в глобальной функции Шаблон никуда не передается, в обработке у тебя он тоже из Конт. не берется - то есть работать Поиск по шаблону будет только при использовании твоих кнопок, которые используют глОбъект.

у меня есть кнопочка Шаблон в форме. И кнопочка Отбор там же есть, я про кнопочки в форме справочника. Но формулы у них "в старом стиле", без использования глОбъекта. я смысла не вижу его заводить или динамически создавать, если можно одной строчкой в обработке добиться того, чтобы работало, беря шаблон поиска непосредственно из контекста вызывающей формы, а длинные формулы в кнопках мне не нравятся (не нужны). копировать проще по справочникам - менять несколько параметров и все. по длинным же формулам долго перемещаться курсором, чтобы найти место, которые нужно заменить (список отображаемых колонок). Вот мои аргументы (с) кот Матроскин
В последней обработке которую я выкладывал я кнопки в своем "старом" стиле прицепил - там Шаблон поиска присутствует.

Ps. Про отбор из формы обработки понятно, что он по внутреннему реквизиту будет работать, эт логично

ну вообще конечно и по нрег( проверять можно, но насчет бага тоже может быть...

artbear писал(а) 28. Мая 2008 :: 06:58:

Так эта обработка и есть тест  

На OLEDB:
"Спр.ID as [Элемент $Справочник."+ВидСправочника+"]"

ТЗ = ОлеДБКоманда.ВыполнитьИнструкцию(ТекстЗапроса);
в ТЗ <ИдетификаторКолонки> = "элемент"

http://www.1cpp.ru/bugs/show_bug.cgi?id=3876
для тестов:

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

все нормально работает.
йэх, жаль Formex в модальных окнах не перехватывает изменение размеров окна и процедура ПриИзмененииРазмераОкна( ни локальная, ни глобальная не работают... даже если кнопку разрешить или принудительно окно "размодалить".
так бы можно было maximaze ему приделать, а то табличка маленькая и не расширить...

Добавлена функция максимизации/минимизации окна. Работает, если уже загружена или может загрузить formex.dll

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

Может кто-нибудь у кого будет свободное время, знания прямых запросов и 1С, допишет поиск/отбор по перечислениям, периодическим значениям, диапазонам дат и  чисел 

spock писал(а) 29. Мая 2008 :: 14:25:

А с помощю 1С++ никак починить не получится 
Может через Ж, при проходе парсера запомнить, а при создании ТЗ или ИТЗ создать из запомненного 

unnamed писал(а) 30. Мая 2008 :: 18:46:
А если он нечестный, может направить на путь истиный  

unnamed писал(а) 30. Мая 2008 :: 18:46:
Несчастные программисты, столько времени и сил тратят на «crappity smacked vfpoledb provider behavior»  

Может знатоки VFP знают, как его вылечить   

может проблема на пустом месте?
Чего такого, что колонки в нижнем регистре получаются?

Мелочь, конечно, но неприятно

под SQL работает .

прикладываю версию 1.2 с максимизацией окна

PS. На будущее предлагаю кнопки переименовать в форме поиска: первую "Выбрать" назвать Показать (она же фактически устанавливает курсор на нужном элементе в форме выбора справочника, а третью "Выбрать ВСЕ" переименовать в "Выбрать", потому что она в случае выделенных элементов при множественном подборе приводит в смущение - фактически она только выделенные выбирает, а создается впечатление, что все найденные и ищешь, где же кнопка выбрать выделенные - нажимаешь в итоге "Выбрать", что приводит к другому результату

У меня странный баг нарисовался  

В монопольном режиме ТиС 9.2 вер.950 DBF, спр. Номенклатура поиск по наименованию:
Цитата:

В разделенном режиме всё ОК.

Протестируйте у себя, пожалуйста  

PS
В разделенном режиме, этот код не выполняется идет на OLEDB 

Все здорово На следующую версию кнопочке "Выбрать" нужно будет какой-нить &горячий кей-таки дописать

Да хоть и &В

Начал тестировать на поиск Числа и Даты, на Запрос1С и OLEDB.
Сразу возникли различия и неточности в реализации.

Хочу взяться за правку и не знаю, в каком варианте делать поиск:
Вариант 1: точное сравнение значений (не нравится).
Вариант 2: поиск как в строке (нравится больше, уже реализовал, почти).
Вариант 3: возможность при поиске указывать режимы =, >, <, <>, диапазон (даже не знаю, вроде тоже может пригодиться).

Какой вариант нравится Вам?

unnamed писал(а) 04. Июня 2008 :: 03:43:
Да 3 вариант для пользователей слишком сложный 
Насчет обработок и отчетов, в любом, где есть множественный подбор из справочника, работает такой поиск
Да для журнала не хватает, может когда-нибудь появится

Unnamed, у тебя пользователи вводят дату 13.01.2008?
Как они отнесутся к 20080113?

Вариант 2 для VFP (но как сделать аналогично для 1С и SQL!?):
2008 поиск по году,
______13 по 13 числам,
____01 по 1 месяцу,
1 3 просто по дате, где встречается 1 и 3,
2008__15 по всем месяцам 15 числа 2008 года,
200801 все числа 1 месяца 2008 года.

Будет так: 13.01.2008 - обычный поиск
15.*.* - по 15 числу
*.1.* - по первому месяцу
*.*.2008 - по 2008г
15.*.2008 - по всем месяцам 15го числа 2008г
*.1.2008 - все числа 1го месяца 2008г

unnamed писал(а) 04. Июня 2008 :: 10:09:

, решил что удобнее парсер с "*"

работает
правда, год получается задавать только в 4х значной форме. лучше когда год формируется, преобразовывать его через Год = ДатаГод(Дата("01.01."+Год))

и в результатах поиска колонки типа Дата изображаются не в привычном 1с-виде, а SQL-like YYYYMMDD (смотрел справочник сертификаты номенклатуры с выводом колонок срок действия с... по, не помню с типовой это или нет)

Учел пожелания + условия <,>,<>,= 

unnamed писал(а) 05. Июня 2008 :: 06:49:
забыл убрать
СтрЗаменить(команда,"=>",">=") а везде ли так, посмотрю.
Еще один баг - внутри SQL пустая дата как 01.01.1753, на DBF пустая  , тут я 

кстати, хорошо бы предусмотреть поиск пустой даты. часто бывает нужно незаполненные поля справочников отслеживать. типа условие по дате ='' или <>'' (ну или "" соот-но)
1с да, не понимает, я как на него пересел, вечно по этому поводу синтаксическим помощником пользуюсь когда ввожу

стразменить(команда,"''","01.01.1753")

unnamed писал(а) 05. Июня 2008 :: 07:56:

Поясни,
указывая '' (кавычка) заменяем на пустую дату?

Добавил опциональное добавление колонок для показа в поиске / удаление их, сортировку как от А до Я, так и наоборот. Вызывается правой кнопкой мыши на заголовке колонки таблицы.

PS. Была ошибка ранее - если передавалось как необходимое поле для показа данных типа справочник, длина его представления всегда бралась как 0, сейчас берется по длине представления.

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

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


ps. если сегодня вечером с делами разберусь то завтра может все и объединю с последней твоей версией...

Пока вот, но ты порушил немного 
поправлю, выложу Релиз

пробуй <>'', <>"", ="", =''

Цитата:
с этим помочь не могу 

Цитата:

все условия через AND, >=*.*.08 <=*.*.09

PVR писал(а) 05. Июня 2008 :: 13:43:


Проверю на работе
теперь по пунктам
AND не столько нужен, так как его можно реализовать через ту идею, что я раньше говорил - оставляем текущую уже таблицу выбранную и новый поиск присоединяем к текущей, интерфейсно решается легко, сделаем. вот OR нужен хотя, конечно, я вначале говорил, что пользователям эт в большинстве случаев... но что-то у меня предчуствие, что из этого потом дальше получится интереснее штуковина еще и к документам и журналам прикрутим.
насчет того, что не можешь '01.01.53' заменить - очень даже можешь, в случае SQL добавить CASE при поле даты... внутри SQL запроса прям.

зы. насчет соавтоарства. а что, я согласен ) перед отпуском-то ))

OPS. Насчет OR понял
>все условия через AND, >=*.*.08 <=*.*.09

гмм... вот интерфейсно OR по разным атрибутам решить пока не представляю как

Зы. а хорошая штука получается аж для души.

В ТП при подборе не показывались галчонки, исправил.
Доработал совместимость работы без 1С++ (без ТЗ, с 1с++ ТП).

Цитата:

Информационный Центр - Посмотреть 10 последних сообщений этого форума.

Цитата:

Ок

Исправил, ТП Ширина колонок (задается в пикселях) + мелочи

гмм...
1) при каждой загрузке пишет "1c++ загружен, требуется открыть обработку еще раз". при повторном остается тоже самое. хотя у меня 1c++ в конфигурации грузится.

2) в модуле ЗПриКонтекстномМеню потерялась когда-то я строчку изменял на:
Если (Колонка.Данные<>"Пометка")и(Колонка.Данные<>"наименование") Тогда
(т.к. наименование это у нас Спр.Desc а не $Спр.Атрибут, выпадает)
- сейчас там только Пометку нельзя удалять. Сделал я это из-за того, что в модуле добавления колонок добавление колонки Наименование не работает (возникает ошибка Тип           = МДСправочник.Реквизит(выбор).Тип;
{E:\1CDATA\TANDEMNN\EXTFORMS\POISK.ERT(116)}: Поле агрегатного объекта не обнаружено (Тип)), то есть если мы удалим колонку Наименование - потом захотим ее добавить, будет ошибка. Можно, конечно, проверять на название колонки... но в принципе зачем его удалять может пригодиться, не знаю.

3) при работе почему-то видна стала и 1совская ТЗ, и ТП.

Даты и условия работают, блеск На пустое значение правда только проверка по "" работает - на '' (одинарные) нет. ну в принципе может и не надо на оба-то

4) в SQL сделал чтобы пустые даты изображались по 1совски .

все вышеперечисленное 1-3 тоже поправил.


PS. Делал на основе poisk_14.ert

5) добавил обработку ошибок ODBC, кстати при попытке поискать слово на поле даты выдает ошибку и текст запроса формируется следующий

Ошибка в запросе:
SELECT Спр.ID as [элемент $Справочник.Сертификаты],Спр.Descr as наименование,$Спр.Производитель as Производитель,CASE year($Спр.ДействиеС) when 1753 then null else $Спр.ДействиеС end as ДействиеС,CASE year($Спр.ДействиеПо) when 1753 then null else $Спр.ДействиеПо end as ДействиеПо
FROM
     $Справочник.Сертификаты as Спр
WHERE
   Спр.IsFolder = 2 AND)) ORDER BY Спр.DESCR

+теперь дальше корректно работает в случае ошибки на драйвере без окна сообщений (ТЗ очищается)

6) Добавлено контекстное меню автоширина и ширина по 1с при вызове на скроллере ТП (горизонтальном или вертикальном). Автоширина равнозначна двойному щелчку мыши на разделителе колонок в заголовке ТП при нажатом shift.

Спасибо, что то я ночью наверно перемудрил, сегодня все проверю

А для этого и остался второй пункт, автоширина по 1с - вернуть как было.
Автоширина обычная для того, чтобы все компактно вошло, что на экране есть, не бегать самому по колонкам / расширяя их. в большинстве случаев этого хватит посмотреть информацию, пролистнуть - если там длина данных другая, прийдется еще раз автоширину вызвать, если необходимо. Либо вернуть ширину в 1совскую. Либо сделать автоширину + ручные изменения по длине колонок. Вобщем это уже на усмотрение пользователя, опционально.

PS. колонка пометка в моем случае увеличивается в размерах пропорционально увеличению других колонок, то есть например у меня пять колонок и по текущим данным они все попадают на экран. По идее, автоширина могла все их уменьшить до видимоего минимума, но тогда последняя колонка стала бы очень большой, некрасиво. Вот она их пропорционально и увеличивает. Меня этот момент не очень смущает, главное юзабелити по видимости данных предоставить (по желанию)

Сообщить("Ошибка в запросе:"+Лев(ТекстЗапроса,220),"!"); 

Зачем Лев(ТекстЗапроса,220) !?
У нас текст разбит на строки 

Исправлены баги
Кстати на VFP и 1C, " работает и "" тоже