Интерфейсы в кларионовских приложениях

[kreator]

Что с EIP в ШВС, затрудняюсь сказать. Помню, что Синявский когда-то давно писал, что тоже считает эту схему работы мало функциональной. Поэтому, возможно, там не все допилено до нужного уровня.

Вы меня, конечно, простите. Но, наверно, хватит жить в прошлом веке. Когда-то Синявский в 1995 году сказал что-то, а Вы всё это помните и (главное) этим руководствуетесь. Всё давно допилили, перепилили, всё давно хорошо и функционально.
Дело ведь не в конкретном сценарии (накладные...), а в принципе, если речь идёт об интерфейсах. Если нужно ввести (или исправить) два-три поля, нафига вызывать форму?
Данная фича особенно актуальна в массовом заполнении одного поля.

[kreator]

Да и с теми же связанными записями решать проблемы...

Всё же прокомментирую. Нет никаких проблем со связанными записями. У Вас всегда есть выбор включать столбец в редактирование по месту или нет. Плюс у Вас есть возможность редактировать по месту через контролы droplist и combo, выбирать что-то из связанной таблицы, если речь об этом.

[finsoftrz]

Что с EIP в ШВС, затрудняюсь сказать. Помню, что Синявский когда-то давно писал, что тоже считает эту схему работы мало функциональной. Поэтому, возможно, там не все допилено до нужного уровня.

Вы меня, конечно, простите. Но, наверно, хватит жить в прошлом веке. Когда-то Синявский в 1995 году сказал что-то, а Вы всё это помните и (главное) этим руководствуетесь. Всё давно допилили, перепилили, всё давно хорошо и функционально.
Дело ведь не в конкретном сценарии (накладные...), а в принципе, если речь идёт об интерфейсах. Если нужно ввести (или исправить) два-три поля, нафига вызывать форму?
Данная фича особенно актуальна в массовом заполнении одного поля.

Причем тут Синявский? Я просто написал, что он придерживался того же мнения, что и я, и поэтому мог уделить EIP в ШВС меньше внимания. Причины, почему у меня не используется EIP, я привел. По моему, все понятно.
EIP как признак "современного подхода", ну, батенька, зажгли.

[finsoftrz]

Критор, сейчас еще Вам мозг взорву.
Droplist по таблицам и combo я тоже редко использую. По той же причине, что и eip. Droplist обычно только для фиксированных списков.

[gopstop2007]

Поддержу kreator-a
Как быстро поменять цены в товаре пробежав по списку или просто поменять какой-то из параметров, если позиций больше тысячи, не говоря о двадцати тысячах? Возьмите для сравнения время часов, потраченное на изменение в товаре на 1000 позиций со стандартной формой или на EIP аля в таблице ексель?

[finsoftrz]

Александр, Вы действительно вручную меняете цены у 1000 товаров?
Бывают, конечно, ситуации, когда надо поменять одно какое-то значение в записи. Например, исправить что-то в строке накладной. Я уже писал, что в этом случае форма открывается сразу с автоматическим позиционированием на нужное поле. Если посчитаете количество нажатий на клавиши, то будет не больше, чем при eip. Но при этом сохраняется вся функциональность.
Я не против eip, если у Вас получается его использовать, замечательно. Я просто написал, что мне для обеспечения нужной функциональности такое не подходит. Какой конкретно функциональности, я написал в одном из предыдущих постов.

[Дед Пахом]

молодёжь авторитетов не признаёт.

[gopstop2007]

Александр, Вы действительно вручную меняете цены у 1000 товаров?

нет, но клиент да

Если посчитаете количество нажатий на клавиши, то будет не больше, чем при eip. Но при этом сохраняется вся функциональность.

Давайте посчитаем:
Ваш вариант
1. мышкой стать на запись
2.изменить в форме
3. ctrl+enter
следующее поле
1. мышкой стать на запись
2.изменить в форме
3. ctrl+enter
...

EIP
1. мышкой стать на запись (on eip)
2.изменить в строке
3. стрелка вниз или (вправо, влево,вверх)
следующее поле
1.изменить в строке
2. стрелка вниз или (вправо, влево,вверх)
....

Выигрыш в одно нажатие на каждой записи (33%), без мелькания формы.

[finsoftrz]

