В дочерних окнах из DLL не работают

← →
ValeraVV (2001-12-20 13:50) [8]

1. Результат не должен был убить систему (если конечно делалось то, что говорил Алексей Петров ©)
2. Оператор is сравнивает два указателя на класс (правда первый указатель бежит вверх по иерархии) и если эти два pointer совпали то можно сказать, что obj is TObject. Соотвественно, когда вызывается невиртуальный и не published метод объекта, точно можно сказать, что адрес метода берется из информации, сгенеренной компилятором. Если главный EXE и DLL-ки компилились отдельно, то для них это разные методы - результат не предсказуем.
3. Еще, IMHO, VMT не генерится в памяти для каждого создаваемого объекта (имеется в виду TObject, не object), а лишь дается ссылка на общую структуру для класса, тогда пункт два справедлив и для virtual methods
4. Если не используются пакеты, глобальные переменные в создаются в контексте главного thread"а, но в разных местах. В пакетах, при использовании threadvar на каждый thread одна переменная, не зависимо от модуля
5. Процедура перехода на пакеты не так уж сложна (поставить у всех проектов галочки и откомпилить) и скорее это сэкономит ресурсы, если DLL много и, к тому же, в них строятся VCL окна, а взаимодействие сводится к минимуму (иначе проблемы возникли бы раньше)
5. Если Microsoft делает огромный каталог system32 и юзает его из всех своих программ, еще в добавок для своего VC делает рантайм DLL-ки, а для своего VB тем более, то почему бы нам не использовать BPL, где не просто импортируются процедуры, но и отслеживается информация о классах, их иерархии и пр., тогда это не минус Delphi (в смысле у ilysha проблемы с Popup ShortCut"ами), а плюс.

Все что выше мои изыскания за Петрова, а к проблеме ilysha все-таки мало отношения имеет, точнее на 50%, путаница возникает либо из-за неправильного определения класса объекта из другого модуля, либо из-за неправильных/не указанных handl"ов окон (что делается через Application, Owner, Parent)

В дочерних окнах из DLL не работают Найти похожие ветки