Snap Search

Возможно, это и так, только я не стал бы заявлять это так категорично, а написал бы "так как, на мой взгляд, без" и далее по тексту… А то, вдруг, не в этом, так в другом случае окажется, что есть и другие варианты…

Алексей, вы знакомы с системой более 14 лет (судя из профиля). Я, пока, не встречал более старого Скала-жителя. Неужели за все эти годы не хотелось сделать то же самое? Мне несколько раз (за мой опыт) уже хотелось, и я сделал на МИФ. Я и сам не люблю им пользоваться, уж больно "притормаживает" систему, но удобства работы в интерфейсе, к сожалению, можно реализовать только на нем. По крайней мере, пока.

На мой взгляд, есть вещи важнее удобства работы в интерфейсе. Это и вышеупомянутая надёжность, и "стандартность" функциональности, и некоторые другие. И я это говорю не потому, что имею опыт более 14 лет (здесь есть участники, которые работают со Скалой не меньше моего), не в годах дело, а потому что почти 7 из них был консультантом. А консультант (опытный, неопытный, напротив, на любой вопрос отвечает "VBA, VBA, VBA") всё время должен помнить об универсальности. О том, что у разных клиентов может быть разное количество модулей (так, например, что ожидаемые поступления-выдачи в модуле УЗ могут быть порождены не только модулями ЗЗ и ЗП, но, например, и МУПр). Что настроенные однажды параметры могут со временем поменяться, а у разных клиентов и вовсе могут быть разными… Я прошёл этот путь ещё задолго до появления VBA, когда Алексей Данилов, мой коллега из киевского офиса Скалы познакомил меня с Titan for btrieve для программирования в среде Delphi. Какое-то время мне казалось, что это долгожданная свобода, пока однажды я не понял, что это, напротив, кабала. Что именно я, написавший "приблуду" на Дельфи несу ответственность за её работоспособность, а клиент, которому я её установил, "попал". Попал от меня в зависимость. А это неправильно. И я остановился. Как мне кажется, вовремя. Да, стандартной функциональностью сделать труднее. Но зато это будет "легальное" решение. А удобство… Иногда им приходится жертвовать… Безусловно, я иногда "дополняю" стандартную функциональность, но стараюсь это сделать так, чтобы по максимуму использовать стандартные механизмы импорта, а не прямую запись в таблицы. В любом случае, что VBA, что любая "приблуда", написанная, например, в Access’е — это кастомизация, создание уникальной, не поддерживаемой хотлайном, версии, зависимость компании-клиента от того "единственного неповторимого", кто это "наваял". Хорошо, если компания может себе позволить держать свой собственный штат таких разработчиков, состоящий из нескольких человек, и очень плохо, если всё держится на одном человеке. Вот и всё объяснение моей просьбы "VBA не предлагать!", ибо, и так понятно, что с помощью VBA это сделать можно и не сложно. Вот только не все клиенты имеют лицензию, во-первых, на VBA Runtime (их число должно совпадать с количеством пользователей, таким образом это довольно недешёвое удовольствие), а во-вторых, как минимум, на Integrated VBA Developer (это дешевле, т.к. можно купить только одного именованного пользователя).

Я не имел в виду проекты заменяющие стандартную функциональность. Речь шла только о проектах, повышающих удобство работы в системе конечных пользователей. Например, вопрос по теме — автоматическая подстановка параметра для "Быстрого поиска". Это никак не повлияет на функциональность, зато сэкономит немало времени пользователям, пытающимся выбрать из массы записей именно ту самую.
Опять же повторюсь, я и сам стараюсь прибегать к МИФ только в крайнем случае. Но в данном случае иного выхода я не вижу.

Последний раз редактировалось: Serj (25.11.2008 17:48), всего редактировалось 1 раз

Нам об этом сказал Юрис Ветринш. Пока тоже не пробовали. По таким вопросам я думаю можно обратится на HL.
_________________
"Я люблю работу, она очаровывает меня. Я могу сидеть и смотреть на неё часами." © Джером К. Джером.

С этого, наверное, и стоило начать, а не заклинать "VBA, VBA, VBA!"

Я попробовал. Только что. Мы ещё не перешли, но тестовая версия, на которой мы тестируем конвертацию и работоспособность накануне перехода с 2.2 на 2.3, имеется. Можно. Но не везде и очень криво. Так, если поле для ввода кода поставщика и поле выбора счёта-фактуры, который мы хотим выбрать, ориентируясь на содержимое поля PL03043, находятся на одной форме, то это возможно (например, при выборе с-ф при вводе счетов-фактур поставщика), а если я задаю код поставщика на одной форме (закладке), а выбор счёта-фактуры из списка на другой форме (например для пункта меню "Запрос по Поставщику и Файлам Книги"), тогда это не работает (По крайней мере у меня не получилось).
В любом случае это уже огромный прогресс, спасибо и на этом! Если будет интерес, как это сделать, готов разобрать на конкретном примере, тогда нужно подробное описание в каком месте и какое содержимое хотелось бы получить/увидеть в результате вызова требуемого быстрого поиска.

Уж не думаю, что DenZ, сидя на Scala 2.3, и, видя кнопку "Параметры" в настройках "быстрого поиска", стал бы задавать вопрос на форуме. Вот я и исходил из того, что стоит версия ниже, чем 2.3.

Ещё про один "подводный камень" слышал. В 2.3, так же как и в 2.2, "быстрый поиск" цепляется не за одно поле формы, а за все схожие поля разных форм. Причем схожесть прописана программерами из Epicor. Таким образом, если на одной форме мы выставим входящим параметром значение одного поля, то на другой форме этого поля может и не быть вовсе, либо называться оно уже будет по-другому.

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