forum.clarionlife.net

Может и лучше, только это приведет к глобальной смене интерфейса. Проблема возникает при плотном расположении контролов. В простых окнах небольшое смещение не критично.

Тут еще вылез какой-то странный баг со стандартным шаблоном versionres.tpl, из разряда не верь глазам своим. Ресурсный файл открывается, читается, потом закрывается. А среда выдает, что уже открыт для чтения. При сборке через раз, при открытии эмбедов постоянно шлет. Танцы с бубном со сменой названия символа, места положения и имени ресурсного файла к успеху не приводят.

Последнее, скорее всего связано с тем, что открыт какой-то еще файл на чтение, а кодогенератор в с11 позволяет открывать только один. Это из разряда предположений, можно выяснить точнее. В с6 подобного не возникало.

поэтому наверно не спешу переходить с 10-ки. Не вижу пока, что есть такого "сверх" в 11

finsoftrz писал(а): 31 Декабрь 2021, 13:29 Последнее, скорее всего связано с тем, что открыт какой-то еще файл на чтение, а кодогенератор в с11 позволяет открывать только один. Это из разряда предположений, можно выяснить точнее. В с6 подобного не возникало.

Для #open с атрибутом read в этом шаблоне стояло #close без read. Поставил везде. Нормализовалось, но не сразу. Я так и не понял логику.
Позволяет создавать дублирующиеся имена локальных переменных, если они объявлены в разных структурах. В промптах шаблонов при выборе полей (ключей) из таблицы не сохраняет последнюю таблицу, из которой выбирали, приходится снова искать ее в списке.
Если разместить на окне поле, потом удалить и снова разместить, нумерует, как при повторном размещении.
Если добавить локальную переменную при заполнении промптов шаблона, на панели data/tables она появится только после сохранения процедуры.
Конечно, мелочи.

Зеленое колесо крутится до 5 сек при входе в список эмбедов контрола, если в окне много контролов. И, наконец, я завалил среду, вылетела с предложением сообщить об ошибке в SV. Значит, пора новый год начинать отмечать.

finsoftrz писал(а): 31 Декабрь 2021, 13:13 Может и лучше, только это приведет к глобальной смене интерфейса.

Тоже так думал. Но потом понял, что глобальная смена интерфейса уже произошла при выпуске Win10, просто я застрял во веустраивающем прошлом. Пришлось догонять. Никто уже не будет тестировать интерфейсы под старые шрифты, ос и т.д., несмотря на декларируемую совместимость.

Вопрос крайне спорный. Интерфейс оценивается по удобству работы, а не по округлостям используемого шрифта. Потом, обратную совместимость обеспечивает MS, а изменения в кларион вносит SV. Разницу чувствуете?
В любом случае, проблема не в шрифте. Кстати, можно нормально и ms sans serif в windows 10 использовать, установив сглаживание шрифтов. На мое восприятие, не так сильно отличается от segoe ui.

finsoftrz писал(а): 31 Декабрь 2021, 18:31 Интерфейс оценивается по удобству работыi.

Безусловно ! И если разработчик или юзер (кассир) работает с одним приложением, то вопроса вроде бы и нет.
А вот если пользователь работает с многими программами и сервисами и только одна программа запускается
с иным шрифтом, то это очень заметно. Не знаю, почему Microsoft сменил рекомендации по шрифту для интерфейса
приложений в WIN10, но вижу, что его выполняют. В т.ч. и SV.

Почему только одна? Тогда бы не было стольких разновидностей шрифтов. В вебе, по моему, segoe ui, вообще никто не использует, в мобильных устройствах тоже. Читается без напряжения, значит, хорошо. Большинство людей воспринимают текст на таком уровне.

Меня бы сейчас устроило оставить рантайм на с6, а среду с11, тк в среде с11 есть ряд важных возможностей. Но вот с дизайнером окон пока грустно.

finsoftrz писал(а): 31 Декабрь 2021, 19:22 Меня бы сейчас устроило оставить рантайм на с6, а среду с11, тк в среде с11 есть ряд важных возможностей.

Аналогично, но наоборот. Но кажется, что в любом случае, собрать только ништяки не получится.
Хошь работать полноценно с современным инструментальным средством, нужно принять и правила
соответствующего поколения Windows.

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

