Выделение Protect-полей цветом

[vo]

Признак Protect запрещает редактирование содержимого поля, но визуально этого не видно, пока не станешь на это поле и не начнешь, что-то на нем печатать.
Было бы ОЧЕНЬ удобно, чтобы Protect поля были выделены некоторым образом уже непосредственно на уровне визуального восприятия элемента окна пользователя.
Делать эти поля со свойством Skip плохо, т.к. в этом случае нельзя спозиционироваться на это поле и например скопировать его значение.

ПРЕДЛАГАЮ:
Выделять Protect-поля каким-то образом, например, цветом.

Разработчик считает, что "разноцветные интерфейсы - сомнительная новация"
Что думаете Вы по этому поводу?

[Empyros]

К цветам интерфейсов нам не впервой привыкать...

[vo]

К цветам интерфейсов нам не впервой привыкать...

Из Вашего комментария не понятно, поддерживаете ли вы мое предложение или нет.

[Empyros]

:) Поддерживаю

[poneatovski]

Как я понимаю есть два варианта:
1. Выделить цветом (колонку, поле, содержимое поля, фон поля).
2. Изменить шрифт (полужирный и др.варианты).

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

[Prof]

Кроме того есть проблема визуального определения полей документа, для которых утилитой Protect инструментального комплекса "Support" закрыт доступ на редактирование.
Можно так же выделять такие поля определенным визульным признаком, например цветом.

[vadim]

Может ли кто-то озвучить полностью логически законченную постановку задачи? А также, что побуждило к ее возникновению и озвучиванию?
Каким выделять цветом-то: например, чуть жирнее или тусклее обычного? Или как?
Кстати, атрибут protect сейчас имеют чаще всего поля, значения которых выбираются из классификаторов при помощи интерейсов выбора. Что, видеть их везде тусклыми? Смысл?
Далее. Если у значения поля доступна модификация, сейчас при перемещении на него все содержимое выделяется - и может быть либо перемещено в буфер либо перебито новым значением без дополнительных нажатий. Если поле имеет тип protect - выделения значения не происходит. Вполне удобно и привычно.

[vo]

Может ли кто-то озвучить полностью логически законченную постановку задачи?

ТЗ нужно прорабатывать.

А также, что побудило к ее возникновению и озвучиванию?

Побудили вполне реальные жизненные ситуации: пользователи иногда становятся в поля анкетных интерфейсов, защищенные свойством protect, начинают там что-то писать, при этом в некоторых интерфейсах Галактики происходит быстрый поиск, текущий документ теряется, дальнейшее редактирование этого документа может приводить к случайной порче данных. (Это вполне реальная жизненная ситуация из моей практики). Считаете ли Вы это основание достаточным для озвучивания проблемы? Возникновение же проблемы обусловлено особенностями системы, описанными в постановке проблемы.

Каким выделять цветом-то: например, чуть жирнее или тусклее обычного? Или как?

Это по-моему решать группе эргономики. Суть предложения в том, чтобы они были выделены.

Кстати, атрибут protect сейчас имеют чаще всего поля, значения которых выбираются из классификаторов при помощи интерейсов выбора. Что, видеть их везде тусклыми? Смысл?

У полей с выбором есть хотя бы кнопка [...] для того чтобы понять, что их нельзя редактировать. В принципе, основные проблемы не с этими полями, а с теми полями, которые не редактируются и при этом не выбираемые.
Делать ли измененный цвет для полей на которых есть pickbutton можно решить в ходе обсуждения.

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

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

[vadim]

А также, что побудило к ее возникновению и озвучиванию?

Побудили вполне реальные жизненные ситуации: пользователи иногда становятся в поля анкетных интерфейсов, защищенные свойством protect, начинают там что-то писать, при этом в некоторых интерфейсах Галактики происходит быстрый поиск, текущий документ теряется, дальнейшее редактирование этого документа может приводить к случайной порче данных. (Это вполне реальная жизненная ситуация из моей практики). Считаете ли Вы это основание достаточным для озвучивания проблемы?

Озвучивать - можно и нужно. Решать же надо, но совсем другим способом - а именно, ликвидацией мест, где при попытке набора в режиме редактирования начинается быстрый поиск и теряется текущий документ. Допускаю, что такие случаи иногда действительно возможны. Должен ведь открываться быстрый выбор, а не переход по записям. Как только такое место будет обнаружено - сразу же необходимо сообщить разработчикам (путем регистрации проблемы в ПИР "прочие несоответсвия стандартов" либо "несоответствия стандартам, существенно затрудняющие использование" - в зависимости от критичности ситуации).
Разукрашивать же protect-поля - неверно. В GUI windows такое не приветствуется: достаточно открыть какой-нибудь стандартный диалог настроек принтера - нет там разукрашивания...

[vo]

...
Разукрашивать же protect-поля - неверно. В GUI windows такое не приветствуется: достаточно открыть какой-нибудь стандартный диалог настроек принтера - нет там разукрашивания...

Любопытно, как сделано в других ERP-системах...
Если кто знает-видел, отпишите, пожалуйста, в эту ветку.

[poneatovski]

...
Любопытно, как сделано в других ERP-системах...
Если кто знает-видел, отпишите, пожалуйста, в эту ветку.

Работал с Oracle Applications (OeBS) и с IFS Applications. И в той и в другой визуально такие поля не выделяются.

[poneatovski]

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

А где взять информацию о стандартах работы системы?

[vadim]

в управлении разработки

[n0where]

В GUI windows такое не приветствуется: достаточно открыть какой-нибудь стандартный диалог настроек принтера - нет там разукрашивания...

Вы не правы. К примеру откройте свойство системы. Там где поле типа EDIT (для данные о пользователе), те поля что можно выделить курсором, а не те поля которые просто для информации (LABEL). Они разделены цветом.

поле EDIT с DISABLE = true - разукрашивается бледным цветом (в GUI Windows цвет прописан)
поле EDIT c READONLY (PROTECTED) = TRUE - не разукрашиваются, Но обычно такие поля стараются избегать (исходя из своего опыта, а благо он большой). Вот как бы в чем вопрос.

В галактике много полей с protected, в принципе логично было бы их сделать не EDIT (поле ввода), а LABEL (текст). Но в Галактике отсутствует такое поле. Поэтому и возникает такой вопрос, что необходимо как-то выделять.

Я бы предложил разукрашивать фон в цвет фейса для таких полей. Как предлагает WINDOWS.

[cruger]

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

Предложение же делать protected поля, в виде меток (текста, на который нельзя встать) сомнительно, т.к. этот атрибут используется, например, для полей, отображающих содержимое классификатора и позволяющих выбрать привязанное значение классификатора (по f3 или pickbutton). Отрубим вход в поле - отрубим f3.