Мышкой на запись вставать не обязательно, можно Enter, стрелка вниз. То есть одно нажатие клавиши выигрываете за счет автоматического смещения на следующую запись? А кто сказал, что надо править именно следующую запись? Такое редко бывает. У меня есть одно место, где пользователи просили сделать автоматическое перемещение на следующую запись. Там как раз такой алгоритм поведения и как раз ввод цен. Изменили одно поле в записи, автоматически сместились на следующую запись. Используется стандартная (у меня) функция ввода числового значения. Нафига динамически создавать и накладывать контролы (поле ввода, калькулятор), отслеживать ненужные нажатия клавиш, если можно просто вызвать одну функцию из библиотеки.

Если получается использовать EIP, то у Вас наверняка очень простое приложение. Это надо, чтобы все поля выводились в броузе, не коррелировали друг с другом, информацию о полях записи не надо было просматривать в других местах приложения, не надо отслеживать конкурентное редактирование записей. Распределение прав доступа, если есть, программируется вручную. Можно долго обсуждать. Я вообще не очень понимаю, что зациклились на EIP. Это для простых приложений с ограниченным функционалом. Хорошо, если подходит. У меня другой случай, я только за себя говорю.

[finsoftrz]

Кстати, еще есть одна хорошо забытая возможность. Недавно вспомнил, когда смотрел интерфейс в Инфо-Бухгалтере. Формами можно управлять стандартными клавишами на тулбаре, так же, как броузами. То есть открыли форму, на тулбаре доступны клавиши сохранить текущую запись и перейти на следующую/предыдущую/страница вперед/страница назад/в начало списка/в конец списка/добавить новую запись. Форма мелькает (открывается и закрывается), чтобы получить актуальное содержание броуза с учетом сортировки и фильтров. У меня такой функционал не прижился. Как-то не очень это понятно, сохранить и перейти на запись в конец списка, например. Но прикольно.

[finsoftrz]

Кстати, Александр, что-то с математикой у Вас не так. Когда считаете процент, то почему-то не учитываете ввод значения.

[gopstop2007]

Кстати, Александр, что-то с математикой у Вас не так. Когда считаете процент, то почему-то не учитываете ввод значения.

Не совсем понятно, что Вы под этим подразумеваете? У меня вроде было указано: 2.изменить в форме или 2.изменить в строке

[gopstop2007]

Мышкой на запись вставать не обязательно, можно Enter, стрелка вниз. То есть одно нажатие клавиши выигрываете за счет автоматического смещения на следующую запись? А кто сказал, что надо править именно следующую запись? Такое редко бывает. У меня есть одно место, где пользователи просили сделать автоматическое перемещение на следующую запись. Там как раз такой алгоритм поведения и как раз ввод цен. Изменили одно поле в записи, автоматически сместились на следующую запись. Используется стандартная (у меня) функция ввода числового значения. Нафига динамически создавать и накладывать контролы (поле ввода, калькулятор), отслеживать ненужные нажатия клавиш, если можно просто вызвать одну функцию из библиотеки.

Если получается использовать EIP, то у Вас наверняка очень простое приложение. Это надо, чтобы все поля выводились в броузе, не коррелировали друг с другом, информацию о полях записи не надо было просматривать в других местах приложения, не надо отслеживать конкурентное редактирование записей. Распределение прав доступа, если есть, программируется вручную. Можно долго обсуждать. Я вообще не очень понимаю, что зациклились на EIP. Это для простых приложений с ограниченным функционалом. Хорошо, если подходит. У меня другой случай, я только за себя говорю.

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

[finsoftrz]

Кстати, Александр, что-то с математикой у Вас не так. Когда считаете процент, то почему-то не учитываете ввод значения.

Не совсем понятно, что вы под этим подразумеваете? У меня вроде было указано: 2.изменить в форме или 2.изменить в строке

Про 33%. Не считаете нажатия клавиш, когда вводится само значение. Процент разницы во времени операции будет сильно меньше.

[finsoftrz]

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

Александр, я Вам сходу скажу слабое место. На основании чего пользователь принимает решение о том, сколько товара в какой магазин отдать? Одних текущих остатков недостаточно.
У нас тоже есть сеть, которая работает по подобной схеме. То есть принимает общую накладную и распределяет товары в несколько магазинов. Давно уже запускали, может, что и забыл, могу уточнить, если надо. По моему, они формируют кросс-таблицу продажи+остатки в разрезе магазинов, установив отбор по товарам конкретного прихода. В первых колонках идет основной склад , потом магазины. Сохраняют в эксель, там еще что-то колдуют, потом из экселя загружают в накладные на перемещения. Планы обмена настроены заранее для каждого магазина.