Перехватить выход из поля ввода #793823

Здравствуйте! 1С 8.2, УТ 10.3 Я правильно понял, что если в Поле ввода ничего не изменялось, то перехватить событие покидания этого поля невозможно? События ПриИменении и ОкончаниеВводаТекста возникают только если что-то менялось. Опишу ситуацию: В поле ввода оператор вводит некую комбинацию чисел. Я отлавливаю событие ПриИзменении и проверяю введенную комбинацию на правильность. Если найдена ошибка, я выдаю сообщение об этом и возвращаю курсор обратно на поле ввода. Но если после всего этого оператор не исправил ошибку (ничего не изменял в поле ввода), то дальше 1С уже позволяет покинуть поле ввода, так как не происходит ни событие ПриИзменении, ни ОкончаниеВводаТекста (((( Как думаете - есть выход? Сталкивались с подобным? Заказчик программы четко указал, что проверка на правильность заполнения должна происходить в момент покиданияполя. В других языках программирования (не 1С) такая возможность предусмотрена.

в поле ввода ты это ни как не сделаешь. По этому корректность данных надо проверять еще раз отдельно в обработке проверки заполнения. Обработка проверки заполнения - обеспечивает корректность данных, которые записываются в базу. Любые проверки в форме - помогают пользователю не накосячить. Перемешивать одно с другим - плохая идея. Хотя бы потому, что объекты могут создаваться и без формы, но корректность этого надо обеспечивать точно так же, как и при заполнении из формы.

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

>чтобы оператор не переходил к заполнению следующего, пока не исправит текущее такие вещи делаются мастером заполнения с кнопкой "Далее". Но это превращает интерфейс системы из просто недружественного в откровенно враждебный и человеконенавистнический. Не надо так делать.

Непонятно только в чем разница между событиями ПриИзменении и ОкончаниеВводаТекста. Они возникают в одной и той же ситуации. Бессмыслица.

для ссылочных данных - в разной. ПриИзменении стреляет после того, как ввод по строке подобрал значение из базы, а ОкончаниеВводаТекста - до. Текстовые поля - частный случай, там оно одинаковое, да. Но это не бессмыслица.

Лефмихалыч, Вы, конечно, сочтете меня грубым извращенцем (хотя по моему твердому убеждению извращений существует лишь два: балет на льду и хоккей на траве, а все остальное, это виды удовольствия), но я нашел вот такой выход: Shell = Новый COMОбъект("WScript.Shell");

убей себя :)

Обычные формы, я правильно понял? В поле ввода можно маску задать. И это просто диалог на форме, или поле таблицы? Есть у формы также метод, по-моему "ОбновлениеОтображения" - можно с его помощью выкрутиться.

*метод = событие

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

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

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

что-то вы читать не умеете. Какой вопрос, какая форма? чушь написали с умным видом. осуществляется выход из Поля ввода. Мне надо, чтобы при выходе обязательно осуществлялась проверка на правильность заполнения. при выходе событие происходит только если в поле ввода были изменения. я эти фиктивные изменения делаю.

Это не чушь, это ты дальше носа не смотришь. Если пользователь откроет существующий объект, в котором значение поля не корректное, и тыкнет в поле ввода, то единственный способ закрыть форму объекта для его - это срубить процесс 1cv8.

а некорректное поменять на корректное

откуда там возьмется некорректное значение? Ему там взяться в принципе неоткуда. Его может ввести только пользователь. Если же пользователь введет некорректное значение (для чего вся проверка то и затеяна), то ему на ошибку указывается и предлагается либо исправить ее, либо стереть все поле целиком. Задача выполнена. А  h-sp вообще какой-то бред написал. Какое сообщение сохранить? У вас в каждом поле ввода после изменения спрашивается сохранить ли введенное значение? Ну, мне жаль ваших пользователей. Какая форма модифицированная, если речь идет только о данном конкретном поле ввода? Мальчик в MSAccess пересидел в детстве слишком много, если не может абстрагироваться от того, что форма используется только для ввода какой-то записи Базы данных и при изменении данных внутри  формы надо спрашивать о необходимости сохранить их в БД. Формы много для чего можно использовать. И да, Лефмихалыч, я старше вас раза в два (просто в 1С недавно), но не считаю трудным обращаться вежливо.

какая разница - откуда? С обменом придет. Со временем изменятся требования, код проверки ты доработаешь и 10% существующих объектов станут некорректными. При твоем подходе, если ты забудешь исправить данные или не успеешь, то у пользователей будет отказ сервиса - открыть можно, а закрыть нет. >И да, Лефмихалыч, я старше вас раза в два ну, давай длиной заодно померимся... календарный возраст в данном случае не имеет ни какого значения. Значение имеет опыт, который, если бы был, ветки бы не было. И вот это "Формы много для чего можно использовать" - смешная сентенция. Когда формы используются для чего-то, кроме UI, стоимость развития продукта растет экспоненциально с каждым обновлением и в конечном итоге становится проще сделать новый продукт, чем в этом что-то изменить.

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

да и - далеко не в два. 13 лет всего. После 20ти это не разница ни какая.

ну,ладно, - после 30

ЭТО НЕ ДОКУМЕНТ! Это форма для того, чтобы оператор мог принять у клиента ставку СпортЛото. Шесть полей. В каждом поле можно заполнить (а можно только в одном или в нескольких) комбинации. Комбинация состоит из нескольких чисел. Количество чисел может быть разным, он зависит от игры. Допустим, если игра 5 из 36, то чисел не может быть меньше 5, логично? И верхний предел количества чисел тоже есть (не 36, меньше). Сами числа должны быть в диапазоне от 1 до 36 и неповторяющимися. никакого документа нет. Клиент протягивает оператору заполненный бланк ставки. оператор заполняет те из 6 полей, которые заполнены клиентом в ПУСТЫХ полях. При заполнении каждого поля, ЗАКАЗЧИК ПРОГРАММЫ хочет проверку на вышеизложенные требования (ну я их очень коротко изложил, там еще есть автоматические ставки и другие требования, лень их тут описывать). Если все правильно заполненно, программа посылает HTTP-запрос с комбинацией на сервер ГосЛото и получает сперва сумму стоимости ставки, а затем второй запрос на регистрацию ставки. Все, никакой документ, который мог бы вызываться в будущем для редактирования, при этом не создается, создаются только оправдательные документы для 1С - РеализацияТоваровУслуг (с заполненной Услугой) и ПКО, но это к сделанной ставке имеет только касательное отношение. Значения заполненных полей стираются и НИКОГДА больше не понадобятся, а если понадобятся, то только для распечатки квитанции, только если ставка зарегистрирована. Это уже другая история, откуда брать данные для печати (квитанцию формирует сам сервер ГосЛото), и никакие проверки уже не проходятся - ставка принята.

и да - если Вы живете не в Казани, если у вашей фирмы большая (сотни) сеть мелких торговых точек, если Вы захотите стать распространителем лотерей ГосЛото (СпортЛото, Русское Лото, ГЛЖ и т.д.) и у вас 1С 8.2 УТ 10.3, то обращайтесь, договоримся. у меня программа почти готова, доделываю мелкие замечания )))) Когда я тут писал - ЗАКАЗЧИК, я имел в виду не свою фирму, в которой я тружусь, а ГосЛото. Потому что они предоставляют только формат HTTP-обмена с их сервером, но также и предъявляют определенные требования к интерфейсной части. И пока ОНИ (ГосЛото) не примут мою программу, наша торговая фирма не получит доступ к распространению лотерей. Уже два просмотра прошли, почти все готово, осталось исправить мелкие замечания.

