forum.clarionlife.net

Rafael, во-первых, Вы привели скриншот 8-10 летней давности, наверно. Сейчас там немного не так все.

Чтобы добавить новую опцию в программу, если речь про базовые параметры, я кода вообще не пишу. Добавляю в словарь, пересобираю, вставляю в форму. Пересборка быстрая, так как кодогенерация работает только для 2 dll (декларации + тянущая шаблонами всякие опции из словаря).
Если речь про дополнительные параметры, которые не надо жестко контролировать, то примерно, как у Вас. Значения могут быть строковые или выбор из классификатора, которых можно подключить столько, сколько надо. Вместо check булево (Да/Нет).

У Вас на товары, контрагентов, сотрудников одно окно? Прикольно.
Вообще говоря, это известный подход, заменять поля ввода на списки. Комментировать не хочу.
Вы делаете некоторую абстрактную программу, не вникая в бизнес процессы пользователей. Тяжесть работ по настройке перекладывается на "настройщиков". И интегрируете свою программу с другими товароучетными системами, бухгалтерскими программами, сайтами и т.п. У нас же реализуется полный функционал, все, что необходимо для работы предприятия в определенных сферах бизнеса. И товароучет с кучей всякого функционала, о котором без погружения в бизнес процессы, Вы даже не будете догадываться, и бухгалтерия, и портал в вебе, все сразу из коробки. Сел и начал работать, практически ничего настраивать не надо. Поэтому совсем разные приложения для разных целей.

Вот этот скриншот Вам, наверно, больше понравится.

Набросал на коленке контрол шаблон с group контролом для наборов кнопок.
Сейчас решает такие функции:
1. Фиксирует собственную высоту.
2. Выравнивает заданные кнопки (их может быть много в ряд) по центру относительно своих границ.
3. Выравнивает ряд кнопок по своей правой или левой границе.
4. Выставляет стандартное значение отступа между кнопками.
Подобных шаблонов можно наделать для разных типовых ситуаций (ряд мелких кнопок, поля ввода и т.д.).

В среде C6 выглядит так. Для наглядности я кнопки специально сместил.
Результат в окне.

finsoftrz писал(а): 21 Август 2020, 21:16 Rafael, во-первых, Вы привели скриншот 8-10 летней давности, наверно. Сейчас там немного не так все.

Я привел скриншот с ролика, который у вас на сайте. Что сейчас в программе не знаю. Я попробовал скачать, там пароль на архиве

Чтобы добавить новую опцию в программу, если речь про базовые параметры, я кода вообще не пишу. Добавляю в словарь, пересобираю, вставляю в форму. Пересборка быстрая, так как кодогенерация работает только для 2 dll (декларации + тянущая шаблонами всякие опции из словаря).

Значит у вас 1-2 клиента всего. Или как вы им всем базы обновляете на новую структуру после добавления каждой опции? Руками что ли?

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

Ну во-первых это мягко говоря не так, а во-вторых, какое отношение это имеет к интерфейсу? Речь шла о количестве окон и контролов. Я привел пример, как количество контролов уменьшается на порядки без какого-либо уменьшения функционала либо отдаления от предметной области

P.S. Для загрузки из Excel удобнее для колонки не entry а spin. У нас там, кстати, тоже список и одно окно для импорта из excel примерно всего. Предполагаю, что у вас окон много и контролов тоже - это возвращаясь к вопросу как надо (ну вам, вероятно, не надо, но вопрос "как надо?" все-таки звучал)

Сел и начал работать, практически ничего настраивать не надо.

А три закладки "установок" это просто так )

Клиентов сильно больше, чем 1-2. Сами понимаете, больше не скажу. Кто работает, кто финансирует, это посторонним знать не надо. А по обновлениям все просто. Есть системы автоматического контроля версий структуры базы данных. Странно, что Вы про такое не знаете. У меня используется своя разработка. Если кратко, полностью автоматически, без ручного кодирования, генерится отдельный небольшой exe, который актуализирует структуру базы данных. Не последних изменений, а всех, начиная от используемых у клиентов версий. Этот exe запускается после распаковки dll+exe новой версии программы. Или вручную, или в составе процедуры автоматического обновления.

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

По спинам я смысла не вижу. На мое восприятия, избыточный элемент декора в данном случае. Номера колонок могут быть 3 значными, никто спины жать не будет.

