Заставить ТурбоБЛ в составе 1С++ заново прочитать методы

[АЛьФ]

Кто-нибудь из знатоков 1С++ знает возможен ли сабж?
Обнаружилась проблема метода Сервис::ЗагрузитьВнешнююОбработку() при включенном ТурбоБЛ. Последний кэширует номера методов и при изменении на лету модуля обработки начинает вызывать всякие не те процедуры вместо тех.

[Злоп]

Отключить ТубоБЛ (тут м.б. дернуть какой-то простой метод) и заново включить?

[АЛьФ]

Отключить ТубоБЛ (тут м.б. дернуть какой-то простой метод) и заново включить?

Не помогает. Даже просто отключение не помогает до перезагрузки 1С.

[Djelf]

Вроде делали Система.ОбновитьДанныеГК(Контекст) но работает или нет, в этом случае, я не в курсе.

[АЛьФ]

Вроде делали Система.ОбновитьДанныеГК(Контекст) но работает или нет, в этом случае, я не в курсе.

У меня в Сервисе Артур делал такой метод, судя по его комментам в исходниках, как раз для такого обновления. Но не сработало. Попробую в 1С++ метод это найти.

[АЛьФ]

Вроде делали Система.ОбновитьДанныеГК(Контекст) но работает или нет, в этом случае, я не в курсе.

Спасибо огромное! Помогло. Буду пытаться повторить код этого метода у себя при загрузке внешней обработки.

[АЛьФ]

А вот в связи с этим глюком возник еще один концептуальный вопрос.
Получается, что при закрытии формы в 1С групповой контекст не уничтожается, а остается висеть в памяти. И при следующем открытии формы обработки подхватывается старый контекст, в котором просто инициализируются внутренние переменные.
Похоже, что я сейчас, при разработке функционала дополнительных кнопок в реквизитах, столкнулся с той же проблемой. Класс CGroupContext содержит массив объектов CRefContext, которые в свою очередь имеют свойство - ссылку на CBLContext. При уничтожении CGroupContext вызываются деструкторы CRefContext. В этом деструкторе уничтожается сам объект CRefContext, но не CBLContext, на который он ссылается. И получается, что CBLContext зависает в памяти.
Пока писал подумал, что что-то тут не вяжется. Если бы действительно групповой контекст не уничтожался, я бы на свою проблему не наткнулся бы. Значит проблема с ТурбоБЛ именно в его реализации - таблица методов строится по типу контекста и для разных объектов используется своя. А отсюда вырисовывается еще одна проблема: недостаточно будет для загружаемой внешней обработки вызвать ОбновитьДанныеГК, открытые ранее обработки этого вида начнут глючить.
Выхода пока не вижу. Только если восстанавливать умение сборки 1С++ и править ТурбоБЛ, чтобы общая таблица методов вида копировалась для каждого объекта этого вида.

Хорошо, что я не склонен к суициду...

[АЛьФ]

После изучения исходников 1С++ родилось простейшее обходное решение проблемы ТурбоБЛ: опставить первым символом в модуле #. ТурбоБЛ воспринимает это, как загрузку модуля из файла и строит каждый раз карту методов заново. А 1С просто игнорирует этот символ.
Добавлю в свой метод ЗагрузитьВнешнююОбработку добавление этого символа в загружаемые объекты.

И надо будет это учитывать при планируемой разработке метода ЗагрузитьМодульОбънета.
Хотя забуду, конечно...

[trad]

Если не разрушается CBLContext значит есть циклические ссылки, а их быть не должно

[АЛьФ]

Если не разрушается CBLContext значит есть циклические ссылки, а их быть не должно

Насколько я вижу по IDA, в деструкторе CGroupContext идет в цикле вызов деструктора CRefContext для каждого элемента массива, а в деструкторе CRefContext тупо уходит в код базового деструктора CBLContext. А вот для ссылки CBLContext, хранимой в CRefContext, даже DecrRef() не вызывается.
Если я в групповой контекста добавляю свой контекст, то он зависает в памяти. Может другие контексты 1С как-то отдельно уничтожает, но сомнительно.

[АЛьФ]

Сколько лет с семеркой вожусь, каждый раз нахожу что-то новое.
Нигде раньше не встречал, что вот такой модуль не дает синтаксической ошибки и нормально работает:

Код Выделить Развернуть

#Какой-то текст с пробелами
#Еще какой-то текст
#И еще много-много строк
Перем Сервис;

Процедура Сформировать()
КонецПроцедуры

[trad]

в 1с++ это используется в модулях определении классов и в директивах препроцессора

[АЛьФ]

в 1с++ это используется в модулях определении классов и в директивах препроцессора

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

[trad]

Так и я про то что компилятор и синтакс контроль игнорирует строки на # и 1спп это использует для выражений описания классов и препроцессора

[Djelf]

Нет. Ты что-то путаешь. Сам попробуй вставить что-то подобное не в самом начале модуля, а после объявления любой переменной, с начальной решеткой.
Так не получится!
Препроцессор Классов 1с++ работает через //# Команда и никак иначе.

АЛьФ, а это интересная находка, как бы теперь придумать как эту фичу можно использовать...