kami

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

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

  • Посещение

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

    40

kami стал победителем дня 17 сентября 2018

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

4 Подписчика

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

  • Звание
    Продвинутый пользователь
  • День рождения 16.06.1981

Контакты

  • StackOverflow
    http://ru.stackoverflow.com/users/192901/kami

Информация

  • Пол
    Не определился
  • Город
    Санкт-Петербург

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

1 078 просмотров профиля
  1. У меня - нет. Емнип, Owner-ом для всех наброшенных на форму компонентов выступает сама форма. Вне зависимости от уровня вложенности визуальных компонентов. Для невизуальных объектов овнер нужен, если они покладены на форму в дизайн-тайме. Parent-а у невизуального объекта нет, а правило "не ты создал - не тебе удалять" выполняться должно. Это из того, что на поверхности. А какие реальные причины заставили иметь не только парента, но и овнера, да еще и для дизайн-тайм... Возможно, действительно без них никак. Давайте только без привлечения ARC "ничего удалять не надо, если и владелец и родитель удалятся, ссылки на объект закончатся и он самоуничтожится".
  2. Понаехавших - нет, не учат. Раненых особенно. Тебе эпитеты тоже подобрать? По сути вопроса? Как ты говоришь "накидывание" возникло от того, что для решения не самого сложного вопроса здесь озвучены (в том числе -тобой) рекомендации и выводы, от которых потом сложно не удивляться - откуда столько говнокода в экосистеме Делфи? Да вот отсюда, из таких топиков на форумах, которые неокрепшие (да и окрепшие) умы впитывают и несут потом в массы. Удивительно, что еще не затронули "уникальное имя нужно, потому что по нему потом будем искать этот компонент"...
  3. Upd. Нет, похоже в fmx механизм FreeNotification не используется для уничтожения. Но это не мешает всему хозяйству уничтожаться корректно, какие бы родители с владельцами ни указывались
  4. Предположил на основании твоего вывода " не будет ошибки дублирования? по моему будет ", который проверяется и опровергается за 2 минуты. В результате вместо того, чтобы понять откуда ноги растут у ошибки дублирования имен - вы имеете костыли типа "по этой причине именовали := 'frame_'+i.toString; "
  5. Уничтожение и в VCL и в FMX идет именно Parent-ом. Owner получал уведомления (FreeNotification / RemoveFreeNotifications) и убирал высвобожденные ссылки из своего списка на уничтожение. Потом уничтожал свое. Это дефолтное поведение, сложившееся издавна, оно же без изменений перекочевало в FMX, единственное - находятся методы FreeNotification / RemoveFreeNotifications в разных классах. Нет, это далеко не так. Parent-ом действительно уничтожается всё дочернее. Но Owner после этого ничего сделать уже не может, потому что он уже не знает об уничтоженном компоненте: destructor TComponent.Destroy; begin ... if FOwner <> nil then FOwner.RemoveComponent(Self); Ну и напоследок: procedure TForm12.btn1Click(Sender: TObject); var fm: TForm; fr: TFrame13; i: Integer; begin fm := TForm12.Create(Self); // создаем дубликат try for i := 0 to 5 do begin fr := TFrame13.Create(Self); // Owner - главная форма // на фрейм накидал эдитов, лейблов - чтобы не пусто было. fr.Name := 'fr' + IntToStr(i); fr.Parent := fm; // а Parent - вторая форма того же класса. fr.Align := TAlignLayout.Right; end; fm.ShowModal; finally fm.Free; // уничтожаем вторую форму end; // и потом, при закрытии главной формы всё кошерно. end; Что я делаю не так?
  6. Вы выискиваете какие-то обходные маневры, генерацию уникальных имен с привлечением guid, обнуление имени после создания... а на самом деле ничего из этих костылей не нужно.
  7. Родитель-то как раз не nil. Владелец nil. Позвольте поинтересоваться, а какой профит помимо счастья обладания геморроем (который сам себе же и сделал) принесет создание компонента с указанием владельца? Единственный плюс, который мог бы быть - владелец при высвобождении себя уничтожает всё, чем он владеет. Но вот беда-то... родитель тоже это делает, причем - раньше. И благодаря подпискам на уведомления владелец узнаёт, что компонента, которым он владел, уже нет, т.е. попытки двойного уничтожения НЕ будет.
  8. попробовать религия не позволяет? Только что написанный код: var i: Integer; fr: TFrame13; // отдельный фрейм, у которого в ObjectInspector так и написано: Name = Frame13 begin for i := 0 to 5 do begin fr:=TFrame13.Create(nil); fr.Parent:=Self; fr.Align:=alRight; end; всё отрабатывает без проблем, никаких вопросов по именованию рантайм-компонентов не возникает.
  9. помнится, отвечал уже кому-то на форуме. Для динамически создаваемых компонентов просто не указывайте имя. Не нужно оно им. Тогда эта проблема отпадает сама собой.
  10. И еще в тему ForceQueue. Как-то раз потребовалась мне конструкция типа "отложенное действие после отложенного действия". Дык вот, если сделать вот так: TThread.ForceQueue( procedure begin SomeAction; ForceQueue(SomeAnotherAction); end); то SomeAnotherAction выполнится сразу же вслед за SomeAction, а не на новом витке Application.Idle. Всё дело в том, что выполнятель Queued-действий просто достает их из списка, пока не закончатся. Т.е. выполняется первый ForceQueue, а вложенный, как таковой, не выполняется: второе действие помещается в список, тут же достается из него и сразу же выполняется! Как результат - при таком вызове де-факто получается срабатывает только первый ForceQueue, а вместо второго выполняется прямой вызов действия.
  11. тут нет потока. forceQueue не использует создание потоков, оно пишет напрямую в структуры синхронизации. Я у себя уже давно сделал хелпер с одним методом - Release. И его использую не получая сообщений от компилятора.
  12. С днем!!! Успехов и всего-всего !
  13. kami

    Перехват сообщений в Windows

    В обработке сообщения производить действия, которые способны генерировать кучу сообщений, которые приведут к обработке того же сообщения, в котором... , имхо, не есть хорошо. Вместо вот такого экранирования я бы попробовал использовать TThread.ForceQueue(procedure begin код, завязанный на IME end);
  14. kami

    Перехват сообщений в Windows

    Это FMX. Оконная процедура устанавливается на конкретный хендл окна. А FMX раз по 100 пересоздает хендл. В результате установка NewWindowProc в качестве WndProc уходит в небытие.
  15. kami

    Перехват сообщений в Windows

    Нужно перехватывать в рамках своего окна / приложения / системы вцелом ?