kami

Это зависит от того, какого эффекта надо добиться. Если queue вызываете из не-анонимного потока кодом вида Self.Queue(myProcedure) - то при уничтожении потока всё что он отдал в очередь на выполнение в главный поток, будет уничтожено. Без выполнения. Если вызывать как TThread.Queue(nil, myProcedure) - то не будет уничтожено. Но в этом случае, само собой, нельзя обращаться к полям и методам этого потока. Если требуется обращение только к полям - заведите локальные переменные и работайте с ними. Например, так: procedure TmyThread.Execute; var SomeValue, SomeAnotherValue: string; begin ..... SomeValue:=Self.FInternalValue; // Self пишу только для понимания, что Fxxx - это поле в экземпляре потока SomeAnotherValue:=Self.FInternalAnotherValue; TThread.Queue(nil, procedure begin ShowMessage(SomeValue + SomeAnotherValue); // эти переменные доживут до выполнения анонимки даже если потока уже не будет. end; );

Покажите, пожалуйста, правильную задачу, которую пытаетесь решить.

Тут нет кода, выполняемого в доп.потоке. Метод Synchronize делает следующее: "приостановить выполнение себя (т.е. доп.потока), переключиться в основной поток, выполнить там действие и после этого вернуться в себя (в доп.поток)". Ввиду того, что в коде доп.потока есть только synchronize - то единственное, что поток делает - ждёт, пока выполнится его действие в основном потоке. То есть - является абсолютно бессмысленным.

Поставьте бряк внутри метода _ReciveMessage и удивитесь - в каком потоке он вызывается. Ну или напишите if TThread.Current.ThreadID<>MainThreadID then // мог слегка ошибиться с наименованиями переменных - пишу по памяти, но вроде это они и есть. Алярма!!! (тут что-нибудь сигнализирующее что всё неправильно). Включая режим буквоедства: смените названия на ReceiveMessage и PackedNumber. Глаз цепляется

Опять пошли в какие-то обходные маневры... Решение для винды: uses FMX.Platform.Win, Winapi.Windows; procedure TForm5.FormCreate(Sender: TObject); // Form5 - это окно-"всплывашка". Не забываем выставить в инспекторе объектов stayOnTop, стиль border-а и т.п. var myHWND: THandle; ExStyle: NativeInt; begin myHWND:= WindowHandleToPlatform(Handle).Wnd; Winapi.Windows.SetParent(myHWND, 0); ExStyle := GetWindowLong(myHWND, GWL_EXSTYLE); SetWindowLong(myHWND, GWL_EXSTYLE, ExStyle or WS_EX_TOOLWINDOW or WS_EX_NOACTIVATE); Возможно, этот код будет актуальнее смотреться в OnShow, а не в onCreate.

У меня - нет. Емнип, Owner-ом для всех наброшенных на форму компонентов выступает сама форма. Вне зависимости от уровня вложенности визуальных компонентов. Для невизуальных объектов овнер нужен, если они покладены на форму в дизайн-тайме. Parent-а у невизуального объекта нет, а правило "не ты создал - не тебе удалять" выполняться должно. Это из того, что на поверхности. А какие реальные причины заставили иметь не только парента, но и овнера, да еще и для дизайн-тайм... Возможно, действительно без них никак. Давайте только без привлечения ARC "ничего удалять не надо, если и владелец и родитель удалятся, ссылки на объект закончатся и он самоуничтожится".

Понаехавших - нет, не учат. Раненых особенно. Тебе эпитеты тоже подобрать? По сути вопроса? Как ты говоришь "накидывание" возникло от того, что для решения не самого сложного вопроса здесь озвучены (в том числе -тобой) рекомендации и выводы, от которых потом сложно не удивляться - откуда столько говнокода в экосистеме Делфи? Да вот отсюда, из таких топиков на форумах, которые неокрепшие (да и окрепшие) умы впитывают и несут потом в массы. Удивительно, что еще не затронули "уникальное имя нужно, потому что по нему потом будем искать этот компонент"...

