Clarion 11-12

[finsoftrz]

Решения я и сам могу найти. Если внимательнее прочитаете, то по каждому пункту оно присутствует в предыдущем посте.
На хабе я недавно спросил про поля ввода на toolbox, меня отослали к документации, где есть отписка, что так и должно быть. Хотя на самом деле проблема касается не всех toolbox, а только float. И в с6 все работает без проблем.
Я, конечно, понимаю, что не очень приятно читать про недоработки в с11, особенно по сравнению с с6, которую некоторые считают не модной. Такова жизнь, поздние версии бывают более проблемными, и это бывает больно.
Могу, конечно, и не писать. Но, если потом сами наступите, потеряете время на выяснение причин, а тут в готовом виде и описание проблемы, и как её можно обойти.

[finsoftrz]

А кто прислал другую версию рантайма?

[Игорь Столяров]

понимаю, что не очень приятно читать про недоработки в с11

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

А кто прислал другую версию рантайма?

Тот у кого есть исходники и желание обсудить свои идеи с такими любопытными как я.

[finsoftrz]

Не знаю, почему Вы считаете маски и тулбоксы ненужным и устаревшими. Это как раз тот функционал, который должен быть в системе. Не потому, что мне нравится, а потому, что это хорошо и удобно для пользователей. Если смотреть объективно.
На самом деле, сейчас принципиальных вопросов к рантайму с11 уже практически не остаётся. Кроме как, а нафига это надо. Смысл может быть в том, чтобы не иметь отдельную версию фреймворка для работы с anyscreen. Сам по себе anyscreen штука нужная, лёгкий способ доступа к нашим базам через интернет и с мобильных девайсов. Это принципиальное расширение возможностей. Остальное хз, на одной чаше весов стабильный и проверенный временем рантайм с6, на другой некоторое улучшение во внешнем виде приложений в рантайме с11, но который заметно слабее протестирован и требует всякого рода обходные пути для решения проблем. Это все должно отлежаться и созреть.

[finsoftrz]

понимаю, что не очень приятно читать про недоработки в с11

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

А кто прислал другую версию рантайма?

Тот у кого есть исходники и желание обсудить свои идеи с такими любопытными как я.

Ок, я понял. С учётом того, что у RZ такого желания точно нет, то можно с первого раза догадаться, кто это был.

[Игорь Столяров]

Вы считаете маски и тулбоксы ненужным и устаревшими

Нет. Я сказал "Вы пытаетесь спасти старый код с масками, да тулбоксами".
Вы переносите свой старый код в C11, а в нём используются эти интерфейсные элементы.
Как я могу делать выводы об их устаревании и тем более ненужности - если я их практически не юзаю ?
И об этом я тоже написал - если прочитать и не пытаться на каждое моё сообщене сразу отвечать двумя.

С учётом того, что у RZ такого желания точно нет

Ну Роберта уже давно со свечами на ClaHUB ищут. Безуспешно.
Но на письмо c указанием проблемы шрифтов в Message() он нам ответил ...

[finsoftrz]

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

[Игорь Столяров]

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

[finsoftrz]

Я тут подумал. То, что нужные и крутые вещи, которые нам доступны в mdi интерфейсе в с6 и по факту перестали корректно работать в с11, имеет рациональное объяснение. MS поддерживает mdi интерфейс по соображениям обратной совместимости и давно там ничего не меняет. На эту тему было обсуждение, в котором RZ сказал, что приходится прилагать немало усилий, чтобы нивелировать некоторые моменты на стороне рантайма клариона. После принятия решения перехода на стандартные контролы винды ситуация, видимо, усугубилась. И чем дальше двигаться в этом направлении, тем больше проблем будет вылезать. Так, как работает система управления окнами в кларионе, я больше нигде не видел. Где видел, окна открывают в одном основном потоке, а обработчики (код) запускают в отдельном потоке. Получается некая ловушка. Кардинально изменить подход приведёт к проблемам с работающими приложениями, а продолжать поддерживать mdi приводит к отвалу функционала. Поэтому происходит постепенно миграция с mdi интерфейса на tab интерфейс. То есть, похоже на mdi, но без органов управления дочерними окнами и тулбоксов. Больше всего в таком подходе не нравится необходимость нагромождать в окна кучу дополнительных контролов. Следующий шаг в этом направлении будет, видимо, раскрытие функционально насыщенных окон во весь экран (по свободной области фрейма), а вызываемые окна делать максимально простыми. Чтобы снизить эффект перегрузки диалогов. Примерно в этом направлении сейчас смотрю организацию интерфейса в anyscreen.

[Игорь Столяров]

То есть, похоже на mdi, но без органов управления дочерними окнами и тулбоксов.

Вы наверно будите опять ругаться, что я не ценю наследие дедов ... но я столько раз наступал на эти грабли.
У нас есть необсуждаемое правило: мы работаем с MDI, но после запуска поток максимально изолирован.
Причём изоляция - это не только управление, но и данные. Никаких (ну почти) Global Static.

Внешнее управление потоком (те же VCR контролы на ToolBar) со времён С1.5 и до С11 работали плохо.
Просто это "плохо" было всегда разным, но стабильным. Они висли, вышибались в GPF и просто блымали. Всегда.
Даже если их вырубить и выкосить - они всё равно прописаные во все окнах и есть отсыл к ним в AppFrame.

[Губин Игорь]

Вы наверно будите опять ругаться, что я не ценю наследие дедов ... но я столько раз наступал на эти грабли.
У нас есть необсуждаемое правило: мы работаем с MDI, но после запуска поток максимально изолирован.
Причём изоляция - это не только управление, но и данные. Никаких (ну почти) Global Static.

