|
Прошлое значение поля ввода | ☑ | ||
---|---|---|---|---|
0
Dirk Diggler
24.12.20
✎
11:54
|
А что, 1С так и не дала возможности узнать в ПриИзменении, а какое значение там было до изменения? Вопросы я смотрю ажно с 2005 г задают...
|
|||
1
ДенисЧ
24.12.20
✎
11:56
|
А что, 1с уже запретила запоминать состояние поля ?
Открыл форму - запомнил. Изменил - запомнил на будущее. |
|||
2
Ненавижу 1С
гуру
24.12.20
✎
11:56
|
а что это трудно организовать самому?
храните в отдельном месте спецзначение, при изменении получайте и сравнивайте спецзначение с новым меняйте спецзначение |
|||
3
Dirk Diggler
24.12.20
✎
11:59
|
Для 4-5 десятков текстовых полей?
|
|||
4
Малыш Джон
24.12.20
✎
11:59
|
(3) Структуру данных давно придумали
|
|||
5
Dirk Diggler
24.12.20
✎
12:00
|
(4) да один хрен решение через одно место. задача-то типовая, можно было бы в платформу уже 20 раз вшить.
понятно короче. будем жрать кактус. |
|||
6
Hmster
24.12.20
✎
12:08
|
Все есть
ОбработкаВыбора Вызывается после осуществления выбора, но до помещения выбранного значения в элемент управления |
|||
7
Dirk Diggler
24.12.20
✎
12:25
|
какой выбор в текстовом поле?
|
|||
8
Малыш Джон
24.12.20
✎
12:31
|
(7) ОкончаниеВводаТекста()
|
|||
9
alkorolev
24.12.20
✎
12:32
|
(0) ОкончаниеВводаТекста
|
|||
10
alkorolev
24.12.20
✎
12:32
|
(8) опередил)
|
|||
11
alkorolev
24.12.20
✎
12:33
|
(9) либо используй описание оповещения и ПоказатьВводСтроки. Возможностей "4-5 десятков"! Непонятно, почему надо завязываться именно на ПриИзменении
|
|||
12
Малыш Джон
24.12.20
✎
12:38
|
(11) >>Непонятно, почему надо завязываться именно на ПриИзменении
Надежнее. Забэкапить значение переменной при открытии и потом при изменнии обновлять и бэкап - это небольшая цена за ломовую надежность способа. |
|||
13
Dirk Diggler
24.12.20
✎
12:42
|
(11) Ну, потому что это методически правильно. Когда не "4-5 десятков возможностей", а один, унифицированный, способ.
|
|||
14
Ненавижу 1С
гуру
24.12.20
✎
12:55
|
есть куда интересней вопрос, почему есть события у элементов формы, а не у реквизитов
при программном изменении в форме надо продергивать события элементов вот уж так себе модель логики |
|||
15
Малыш Джон
24.12.20
✎
13:03
|
(14) Логика нормальная. Событие ≠ изменение значения.
Инструменты надо использовать по назначению, а не микроскопом гвозди забивать. |
|||
16
Ненавижу 1С
гуру
24.12.20
✎
13:05
|
(15) я не говорю, что логики нет
и не говорил, что "событие = изменение значения" но просто в одном слое события есть, а в другом нет то о чем я хочу сказать, это инкапсуляция |
|||
17
acht
24.12.20
✎
13:06
|
(14) Пушо элементы - они на клиенте. А реквизиты они и на клиенте и на сервере. И с воплями "как же они достали" ты сам упаришся пыль глотать при борьбе с контекстами. Ну, например, если найдется клиент-серверный метод, куда передается параметром форма.
|
|||
18
Ненавижу 1С
гуру
24.12.20
✎
13:06
|
(8)(9) а если крестик нажмут?
|
|||
19
Ненавижу 1С
гуру
24.12.20
✎
13:07
|
(17) реквизиты объекта - на сервере
реквизиты формы - на клиенте разве нет? |
|||
20
alkorolev
24.12.20
✎
13:09
|
(18) какой крестик в текстовом поле?
|
|||
21
acht
24.12.20
✎
13:11
|
(19) Счаcтливой отладки:
&НаКлиентеНаСервереБезКонтекста Процедура Метод(Форма) Форма.РеквизитФормы = 1; КонецПроцедуры &НаСервере ... Метод(ЭтотОбъект); &НаКлиенте Метод(ЭтотОбъект); |
|||
22
Ненавижу 1С
гуру
24.12.20
✎
13:14
|
(20) Alt+F4
(21) неплохо, но ведь это только потому что 1С придумала, что формы будут жить на двух берегах? |
|||
23
Ненавижу 1С
гуру
24.12.20
✎
13:14
|
(20) запрещено?
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |