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

[finsoftrz]

Если распределение делать в рамках программы, то это, видимо, уже заказная опция. У разных пользователей критерии распределения могут отличаться. Я бы, наверно, оформил в виде 2 связанных списков. В верхнем список товаров и общее количество по накладной и остаток в процессе распределения. А в нижней список магазинов с колонками по необходимым критериям конкретного товара (текущий остаток, дата последнего распределения, скорость ухода, полученный доход с продаж и т.п.). Ввод через стандартную (у меня) функцию ввода числовых значений. Можно с автоматическим переходом на следующую строку.
Надо спросить, может, заработать получится. Там, правда, человек экселем владеет, может сам макросы писать.

[kreator]

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

Словоблудие! Вы скажите, чего нет в EIP. Вы не знаете, потому что зациклились на своём мнении и в сторону смотреть не хотите. Ещё и Синявского в качестве авторитета подвязали .

[kreator]

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

Александр ошибся. В EIP нажатий в два раза меньше, чем с формой.

[finsoftrz]

Аргументы были приведены, и не один раз. Про шаблоны Синявского Вы сами спросили, я дал информацию, какая у меня есть. Получается у Вас так работать, ну и слава богу. Думаю, что тема EIP исчерпана, дальше обсуждать избыточно.

[RaFaeL]

Странная тема. Вроде, должны обсуждаться разные интерфейсы с разными находками. В итоге finsoftrz постит 100500 картинок со 100500 своих форм вида как еще деды писали лет 20 назад (если не 30), в которых лично я не вижу вообще ничего интересного, на все остальные варианты отвечает в стиле "мне так не надо", "смысла нет в этом", и т.д. и т.п. И так все 28 страниц. Зачем тогда тему завёл? )

[kreator]

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

Причина та же - что-то не так работает в шаблонах Синявского? Переделать или уйти с этих шаблонов не вариант?

Думаю, что тема EIP исчерпана, дальше обсуждать избыточно.

К сожалению, стандартный Ваш ответ. Лучше, действительно, послушали бы коллег. А то пользуетесь ограниченным набором возможностей Клариона.

[gopstop2007]

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

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

Спасибо, рад любой подсказке. У меня в таком виде, тут правда заказ, но аналогично и раздача по торг. точкам, когда то наваял, не Рио Де Женейро Сейчас делаю по другому.

[finsoftrz]

Странная тема. Вроде, должны обсуждаться разные интерфейсы с разными находками. В итоге finsoftrz постит 100500 картинок со 100500 своих форм вида как еще деды писали лет 20 назад (если не 30), в которых лично я не вижу вообще ничего интересного, на все остальные варианты отвечает в стиле "мне так не надо", "смысла нет в этом", и т.д. и т.п. И так все 28 страниц. Зачем тогда тему завёл? )

Rafael, так постите сюда то, что считаете интересным. Я никогда дизайном не увлекался, всегда главное было функциональность и удобство в манипулировании информацией. А также унификация и систематизация. С этой точки зрения и воспринимаю интерфейс. Кому-то интереснее внешнее оформление, почему бы не рассказать? И это не значит, что все должны соглашаться друг с другом. Посмотрели, прикинули, есть ли что полезное и что можно применить у себя.
Насчет 20-30 лет, вряд ли навешивание ярлыков способствует конструктивному общению. Это только Ваше мнение, не более того. Лучше сказать, я делаю вот это самое, но вот таким другим способом, и это имеет вот такие плюсы и минусы.

[finsoftrz]

Спасибо, рад любой подсказке. У меня в таком виде, тут правда заказ, но аналогично и раздача по торг. точкам, когда то наваял, не Рио Де Женейро Сейчас делаю по другому.

Заказы поставщику тоже довольно непростая тема, с большим количеством нюансов. У нас используется несколько вариантов, в зависимости от бизнес-процессов. Обычно вначале выводится список поставщиков с итоговыми значениями продаж, остатков, доходности, а потом, щелчком мышки, открывается деталировка по товарам. Там происходит подборка товаров, потом проверка и отправка поставщику.

Распределение по магазинам не требовалось, таких клиентов мало. После нашего обсуждения набросал такой вариант. Если пойдет в продакшен, будем уточнять.

http://finsoftrz.ru/mp4/fs_demo0012.htm

[finsoftrz]

У англоязычных коллег всплыла старая статья Карла Барнеса по поводу возможностей применения win32 api для расширения свойств стандартных кларионовских контролов. В частности, по поводу того, как сделать check и option многострочными. Мне показалось довольно познавательно.

[finsoftrz]

Причина та же - что-то не так работает в шаблонах Синявского? Переделать или уйти с этих шаблонов не вариант?

Дело не в шаблонах. Не знаю даже, как написать, чтобы понятно было.
Ну, например, есть у Вас на форме droplist по таблице для выбора значения из справочника. Название в справочнике может быть длинное, на экране в рамках комплексного окна не помещается. Окно открыто в режиме только просмотра. Droplist задизайблен, видимо. Как увидеть всю нужную информацию о выбранном элементе справочника? У меня вместо droplist специальный control шаблон с полем ввода кода и кнопкой выбора из справочника. Если режим только просмотра, то поле ввода в readonly. Но, находясь на нем, можно нажать горячую клавишу и открыть на просмотр форму записи справочника с необходимой информацией.
Другой вопрос. Пользователи часто запоминают коды, с которыми работают. Им быстрее набрать код, не открывая списка для выбора. Как это соотнести с droplist?
Еще вопрос. Если для отдельных категорий пользователей в соответствии с правами доступа надо предоставлять не стандартный выбор из списка записей, а отличный. Что делать в варианте с droplist?
И таких вопросов много.
Понятно, что можно в каких-то случаях отказаться от droplist по таблице, в каких-то оставить. Но у меня таких мест, где разумно применить droplist практически нет. Разве что при выборе пользователя при входе в программу.
И, как я писал, речь только про droplist по таблицам. Если есть некоторый фиксированный список значений, тогда droplist активно применяется.