не давать выйти из поля - это фашизм. Причем не нужный совершенно, раз полей всего 6. Эи все проверки нужны на первое время, пока пользователь обучается, в дальнейшем операторы будут, не глядя, лупить правильные значения. Лучше сосредоточить на порядке обхода и всяких хоткеях, чтобы пользователю не нужна была мышь. А еще лучше - придумать решение, чтобы клиент сам на каком-то тачскрине набирал свои данные. Гораздо лучше. Тачскрину зарплата, отпуск, больничный и декрет не нужны.

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

Фашизм как просьба ЗАКАЗЧИКА. Мы только собираемся распространять лотереи, а сама фирма ГосЛото сделала это во многих фирмах и во многих городах. Им виднее, я считаю

то, что заказчик и то, что он реально - это чаще всего две большие разницы. Здесь он, скорее всего, хочет, чтобы данные были корректными, а выражает это в форме технического решения "сделайте, чтобы выйти из поля ввода было нельзя". Делать то и только то, что заказчик - себе дороже. Потеряешь или время, или репутацию, а то даже - то и это одновременно. Но, ты же вдвое меня старше, так что я этого всего объяснять, пожалуй, не буду.

Анализ ЭтаФорма.ТекущийЭлемент в обработке ожидания

Отклоняться от темы не нужно.

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

Сдать проект, а не "сать" )))))