Согласен на все 100500!

Потоки изолированы и самодостаточны. Во фрейме есть только тулбары с кнопками (красиво, а в потоках их нет). Для обмена командами между потоками/потоками и фреймом есть Events, для обмена настройками есть одна единственная глобальная группа переменных, каждое изменение в которой обвешано семаформами по самое не хочу. Если надо обмениваться чем-то большим, то используется фича в виде файлов memory.

[finsoftrz]

То есть, похоже на mdi, но без органов управления дочерними окнами и тулбоксов.

Вы наверно будите опять ругаться, что я не ценю наследие дедов ... но я столько раз наступал на эти грабли.
У нас есть необсуждаемое правило: мы работаем с MDI, но после запуска поток максимально изолирован.
Причём изоляция - это не только управление, но и данные. Никаких (ну почти) Global Static.

Внешнее управление потоком (те же VCR контролы на ToolBar) со времён С1.5 и до С11 работали плохо.
Просто это "плохо" было всегда разным, но стабильным. Они висли, вышибались в GPF и просто блымали. Всегда.
Даже если их вырубить и выкосить - они всё равно прописаные во все окнах и есть отсыл к ним в AppFrame.

Ну, я не знаю, что у вас не так было. За последние 20 лет никаких проблем с контролами управления на тулбаре и с тулбоксами не наблюдаю. От слова совсем. До начала тестирования рантайма с11, где начало вылезать. Сейчас у меня на компе перед глазами сборка большого проекта на с63, она же на с11, сборка под anyscreen с частичным функционалом и та программа, название которой просили не писать. Сборка под с6 работает отлично, вообще без нареканий. Сборка с11 - то одно выскочит, то другое. Рандомно. На ней, видимо, действительно, надо отказываться от mdi в пользу tab. Назовём это так для понимания разницы. Я смотрю на сборку под anyscreen и на ту, которую нельзя называть. Может, это дело привычки в какой-то степени. В этих приложениях порядка 10-20 дополнительных кнопок (и не только) в КАЖДОМ окне при меньшей общей функциональности. То есть я могу понять ситуацию с anyscreen, оно работает в веб браузере, где по определению нет mdi, но оно того стоит, так как обеспечивает доступ к приложению через веб без необходимости использования дополнительного внешнего по (и сопутствующего администрирование). Гораздо сложнее понять, какой смысл в использовании с11 для обычных настольных приложений, если это объективно в плане функциональности заметный шаг назад. Вот я и пытаюсь это осмыслить, тупо щелкая по окнам в упомянутых приложениях. Вдруг глаз замылился и чего-то сокрального не замечаю. Уважаемые люди пишут халва-халва, а свои глаза что-то другое видят.
Самые большие хотели из с11 это стилизированные закладки со скосами и управление цветом заголовков в LIST. Из-за этого менять рантайм и отказываться от mdi что-то как-то не очень убедительно. Может, скоро произойдёт чудо, и RZ что-то такое покажет, что хочу это перекроет другие доводы разума. Например, кажись в следующем месяце по плану должен появиться clarion 64.

А так, если выкинуть mdi и маски, особых проблем в рантайме с11 вроде как и не всплывало.

[Игорь Столяров]

Сборка под с6 работает отлично, вообще без нареканий. Сборка с11 - то одно выскочит, то другое.

Мне кажется - это и есть ключевое место. Вы воспринимаете C11 как С6 с модными прибамбасами.
И считаете, что C11 полностью совместим и должен собирать все те же проекты, что отлажены у Вас для C6.
Это не совсем так, к сожалению ... Мы много лет вели разработку в C6.3, а собирали финишный проект в C10 / C11.
Год назад перешли на С11 и лично выкосил штук 30 раличных костылей убирающих расхождение в версиях.
И это при том, что были уже вообще убраны всякие косяки C11 вроде BIND() массивов в BROWSE и т.д.
Одни MDI окна в запросах на REPORT сколько крови выпили ...

[finsoftrz]

Я просто пытаюсь понять, что получу, если переведу приложение на с11, а что при этом потеряю. Пока баланс не в пользу с11, увы. В чем смысл втуливать пользователю кучу дополнительных кнопарей в каждое окно. Почему в приложениях, где 99% работа с цифрами, я должен отказываться от контроля ввода этих цифр по маске. Что можно предложить взамен удобной строки для поиска в таблицах на тулбаре. Почему я не могу использовать тулбокс с калькулятором и контрольной ленточкой, плюс режимом эхо суммирования (когда в любом окне можно выделить число в поле ввода или ячейке LIST и нажать клавишу прибавления/вычитание, что сразу отражается в результате и контрольной ленте). Что предложить взамен тулбокса, на котором выводится индикация о напоминания, быстрых сообщениях от других пользователей и тп. Да, я могу сделать фиксированный тулбокс с пользовательским меню, но почему я не могу тут же повесить кнопку для включения в него команд, а должен объяснять пользователю, что нужно идти куда-то в настройки. И таких вопросов набирается довольно критична масса. Я понимаю, если всего этого нет в приложении и не планируется делать, то можно спокойно пересесть на с11 (если какие-то старые сторонние либы ещё не держат). А вот если все это уже есть и много лет используется реальными пользователям, задумаешься.

[Игорь Столяров]

Я полностью согласен, что нет смысла ломать работу пользователей только из-за перехода на C11.
Значит как Вы и говорили - старые проекты остаются на C6, а в новых уже ищутся какие-то альтернативы ...
Мы тоже многое перенастраивали, но это было эволюционно растянуто во времени.