forum.clarionlife.net

Интересный вопрос, где больше работающих проектов, на рантайме с6 или на рантайме с11.
У вас ситуация другая и проекты на более массовую аудиторию. Наверно, вам действительно важна поддержка манифеста для вин10.

finsoftrz писал(а): ↑12 Май 2024, 8:33 на рантайме с6 или на рантайме с11

Судя по тому, что иногда выкладывают на ClaHUB - это проекты под RunTime C11, но тупо сконвертированные из C 55/ 63 Legacy.

Кроме двух поверхностых прибамбасов (манифест и поддержка AnyScreen) RunTime C11 всё-таки содержит ещё 15 лет изменений.
Например, мне очень понравилась реально заработавшая поддержка уведомлений между потоками (NOTIFICATION)
вместо событий (EVENT) и т.д. В старом Run-Time тоже были свои фишки, но его всё-равно уже никто его не воскресит.

NOTIFICATION и в c6 работает, я им пользуюсь.
Я бы не стал называть манифест и anyscreen поверхностными прибамбасами. Благодаря манифесту работает та версия гуя, которую Вы любите. А anyscreen позволяет приложениям работать как веб приложения. На самом деле это все круто. Если бы не многочисленные недоработки, вопросов бы не было.
Основные изменения были первые лет 5. Потом все сдулось, много народа отвалилось.

Поверхностные - в том плане, что сразу видны тем, кто делает тестовые сборки с RTL C11.
А с C63 я уже наверно ушёл одним из последних. Но для меня всегда был важней результат, чем инструмент.

Игорь Столяров писал(а): ↑12 Май 2024, 12:26 Поверхностные - в том плане, что сразу видны тем, кто делает тестовые сборки с RTL C11.
А с C63 я уже наверно ушёл одним из последних. Но для меня всегда был важней результат, чем инструмент.

Я думаю, что много народа и сейчас на с63 сидят. Может, даже больше, чем на с11. Просто они в интернете не особо светятся.

Смотря что под результатом понимать. Если конечное приложение, то оно и там, и там одинаковое. А если потраченное на его разработку или поддержку время, то тут без нормального инструмента грустно. Можно, конечно, опустить планку, и считать нормальным потратить часы там, где на нормальном инструменте будут минуты. Достаточно просто не думать и не хотеть знать про это.

finsoftrz писал(а): ↑12 Май 2024, 12:44 Я думаю, что много народа и сейчас на с63 сидят

Скорее досиживают - это игра со временем.
Если есть замкнутая бизнес-система учёта, проект и инструмент - то можно ничего и не менять.
Но ничего нового (включая разработчиков) там уже не будет.
Просто поддержка ... и потом стремительным домкратом на 1С.

Лучше на заслуженный отдых. Ситуация у тех, кто на с11 - аналогичная.

Игорь Столяров писал(а): ↑12 Май 2024, 8:18 Но мы честно перевели всё на RunTime C11 без распараллеливания проектов. Умерла - так умерла.

Аналогично!

ДД !

Интересное наблюдение. C11.1 & ABC.

Если для шаблонной процедуры включить опцию "Preserve Local Variables" - то значения считываются всегда.
А вот записываются, только если для окна включена опция "Save and Restore Window Location" ...
Печаль !

Игорь Столяров писал(а): ↑09 Июнь 2024, 18:36 ДД !

Интересное наблюдение. C11.1 & ABC.

Если для шаблонной процедуры включить опцию "Preserve Local Variables" - то значения считываются всегда.
А вот записываются, только если для окна включена опция "Save and Restore Window Location" ...
Печаль !

Обсуждали сто лет назад. Я делал себе исправление. Если надо, могу найти и поделиться. SV такими мелочами заниматься не будет.

kreator писал(а): ↑10 Июнь 2024, 19:23 Если надо, могу найти и поделиться

Спасибо ! Не надо. Просто никогда не пользовался, обычно вручную записывал значение в реестр или INI файл.
А тут смотрю, красота-то какая ! Но нет, снова опыт.

Игорь Столяров писал(а): ↑10 Июнь 2024, 22:08 Спасибо ! Не надо. Просто никогда не пользовался, обычно вручную записывал значение в реестр или INI файл.
А тут смотрю, красота-то какая ! Но нет, снова опыт.

Такого очень много. Поэтому переход на свежий билд занимает немалое время. Всегда проверяю - вдруг исправили. Я предпочитаю самостоятельно исправить что-то в классах или шаблонах вместо ручного обхода проблемы.

kreator писал(а): ↑11 Июнь 2024, 16:07 Поэтому переход на свежий билд занимает немалое время.

Вот поэтому и не надо !
Если косячит функционал в шаблоне, лучше найти другое решение, чем потом всё выверять.
Тем более, что в данном случае, функционал вообще не военный.

kreator писал(а): ↑11 Июнь 2024, 16:07 Всегда проверяю - вдруг исправили. Я предпочитаю самостоятельно исправить что-то в классах или шаблонах вместо ручного обхода проблемы.

При нахождении затыков (ошибок) в базовом шаблоне действует следующий алгоритм
1. Если проблему можно решить малой кровью (некие действия в коде, написание дополнительного шаблона для реализации функционала...), то решается малой кровью, с продолжением использования базовых шаблонов
2. Если единственный путь исправления - правка в самом шаблоне, то правится базовый шаблон с сохранением исходного и сравнением при каждом билде.

На сегодняшний день вариант 2 был использован лишь один раз - в шаблоне обработки Notify, где всё написано так, что своего не воткнёшь. Во всех остальных случаях реализован вариант 1, при том дополнительные заплатки в коде программы потребовались 2 раза (шаблон Tree и шаблон генерации отчётов), а во всех остальных случаях решалось навешиванием собственного шаблона.

Есть практика эмпирическая практика применения шаблоноправления :
--------------------------------------------------------------------------------------------
1. Если проблемы при поддержке кода программы неизбежны - исправляем шаблоны.
2. А как узнать, что проблемы при поддержке кода программы неизбежны ?
3. Если исправлять шаблоны - то проблемы при поддержке кода программы будут неизбежны !