OberonCore

Принципиально я согласен! что сейчас код с немодальностью несовместим. Так как надо делать через обратные вызовы, как я сделал GetAction в Dialog. Так надо и выбор цвета и шрифта переделывать.

Меня тревожит, что Views.Old немодально не открыть. ББ просто зависнет на многих линуксах, так как попытается открыть модальный диалог, который рушит процесс.

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

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

хотя бы временно добавить, написав большими буквами в исходниках, что не надо эту фичу использовать, её когда-нибудь удалят. как будто такие предупреждения хоть раз кому-то помогали, конечно. ;-)

Страшная тайна в том, что это можно сделать через сопрограммы. Сопрограммы для Windows описаны хорошо в сборке Центра, а для Linux в одном из расширений Дмитрия Викторовича Дагаева они тоже сделаны! Однако это сделано для старых ядер, до того, как они были рассечены для упрощения репозитория и более удобной кросс-компиляции и кросс-сборки. Но это всё возможно освежить, внедрить и радоваться модальным окнам, которые сделаны будут в самом Блэкбоксе. Только это всё займет какое-то феерическое количество времени, чтобы внедрить и отладить. Однако при наличии мотивации, с пониманием, зачем и куда вы это внедрите, я думаю, что всё возможно.

У меня пока такой "ленивый" план, чтобы документировать опасные моменты "не вызывайте в Linux Views.Old, используйте только Dialog.GetIntLocName Dialog.GetExtLocName"

да, я про сопрограммы тоже упоминал. ;-) и я в курсе, что сейчас их нет. в теории я могу их сделать; а на практике, конечно, надо сначала вдумчиво почитать ядро (ядра), и посмотреть, чего там не хватает. как минимум работу со стеком, видимо, надо будет менять, и скорее всего не только. поэтому я их и не рассматривал пока как практический вариант.

проблемы, правда, всё равно останутся. например, мы вызвали такой «псевдомодальный» диалог выбора файла по кнопочке (ну, в декодере, например), а потом окно декодера закрыли. и бедному диалогу больше некуда возвращаться, висит он неприкаяный, а потом и вовсе трапается. тут тоже плотно думать надо, просто возможности иметь рабочие сопрограммы мало.

Чтобы не изобретать велосипед, обязательно посмотрите
https://community.blackboxframework.org ... .php?t=164

спасибо! да, я видел эту тему. но вряд ли я буду заниматься сопрограммами в ближайшем будущем, и так слишком много всего уже запланировано, тут хоть бы малую часть доделать, а не распыляться…

Тоже верно. У меня такая же ситуация.

Пока по плану:
1. Внедрить ваши наработки элементов управления, доработать многострочность, если вы переключитесь на другие задачи
2. Починить сохранение/загрузку верстаков
3. Обновить ветку master

Сопрограммам в ядре делать нечего. Исключили их оттуда и правильно. Отдельным модулем если только.

Модальные, конечно, нельзя, поскольку "модальный цикл" прерывает отрисовку. То, что я делал - как раз немодальные диалоги о закрытии, они вставлялись сразу во все несохранные окна. У меня они были вверху окна, как панелька, но для Ивана я сделал вариант, когда диалог рисовался поверх содержимого окна; впрочем, он его тоже отверг в пользу модальных диалогов.

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

Эмулировать модальность - т.е. запретить польз-лю на время работу с любыми окнами, кроме модального - это можно, конечно, и даже есть где-то в старых ББ. Например, если на атомной станции нужен срочный ответ оператора реактора )) - Д.В. такой пример приводил в пользу модальности. Но циклы и алгоритмы придется переделывать.

Views.Old не надо запрещать и маркировать красным. Надо Views.ask и Files.ask. Это вот хакостыль - но, возможно, он был неизбежен, ведь ББ должен был использовать ВинАпи-диалоги выбора файлов.

почему нельзя? мне думается, можно. придётся сделать отдельный диспетчер, который рассылает только update-сообщения (и избранные poll), запретить активацию других окон и меню — и, в принципе, должен получиться вполне рабочий модальный цикл, который можно крутить в отдельной процедуре, нет?

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

кстати, никогда не использовал, всегда казалось, что оно там как-то не к месту.

согласен. просто выкинуть их, да и всё. точнее, сигнатуру процедуры не менять, но сделать HALT(низя!) с ними. тогда у людей код красиво трапнется, они пойдут посмотреть, что ж такое — и увидят в коде комментарий, где написасно, что так нельзя, и куда читать, чтобы узнать, чем заменить.

Я бы тоже повыкидывал. Именно с удалением параметра, все равно совместимость с 1.7 уже потеряна. Параметры ask кстати добавили в версии 1.4, тоже сломав совместимость со старым кодом. Для мажорных версий фреймворка это норма.

У меня что-то в Mint с недавних пор начал нормально открываться гткашный модальный диалог выбора файлов. Не знаю, как в других дистрибутивах. Однако это не повод менять отношение к его замене, конечно, но такое наблюдение.

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