Upd. Нет, похоже в fmx механизм FreeNotification не используется для уничтожения. Но это не мешает всему хозяйству уничтожаться корректно, какие бы родители с владельцами ни указывались

Предположил на основании твоего вывода " не будет ошибки дублирования? по моему будет ", который проверяется и опровергается за 2 минуты. В результате вместо того, чтобы понять откуда ноги растут у ошибки дублирования имен - вы имеете костыли типа "по этой причине именовали := 'frame_'+i.toString; "

Уничтожение и в 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; Что я делаю не так?

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

Родитель-то как раз не nil. Владелец nil. Позвольте поинтересоваться, а какой профит помимо счастья обладания геморроем (который сам себе же и сделал) принесет создание компонента с указанием владельца? Единственный плюс, который мог бы быть - владелец при высвобождении себя уничтожает всё, чем он владеет. Но вот беда-то... родитель тоже это делает, причем - раньше. И благодаря подпискам на уведомления владелец узнаёт, что компонента, которым он владел, уже нет, т.е. попытки двойного уничтожения НЕ будет.

попробовать религия не позволяет? Только что написанный код: 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; всё отрабатывает без проблем, никаких вопросов по именованию рантайм-компонентов не возникает.

помнится, отвечал уже кому-то на форуме. Для динамически создаваемых компонентов просто не указывайте имя. Не нужно оно им. Тогда эта проблема отпадает сама собой.

И еще в тему ForceQueue. Как-то раз потребовалась мне конструкция типа "отложенное действие после отложенного действия". Дык вот, если сделать вот так: TThread.ForceQueue( procedure begin SomeAction; ForceQueue(SomeAnotherAction); end); то SomeAnotherAction выполнится сразу же вслед за SomeAction, а не на новом витке Application.Idle. Всё дело в том, что выполнятель Queued-действий просто достает их из списка, пока не закончатся. Т.е. выполняется первый ForceQueue, а вложенный, как таковой, не выполняется: второе действие помещается в список, тут же достается из него и сразу же выполняется! Как результат - при таком вызове де-факто получается срабатывает только первый ForceQueue, а вместо второго выполняется прямой вызов действия.

тут нет потока. forceQueue не использует создание потоков, оно пишет напрямую в структуры синхронизации. Я у себя уже давно сделал хелпер с одним методом - Release. И его использую не получая сообщений от компилятора.

С днем!!! Успехов и всего-всего !

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

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

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

А в чем загвоздка? Достать поле из JSON - вроде просто, обычная работа с JSON далеко не самой сложной структуры. Раскодировать из Base64 - uses System.NetEncoding; TNetEncoding.Base64.DecodeStringToBytes и сохранить их в файл Потом открыть файл через интент.

Друже! Ты прекратил мои мучения. Ибо всякие извращения с обращением Query.Fields('lalala').AsBytes и тому подобное приводили к AV на закрытии Query. При этом тип поля - TVarBytesField (почему-то именно так распознается VARBINARY в SQLite...).

У меня большая просьба: вместо кучи маленьких сообщений, которые вы пишете буквально одно за другим, составьте одно, в которое напишите всё то, что хотели сказать. Это не чат, где "кто в онлайне - прочитали, остальным пофиг". Это форум. И искать зерна истины в этой портянке из мимолетных мыслей как минимум неудобно.

А можно тогда запушить последнее изменение на гитхабе в Readme.md, чтобы всем было видно "ПРОЕКТ ПЕРЕЕХАЛ" ?

Не здесь надо писать. А на гитхабе заводить issue. Это будет правильнее и нагляднее: сам проект лежит на гитхабе, там же значительно проще работать с багами / неудобствами. Да и всем видеть как развивается проект - гораздо лучше. А здесь в толпе ваших сообщений я,к примеру, уже потерялся.