Любой интерфейс это компромисс возможностей. Я в свое время много смотрел и анализировал разные программы, прежде чем пришел к определенной методологии работы. Да, это было давно, в начале нулевых. Сейчас некоторые вещи выглядят несколько иначе, так как изменилась аппаратная база компьютеров. Но не все "новое" надо хватать. Если MS пишет, что MDI интерфейс устарел, то это не повод от него отказываться. Я смотрю на другие приложения в области учетных систем. И большинство из них имеет даже еще более аскетичный вид. Посмотрите на те же Супермаг, Товар-Деньги-Товар, Папирус и им подобные. Почему так? Потому, что дизайн в нашем случае вторичен. Главное надежность, скорость работы, функциональность. В плане разработки интерфейса разработчики сделали инвестиции, пользователи привыкли, мало кто видит смысл что-то переделывать. Тем более, что дизайн вещь очень не однозначная. Достаточно вспомнить слова Артема Лебедева на этот счет, в чем-то он безусловно прав.

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

[Admin]

У англоязычных коллег всплыла старая статья Карла Барнеса по поводу возможностей применения win32 api для расширения свойств стандартных кларионовских контролов. В частности, по поводу того, как сделать check и option многострочными. Мне показалось довольно познавательно.

Это все у нас годами на ftp лежит.

[finsoftrz]

Когда проглядывал clamag, не обратил внимание на эту статью. Возможно, потому, что некоторые выпуски в битых архивах были. Или тема не интересовала. А брал я, скорее всего, здесь. Давно это было, во времена, когда clamag почил. Точнее, на виндев переключился. Лет 10 назад, поди уже.

[kreator]

Другой вопрос. Пользователи часто запоминают коды, с которыми работают. Им быстрее набрать код, не открывая списка для выбора. Как это соотнести с droplist?

Например, dropcombo это делает. Более того, сразу показывает что за этим id-шником. Я не согласен с Вами, что пользователи помнят id-шники. Могут помнить артикулы часто используемых товаров. А клиента легче искать по названию. Вот на фабрике изделия маркируются так - "1980 Джемпер женский". Поэтому "оператор" начинает поиск с цифры "1". Иначе никак, потому что этих "Джемперов женских" сотни. Я практически всегда вместо вашего Entry использую dropcombo. Если пользователь не может найти что-то в dropcombo, то лезет в справочник. Это сильно дольше. Особенно, если справочник деревянный.
Есть ещё фича dropcombo. Можно из него сразу ввести новую запись в таблицу, по которой dropcombo. В некоторых случаях это оправдано.

[finsoftrz]

На всякий случай уточню, что id и код у нас это разные понятия. Id однозначно определяет запись и не может быть изменен пользователем. Код, как и id, автонумеруется, но может быть изменен пользователем. Иногда нумерация кодов делается хитро. Например, весовые товары имеют код до 100000, штучные выше. В некоторых видах бизнеса, например, близкая мне тема оптовки хозяйственных товаров, вся работа строится "от кода".

По поводу маркировки изделий на швейной фабрике, скорее всего, они подстраиваются под предложенное Вами решение. Одно время я работал с несколькими швейными фабриками, ничего подобного я там не видел. Было название изделия и отдельно артикул. Артикул состоял из цифр и букв. И там была своя система кодирования артикулов, то есть это не просто абстрактные цифры и буквы. Глядя на артикул, специалист мог сразу определить некоторые основные параметры изделия.

По вводу названия товаров есть определенные рекомендации. Я и сам их озвучиваю пользователям, и у других разработчиков видел аналогично. Артикул иногда включают в состав наименования, но он не располагается в начале. Простой пример для обоснования. Вы выписываете товары с поиском по артикулу (или коду), но порядок сортировки в броузе стоит по наименованиям. Если покупатель спросил какой-то конкретный артикул (или код), а его, например, нет в наличии, то оператор или менеджер сразу видит подобные товары, которые есть на складе, и может предложить на замен.

В продуктовом бизнесе работают по наименованиям. Там используется поиск товаров не по первым символам названия, а по нескольким фрагментам. То есть пользователь вводит через пробел фрагменты названия с наибольшей смысловой нагрузкой, программа выводит все варианты товаров, в названиях которых имеются эти фрагменты в любой последовательности. Например, "молоко 3" выдаст все варианты молока с жирностью 3.2%. Иногда для уточнения позиции еще ориентируются по ценам и остаткам.
А теперь представьте, что подобный функционал не в одном месте, а в дюжине разных документов. Мне кажется, говорить об использовании выпадающих списков в данной ситуации смысла нет.

Хотел еще по ходу спросить. А Вы ресайзите выпадающие списки? То есть при одном разрешении монитора (размере экрана) в видимой части выпадающего списка надо размещать одно количество строк, на другом другое. Меня в С11 вымораживают их выпадающие списки. Постоянно куда-то улетают. На разрешении 800х600 работать с ними невозможно, на разрешении 1024Х768 можно, но не везде.