kami

Похоже, ответ появился: https://en.delphipraxis.net/topic/2949-zxing-delphi-for-104/?do=findComment&comment=23777

Т.е. прочитать, что они делают - это излишне? Бессмысленные действия, результат выполнения которых уже известен изначально. И всё остальное - тоже проигнорировано... Удачи.

Form1.Edit1.Text:=Form1.Edit1.Text+ch; Вам еще в прошлом топике сказали - не нужно так делать. Обработчик хука должен максимально быстро вернуть управление. Любая обработка должна проводиться постфактум, асинхронно. Здесь вы без тени сомнения работаете с визуальными компонентами, вызов которых может и должен производиться только из главного потока вашего процесса. Откуда такая уверенность, что коллбак хука будет вызван именно в этом потоке? В вашем коде первые две строки бессмысленны, почитайте их описание в https://docs.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-mapvirtualkeyw , чтобы понять - почему. Читаем ремарки (часто ремарки - это самое главное ) для GetKeyboardState: https://docs.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-getkeyboardstate и выясняем, что она привязана к вызывающему потоку. А LL - хуки вызываются как минимум в контексте установившего их процесса, скорее всего (лень читать доку) - в контексте установившего хук потока. Потому и не отрабатывает, что GetKeyboardState для получения нужного эффекта должен вызываться в контексте чужого потока в чужом процессе. Чтобы отвязаться - следует использовать (как следует из тех же ремарков по ссылке выше) GetAsyncKeyState.

Исчерпывающее описание проблемы. Вам сама операционная система говорит - нельзя так делать, вы тормозите ВСЁ что только можно, в результате ваш хук признается вредоносным и исключается из цепочки. Но вы упорный... Ждите ответа. Но в своем коде, а не в хуке. А в свой код передавайте данные асинхронно, через тот же postMessage

PeekMessage - бессмысленно и даже вредно с флагом PM_REMOVE. Убрать. SendMessage - эта функция отправляет данные окну и дожидается, пока окно их обработает. А хук ждать не должен, его задача - максимально быстро отработать. Заменить на PostMessage. длл здесь не нужна. LL-хуки работают из любого места. Просто перенести весь код в exe.

Не надо TCPServerов на клиентах. Ничего хорошего из этого не выйдет, как минимум потому что белые IP есть у 1% пользователей сотовой связи, к остальным будет не подключиться извне. TCP соединение позволяет обеспечить двусторонний обмен. Любой из корреспондентов (и клиент и сервер) в любой момент времени вправе отправить в соединение данные. На стороне TCP сервера для этого нужно отправить данные в конкретное соединение с конкретным клиентом, а на клиентской - и выбирать ничего не надо, у TCP-клиента только одно соединение.

WebSockets обеспечивает обратную связь "сервер-клиент", в отличие от обычного http, где идет клиент-сервер. Увы, насколько я знаю - это доступно только на Indy (буду очень рад, если ошибаюсь), а (далее всё очень субъективно) с индейцами у меня как-то не сложилось...

Это зависит от того, какого эффекта надо добиться. Если 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 не используется для уничтожения. Но это не мешает всему хозяйству уничтожаться корректно, какие бы родители с владельцами ни указывались