У меня все крутится мысль сделать внешний дизайнер окон как дополнение к среде с11. В плане функционала перемещения, выравнивания контролов. Возможно, установки каких-то их свойств. И применять, когда в среде работать трудоемко. Можно было бы сделать все, как нужно. То есть, в среде накидываем приблизительно контролы и контрол-шаблоны, затем ctrl+a, ctrl+c в текстовой структуре окна, alt+tab и жмем кнопку в нашем приложении. Окно появилось. Вносим изменения, жмем кнопку сохранить. А в среде в текстовой структуре окна ctrl+v, замещаем исходное описание. Метки и seq сохраняются, замещение проходит без проблем. В принципе, сделать это не слишком сложно, у меня есть наработки по созданию и перемещению контролов, примерно, как в оконном дизайнере с6. Только под другую задачу, там всего 2 вида контролов. Реализовать динамическое создание всех нужных видов контролов, разбор структуры window из буфера обмена во внутренние структуры класса, создание структуры window из внутренних структур класса.

finsoftrz писал(а): 31 Декабрь 2021, 20:12 У меня все крутится мысль сделать внешний дизайнер окон как дополнение к среде с11.

Тогда уже совсем рядом будет сделать и интерпритатор по визуализации этих окон (аналогично preview C11) ...
получится почти 1С. Ну и рисуем мы Clarion. А какая разница в скомпилированном приложении от VC ?

finsoftrz писал(а): 30 Декабрь 2021, 16:12 Охота Вам тратить время на anyscreen...

ШВС куда перспективней. Прикрутить к ним манифест вообще на нобелевку тянет. Хотел Вам посоветовать не заниматься этим, остаться на классике. Внешний вид кларионовского приложения, запущенного через rdp для перфекциониста вызовет только дополнительные вопросы.

И Вас с Новым годом!
Прикручивать манифест к ШВС не надо совсем. Достаточно подложить стандартный небольшой файлик к программе или прилинковать его как ресурс к app exe, будет счастье. А вот то, что anyscreen изначально проблемная технология, вполне очевидно, если немного задуматься на эту тему. Поэтому никто такую фигню для работы через веб и не пишет. Поинтересуйтесь для саморазвития, как организован "тонкий клиент" в 1с8, на что они пошли и сколько вбухали, чтобы получить работающее решение.

Теперь немного по теме. Для связки с11-с6 есть один существенный нюанс. В с6 мы стандартно работаем со шрифтом MS Sans Serif. В с11 такого шрифта в списке шрифтов для выбора нет. Если ввести вручную, то заменит на Microsoft Sans Serif. Это другой шрифт, рантайм с6 с ним корректно не работает. Тем не менее, после конвертации app с с6 в среду с11, шрифт MS Sans Serif остается. Среда его показывает, как Microsoft Sans Serif, и не трогает, пока не изменить какие-то параметры шрифта. Тогда в декларации окна шрифт меняется и начинается веселье. В принципе, можно поменять шрифт в текстовой декларации. Но, чтобы не прилетело вдруг, лучше отработать на уровне шаблонов. В ШВС это выглядит примерно так (перед размещением декларации окна). Если у контрола установлен тот же шрифт, что и у окна, то кодогенератор его опускает в window структуре. Поэтому достаточно отследить в заголовке окна.

Еще из замеченных проблем. Если у окна поменять размер шрифта в дизайнере окон, то контролы разлетаются в разные стороны, как почтовые голуби. В с6 окно корректно масштабируется. В принципе, не так страшно, шрифт у окна редко меняется.
Почему-то символ %ProgramDateChanged стал возвращать какую-то левую дату. В с6 возвращал дату последнего изменения программы. Аналогично %ProgramDateCreate, символы времени я не проверял, так как не использую и лень. Пришлось заменить на функцию определения даты по exe программы (command(0)). Если exe подписан, то можно вытаскивать оттуда (если предварительно положить).

По поводу известного бага рантайма с11 с пропаданием меню фрейма при выключении темы. Пока получилось выводить сообщение. Не знаю, можно ли как-то перерисовать меню фрейма средствами win api или там подвязки на кларионовский рантайм.