Задача при разработки информационной системы не в том, чтобы сделать минимальное количество окон и контролов. Это из разряда "сделаем всю структуру базы данных на 7 таблицах". Есть и такие проекты. Прописали один раз на все случаи жизни, красота. Те же яйца в профиль. Но люди ведь не зря придумали все эти заморочки с проектированием структуры базы данных, разработкой диалоговых окон, изолированием функций бизнес-логики. Я "гибкими и настраиваемыми программами" переболел еще в 90-е годы. Для меня когда-то было открытием, что в меню программы может быть строка "Приходные накладные". Должно ведь быть "Журналы документов". А там справочник видов документов, заголовки документов и строковые части. Потом уже пришло понимание, что с таким подходом неминуемо снижается функциональность приложения для пользователей. Введение избыточных абстракций ограничивает возможности в развитии проекта, не позволяя углубляться в предметную область и хорошо контролировать бизнес-логику.
Rafael, я не говорю, что у Вас все плохо, у нас все хорошо. Только отмечаю, что системы разного назначения, с разными планками и критериями оценки. То, что работает у Вас, не будет работать у нас. Я же все это не просто так от балды пишу, каждый день анализирую, что можно улучшить в проекте. Но сохраняя его архитектуру и идеологию.

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

Он файл интерфейса клиенту импортирует из библиотеки типовых настроек и всё )

finsoftrz писал(а): 22 Август 2020, 8:05 По спинам я смысла не вижу. На мое восприятия, избыточный элемент декора в данном случае. Номера колонок могут быть 3 значными, никто спины жать не будет.

В скольки процентах случаев будет 3 значный номер? Максимум в 1%. Еще в 4% он будет двузначный, а вот в 95% случаев однозначный, и его быстрее ввести через спин скроллом. Это не декор, это удобство ввода. Руками то никто не запретит ввести. И вот так у вас везде...

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

Информация из MSDN, как MS относится к spin контролам.

https://docs.microsoft.com/en-us/window ... n-controls

В целом, предлагается использовать для ввода небольших значений (в пределах 100), для небольших отклонений от введенного или дефолтного значений, когда пользователи предпочтительно работают мышкой. В принципе, ввод номеров колонок подпадает под первые 2 критерия. По третьему критерию не очень. В учетных системах вводят много цифровой информации, и делают это с клавиатуры.

Что мне еще не нравится, это получается нестандартно в рамках всего приложения. При вводе количества, которое может быть дробным, или значений цен/сумм использование spin выглядит забавно и вряд ли имеет какой-то практический смысл. А именно для ввода значений колонок в Excel, чем пользователи занимаются исчезающе редко, мы делаем иначе.
Мысль, конечно, имеет место. Хорошо, что обратили внимание. Но я пока не вижу достаточно аргументов, чтобы изменить существующее решение.

Оконные процедуры можно создавать просто и быстро, используя специализированные визарды. Сейчас эта тема как-то на второй план ушла, но когда шло активное наполнение функционалом, было очень эффективно. На днях проверил в C11, все работает.
Я когда-то писал, по моему, про эту технологию. Склероз самая приятная из болезней. Если кратко, то делается следующим образом. Создаем отдельные dct+app. В dct добавляем таблицы, как обычно. Единственное, называем таблицы и префиксы определенным образом, чтобы потом можно было массово заменить на значения промптов. Основные таблицы Справочник, Группы справочника, Заголовки документов, Строки документов и т.п. Далее, в app проектируем оконные процедуры, тоже, как обычно. В описание, категорию, метку помощи и т.п. вставляем определенные значения. Тоже, чтобы легко заменить на промпты. Навешиваем различные шаблоны, доводя функциональность до нужного уровня. Потом эти процедуры сохраняем в txa. Один txa, одна оконная процедура. В любом текстовом редакторе делаем несколько массовых замен. Txa приведен в боевой вид. Копируем tpw файлик из заготовки, вставляем нужные промпты. Стандартные там уже есть (категория, описание, пиктограмма). Инклудим один или несколько заготовленных на предыдущем шаге txa. А сам tpw инклудим в заглавный tpl, зарегистрированный в шаблонах.
Таким образом, один визард позволяет в несколько кликов создавать от одной до нескольких оконных процедур со всеми обвесами, а также частично (а в отдельных случаях и полностью) заполненными полями в броузах и формах.

Как выглядит текст tpw рабочего визарда, может, кому пригодится.
#INCLUDE('FsWOtSymple.fsw') - инклудим экспортированный txa файл.
#INSERT(%FsOtSympleWiz) - это символ группы, в которую обрамлен код в txa файле.
Txa файл.

