SB
Либо там где-то аварийный выход через halt()
Size: a a a
2020 February 08
DB
тут еще вопрос - нужен ли инстанс этого класса один на форму или достаточно одного на юзера или даже вообще одного на всё приложение. если так - то можно его создавать и разрушать либо в TUniMainModule либо вообще в TUniServerModule
ГМ
constructor create;
destructor Destroy;
end;
а здесь нужен override?
destructor Destroy;
end;
а здесь нужен override?
На create override может быть не нужен, а на destroy точно нужен
AS
Специфика приложения UniGUI такова, что Destroy модуля может выполниться при перезагруке страницы, т.е. после создания модуля, я уже пытался... не знаю как это объяснить
А это не документировано?
AS
constructor create;
destructor Destroy;
end;
а здесь нужен override?
destructor Destroy;
end;
а здесь нужен override?
виртуальные методы обычно всегда надо перекрывать (override). Если этого не делать, то компилятор даже будет подсказки выдавать (по крайней мере, последние его версии)... Но кому нужны подсказки компилятора? их же так много, что на них смотреть? Что там может быть важного?
ГМ
виртуальные методы обычно всегда надо перекрывать (override). Если этого не делать, то компилятор даже будет подсказки выдавать (по крайней мере, последние его версии)... Но кому нужны подсказки компилятора? их же так много, что на них смотреть? Что там может быть важного?
Он точно не будет предупреждать, если ты не переопределишь destructor, а вызываться он не будет
KB
На create override может быть не нужен, а на destroy точно нужен
добавил override; Destroy; вроде помогло
ГМ
По поводу проблем с утечками, возникла у меня идёя. Возможно костыль, но просто хочу поделиться. Ещё не продумал до конца эту идею, но это детали.
В общем, это подражать классу TComponent, т.е. всегда в конструкторе указывать родителя. Родителем будет особый класс, который инициализируем и уничтожаем модулем (init.., final...). Родитель уничтожит все дочерние объекты как TComponent.
Сильно не пинайте, придумал только что.
В общем, это подражать классу TComponent, т.е. всегда в конструкторе указывать родителя. Родителем будет особый класс, который инициализируем и уничтожаем модулем (init.., final...). Родитель уничтожит все дочерние объекты как TComponent.
Сильно не пинайте, придумал только что.
KB
тут еще вопрос - нужен ли инстанс этого класса один на форму или достаточно одного на юзера или даже вообще одного на всё приложение. если так - то можно его создавать и разрушать либо в TUniMainModule либо вообще в TUniServerModule
та сейчас это не важно, думаю, что один на пользователя хватит, исходные данные для списка меняются редко
KB
inherited забыл
override забыл :)
ГМ
override забыл :)
Я тоже так пару раз обжигался
KB
виртуальные методы обычно всегда надо перекрывать (override). Если этого не делать, то компилятор даже будет подсказки выдавать (по крайней мере, последние его версии)... Но кому нужны подсказки компилятора? их же так много, что на них смотреть? Что там может быть важного?
вот как раз при отсутствующем override у деструктора и не выдал :(
ГМ
вот как раз при отсутствующем override у деструктора и не выдал :(
А у TObject Destroy как раз vitrual)
KB
а при вызове .Clear() точно происходит очистка объектов? или только при .free()?
только что проверил - достаточно просто TObjectDictionary.free
KB
А у TObject Destroy как раз vitrual)
??
ГМ
class = TObject
KB
я что-то ещё забыл?
KB
class = TObject
всё равно не понял
ГМ
я что-то ещё забыл?
Тебе сказали, что методы vitrual нужно переопределять override, так?
KB
ага