После загрузки 1С++ перестают создаваться объекты из других компонентов, написанных по технологии Rainbow. Точнее сразу после загрузки 1С++ объект создается успешно РОВНО ОДИН РАЗ. После этого СоздатьОбъект выполняется без ошибки, но возвращает НеизвестныйОбъект. Не работало на моих компонентах, но для воспроизведения ошибки можно использовать и общедоступные, к примеру тот же vkloader, с помощью которого тоже пробовал загружать старую версию 1С++. Результаты везде одинаковые.

Если ЗагрузитьВнешнююКомпоненту(КаталогИБ()+"vkloader.dll")=0 Тогда
	Сообщить("Ошибка загрузки vkloader");
КонецЕсли;

Загрузчик=СоздатьОбъект("ЗагрузчикВК");
Сообщить("= "+Загрузчик); // = ЗагрузчикВК
Загрузчик=СоздатьОбъект("ЗагрузчикВК");
Сообщить("= "+Загрузчик); // = ЗагрузчикВК
Загрузчик=СоздатьОбъект("ЗагрузчикВК");
Сообщить("= "+Загрузчик); // = ЗагрузчикВК

// Для версии 3.0.1.22
//Рез=Загрузчик.ЗагрузитьВК(КаталогИБ()+"1cpp.dll", "Addin.1C++=fde5ae76-00b3-4bdb-921b-d5937997b1b7");

// Для версии 3.2.3.20
Если ЗагрузитьВнешнююКомпоненту(КаталогИБ()+"1cpp.dll")=0 Тогда
	Сообщить("Ошибка загрузки 1C++");
КонецЕсли;

Загрузчик=СоздатьОбъект("ЗагрузчикВК");
Сообщить("= "+Загрузчик); // = ЗагрузчикВК
Загрузчик=СоздатьОбъект("ЗагрузчикВК");
Сообщить("= "+Загрузчик); // = НеизвестныйОбъект
Загрузчик=СоздатьОбъект("ЗагрузчикВК");
Сообщить("= "+Загрузчик); // = НеизвестныйОбъект
 

Порядок загрузки значения не имеет. Перепробованы все варианты. Грузить первой 1С++, грузить все компоненты вначале, в середине, вперемежку. Результаты одинаковые.

Также попробовано с вкл/откл TurboBL.

Можно еще так:

Если ЗагрузитьВнешнююКомпоненту(КаталогИБ()+"1cpp.dll")=0 Тогда
	Сообщить("Ошибка загрузки 1C++");
КонецЕсли;
Если ЗагрузитьВнешнююКомпоненту(КаталогИБ()+"vkloader.dll")=0 Тогда
	Сообщить("Ошибка загрузки vkloader");
КонецЕсли;
Если ЗагрузитьВнешнююКомпоненту(КаталогИБ()+"test.dll")=0 Тогда
	Сообщить("Ошибка загрузки test");
КонецЕсли;

Загрузчик=СоздатьОбъект("ЗагрузчикВК");
Сообщить("= "+Загрузчик+" "+ТипЗначения(Загрузчик)); // = ЗагрузчикВК 100
Загрузчик=СоздатьОбъект("ЗагрузчикВК");
Сообщить("= "+Загрузчик+" "+ТипЗначения(Загрузчик)); // = НеизвестныйОбъект 100
Загрузчик=СоздатьОбъект("ЗагрузчикВК");
Сообщить("= "+Загрузчик+" "+ТипЗначения(Загрузчик)); // = НеизвестныйОбъект 100

Загрузчик=СоздатьОбъект("Тест");
Сообщить("= "+Тест+" "+ТипЗначения(Тест)); // = Тест 100
Загрузчик=СоздатьОбъект("Тест");
Сообщить("= "+Тест+" "+ТипЗначения(Тест)); // = НеизвестныйОбъект 100
Загрузчик=СоздатьОбъект("Тест");
Сообщить("= "+Тест+" "+ТипЗначения(Тест)); // = НеизвестныйОбъект 100
 

Каждый объект создается ровно один раз.

Проверено также отладчиком: при втором и последующих созданиях объекта никаких попыток вызова CreateObject не происходит.

1С++ перехватывает какие-то функции по созданию объектов? Кто знает, скажите откуда хотя бы начать копать?

Ну, супер, документируйте где-нибудь, какие именно изменения требуются, чтобы все было норм.
Можно исходник исправленный прикрепить сюда.
Хорошо бы еще и этот test.dll тоже с исходником, чтобы можно было проверить и убедиться.
Напишем Артуру (artbear), он давно хотел сделать что-то хорошее.

Проверил vkloader. Да, действительно, объект создается только 1 раз при загруженном 1с++.

Интересно. Вот например Formex - тоже реализован по технологии rainbow. Люди не жалуются на несовместимость с 1с++.
У меня есть куча ВК по той же, так называемой технологии rainbow. С ними тоже я проблем не наблюдаю.

ps под технологией rainbow я понимаю: линкование библиотек v7 и регистрация классов непосредственно через CBLContext::RegisterContextClass, а не по ТСВК через интерфейс LanguageExtender

pps Просто наблюдения

dfuy писал(а) 18. Марта 2013 :: 11:25:
ты обратись к Саше. У него есть более свежий "движок" (набор шаблонов) для написания ВК. Я писал все свои ВК на нем. Проблем нет. Скорее всего он поделиться.

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

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

Кстати, предварительная проверка показывает, что дллка грузится прекрасно на компах юзеров без COneAddinImpl. Завтра проверим более масштабно.

Простите за флуд, но охота излить мысли куда-нибудь. Как закончу работу над новым "движком", может выложу его куда-нибудь в отдельную тему, а пока напишу сюда.

Дак вот, прибирал я структуру Runtime классов. Поломав голову, получилось реализовать ее правильное (причем автоматическое!) формирование с помощью тех же шаблонов, даже при наследовании их друг от друга. А раз уж такое дело, стал реализовывать возможность наследования вообще (ну а че зря пропадать-то такому добру). Весь мозг вынес. Структура шаблонов усложнилась до того, что компилятор перестал компилировать код, вылетая в рандомных местах в Internal Compiler Error. А если и компилировал, то вылетала уже программа с переполнением стека (компилятор вместо вызова функции из базового типа вызывал саму себя), Acces Violation'ами и прочими прелестями. Шаманскими действиями над кодом (к примеру, вместо вызова типа SomeClass:Prev:SomeFunc() пишем метод SomeClass:PrevSomeFunc(), а он уже вызывает Prev:SomeFunc()) удалось-таки добиться правильной компиляции кода. Возможно, более новые компиляторы так издеваться над прогой не будут, так что если уж удалось скомпилить под VS6, остальные должны делать на раз.

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

текущая версия "движка" с наследованием: