slav_z

Пользователи
  • Публикаций

    27
  • Зарегистрирован

  • Посещение

  • Победитель дней

    4

slav_z стал победителем дня 9 января

slav_z имел наиболее популярный контент!

Информация о slav_z

  • Звание
    Пользователь

Посетители профиля

140 просмотров профиля
  1. в FMX очень удобно делать модальные диалоги поверх всей формы. прозрачный layout сверху (по клику закрывается модальная форма - просто разрушается layout со всем содержимым - 1 случай) конкретное содержимое кладется на него там, конечно, можно расположить кнопку закрытия диалога и все остальное... по нажатию на эту кнопку также разрушается layout - 2 случай. кнопка разрушается через разрушение своего Owner-а. Но это тоже самое что и разрушить кнопку по нажатию на саму себя.
  2. Owner - отвечает за разрушение "своих" объектов при собственном разрушении. Parent отвечает за прорисовку "своих" объектов. Какая еще иерархия объектов? визуальная иерархия - да... было бы неплохо что бы эта иерархия отвечала и за выравнивание объектов - но нет... не знаю когда в delphi будет нормальное выравнивание... может еще лет 20 подождать...
  3. но не в FMX !!! в FMX Parent (панель) при своем разрушении разрушит и кнопку. Вот это неправильно.
  4. Я бы сформулировал вопрос по-другому. Чем отличается Owner и Parent? Для чего нужен тот и другой. Почему это разные объекты? Ярослав, дайте пожалуйста четкое пояснение как разработчик FMX. Я думаю многим здесь это будет интересно.
  5. разработчики FMX по каким-то неведомым причинам сделали так, что визуальный контейнер при своем уничтожении так же разрушает и те компоненты, которые отображает (достаточно было просто обнулить Parent). такого никогда не было в VCL. это плохо и неправильно. это работа Owner а не Parent. Поробуйте создать элемент Create(Owner) и указать какой-нибудь посторонний Parent не принадлежащий Owner. При разрушении получите AV (сначала элемент будет разрушен Parent-ом а затем то же самое попытается сделать и Owner... нет там никаких нотификаций и подписок). я постараюсь далее не вступить в спор... но ничего не обещаю...
  6. замени TFrame13.Create(nil) на TFrame13.Create(Self) только ради бога не спрашивай зачем... проверка на дублирование имени выполняется родителем... а он у тебя nil.
  7. будет. но вместо := 'frame_'+i.toString; можно просто "обнулить" имя :='';
  8. напугать получилось... дай пять! да не... нет проблем с этим...
  9. да нет смысла... это сложнее чем назначить пустое имя при создании. F:=TFrameClass.Create(Self); F.Name:=''; ...
  10. я про TFrame.. конечно всяким TLable и т.п. имя назначать ни к чему... Фреймы получают имя в designtime и создаются (динамически) с этим именем.
  11. теперь все понятно. спасибо.
  12. но есть еще проблема: Если сразу после Release попытаться создать элемент заново (TFrame), то будет ошибка дублирования имени компонента (старый компонент еще жив в списке компонентов родителя). Поэтому кроме Parent := nil (убрать элемент с экрана) еще необходимо Name := ''; короче... жуть какая-то.
  13. Намного проще оставить в покое метод Release.
  14. FreeAndNil() не подойдет... проблема в том, что после вызова OnClick() далее еще происходят вызовы методов самого объекта (см. исходники FMX.Forms) и если разрушить объект на OnClick, то будет AV (не каждый раз - а как повезет... ).
  15. отдельный поток для "убийства" объекта? брутально! вот как сделано в 10.2.3 : procedure TFmxObject.Release; begin if not (csDestroying in ComponentState) then begin if (Application <> nil) and (Action <> nil) then Application.UnregisterActionClient(Self); Parent := nil; TThread.ForceQueue(nil, procedure begin Self.DisposeOf; end); end; end;