Все таки сделал ввод номеров колонок через spin. Поменять через кнопку соурса окна быстро. С точки зрения системы обоснование есть. Экселевские формы приходят из разных источников и могут содержать всякие нюансы, типа объединений или скрытия колонок. Поэтому вероятность ввода номера колонки с ошибкой существует. Поправить ее, увеличив значение на 1-2, практическая ситуация. Поэтому пусть такой маленький сервис будет.

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

Есть такая интересная штука, как AnyFont от CapeSoft. Я про него слышал, но никогда раньше не смотрел.
В целом, это небольшой класс и шаблоны к нему. Класс в сырцах, ни на что не завязан, и его достаточно просто использовать и без шаблонов, или интегрировать в любые шаблоны, если идущие в комплекте не хочется. Класс позволяет установить шрифт контролов и автоматически изменяет размеры самих контролов и всего окна. Достаточно сразу после открытия окна сказать типа такого:
AnyFontL.SetWindow('Tahoma',10,,,204)
Плюс есть возможность учитывать контролы с нестандартными шрифтами, передавая ссылку на очередь с ними. Использование AnyFont требует некоторой шлифовки ресайзера Струменского. А стандартный ресайзер поддерживается из коробки, как я понял.
Немного сегодня попробовал в ручном режиме на некоторых окнах реального приложения. Если меняется только размер шрифта, то все проходит хорошо. При смене шрифта, например шерифа на тахому или сегое, некоторые контролы могут съезжать. Прежде всего это относится к тем, у которых дефолтное значение ширины или высоты. То есть проверять работу в этом случае надо в каждом окне.

Вот это скриншот стандартного окна с шерифом 8. Это после применения anyFont с тем же шерифом, размер шрифта 10.

Из серии "фич" интерфейсов (убил на это пару часов).
В окне проходит длительная обработка на каждый ввод символа в некоторое поле. И, дабы не нервировать пользователя, было сделано так

Open(окно не боись, работаю)
Перегенерация Browse с новым фильтром
Close(окно не боись, работаю)
Beep(не спим)

Всё было хорошо, пока условие фильтра прописывалось во View. Но, по ряду причин, потребовалось вынести обработку в соответствующий Embed. И тут всплыло интересное: Entry, на котором стоял курсор в момент перегенерации, оказывалось выделенным полностью. Стоило убрать "окно не боись, работаю", как всё опять вернулось на круги своя - курсор в поле Entry оставался на стром месте, никаких сложностей для дальнейшего ввода.

finsoftrz писал(а): 29 Август 2020, 16:10 некоторые контролы могут съезжать

Интересно, как они этого достигают, съезжания контролов? Масштабируют в открытом окне контролы под размер шрифта?
У меня аналогичное встроено в шаблоны, но там, наоборот, шрифт масштабируется под размеры контролов:
- задаём новый базовый шрифт (в настройках пользователя)
- открываем окно
- меняем шрифт на новый базовый во всех контролах, где надо
Accept
- при ресайзе автоматически пересчитываем размеры контролов и размер шрифта
- меняем шрифт во всех контролах, где надо
End

Этакий аналог Grey+-

Делают сразу после открытия окна. Вначале сохраняют текущие значения контролов в очередь (положение и размеры), потом заменяют шрифт, потом выставляют новые значения контролов. А в конце еще размер окна меняют. При передергивании prop:pixels происходит пересчет размера dlu. Глянь сырцы, там все более менее понятно написано и с комментариями.

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

Я неверно написал, что ресайзер Струменского требует адаптации. Все нормально работает, во всяком случае, при изменении размера шрифта в большую сторону. В общем, я добавил поддержку либы себе в шаблоны. А в настройке программы оставил только 2 варианта для выбора размера шрифта, стандартный 8 и увеличенный 10. Сам шрифт не меняется, смысла нет. А на больших размерах тестить негде.
Получилось решить вопрос с мелковатостью шрифта при разрешении монитора больше чем 800х600, под который проектировалось приложение. Например, на разрешении 1024х768 с размером шрифта 10 все выглядит так же глазасто, как на 800х600 с размером шрифта 8. Это важный момент. Если есть приложение, разработанное под разрешение 800х600 и надо его поддерживать либо нет времени переделывать на более крупный шрифт, то anyfont, в целом, закрывает вопрос.

Я, исключительно, с целью повышения образованности. Мой шаблон отрабатывает надёжно. Видимо, всё дело в том, что я шрифты и размеры контролов и окна разнёс по разным логикам (размеры шрифтов меняются после установления размеров контролов)