krapotkin

означать это может все что угодно windows использует минимум три разных исторических системы для работы с мультимедией Какой конкретно она воспользуется в этот раз - можно и разобраться с применением разных инструментов. Но вопрос один - вам шашечки или такси ехать? Все норм плееры тащат с собой целую тучу DLL для воспроизведения всех форматов. Если бы было все хорошо, этого бы не было в принципе. Поэтому моя рекомендация - как сделать, чтобы всегда работало. А если хотите узнать почему иногда (чаще всего) не работает - читайте MSDN и проводите эксперименты. (Делфи инструментов для этого не найдете)

Это зависит исключительно от набора установленных у Windows кодеков. Поэтому использовать этот компонент абсолютно рисковое мероприятие. Лучше взять что-то специальное типа PasLibVlc

серьезно, если это все вызывается в потоке, то всяко "нужно" обернуть, и мода тут ни при чем

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

любым способом вплоть до оборачивать каждое обращение к формам в отдельный Synchronize можно также воспользоваться асинхронным методом TThread.Queue для освежения интерфейса мне кажется он более полезным, потому что не блокируется выполнение потока, он не ждет синхронизации.

Задача любой синхронизации - не дать разным потокам одновременно изменять данные. Можете себе представить принтер, на который печатают несколько человек. Если не выстроить их в очередь, то результат вам не понравится. Ровно так же и с объектами программы. Если к ним есть доступ у нескольких потоков, то результат взаимодействия почти гарантированно приведет к ошибке программы. Synchronize ставит действие в очередь на ожидание главного потока. Как только тот освобождается, он выполняет это действие и оба потока идут дальше. Главный - своей дорогой, вызвавший Synchronize - своей. Достаточно просто запомнить - экран - один, вызов только через синхронизацию. Более полное объяснение заповедей многопоточного программирования несложно найти в сети)

синхронная концепция вызова и синхронизация потоков не имеют ничего общего то, что программа не пойдет дальше, пока не закончится POST, никак не отменяет того, что вызовы экранных компонентов должны происходить только в главном потоке поэтому TThread.Synchronize

нет не следует там написано, "если вы хотите получать данные прямо в процессе их получения, вместо того чтобы ждать когда скачается всё до конца..." ну собсно, да, можно из того же стрима их забирать в событии OnReceiveData, но зачем вам неполный json ?? это же не звук, не видео, которые можно сразу на экран выводить, не дожидаясь всего кино... но при этом это будет происходить независимо, опять же в другом потоке. ваш поток, где вы вызвали Post, будет ждать окончания загрузки. Асинхронно это будет только через BeginPost

Вся эта процедура в моем коде запущена в отдельном потоке через TTask.Run(). (кстати - асинхронно! т.е. сначала скорее всего выполнится до конца FormCreate а потом запустится run) Поэтому доступ к визуальным компонентам должен быть только через синхронизацию. Для этого вывод в memo обернут в TThread.Synchronize(); Далее. В этой форме POST второй параметр - стрим, данные из которого мы передаем на сервер, а третий - стрим, куда придет результат. Так как мы знаем, что туда и обратно будет ходить текст, то и выбираем TStringStream, как самый подходящий. Т.е. в stRes нас будет ждать результат. Такой же как и в R.ContentAsString Если вы хотите отслеживать (track) процесс получения данных, то можно повеситься на OnReceiveData там будет сообщаться сколько байт уже скачано, сколько всего планируется скачать. В этом обработчике можно сделать обновление progressBar, тоже через синхронизацию. Предполагается, что у вас там хотя бы сотни килобайт данных, иначе сомневаюсь, что этот обработчик хоть раз сработает. Ловить окончание с его помощью точно не нужно ) Все процессы обмена обычно делятся на синхронные и асинхронные. Синхронные - программа дальше не идет, пока не выполнится эта строчка. Асинхронные - команду отдали и пошли дальше. В этом случае обычно задается кусок кода, который выполнится по окончании процесса. THttpClient имеет оба вида вызовов. Обычные синхронные Get, Post и т.д. Асинхронные - BeginGet, BeginPost и т.д. http://docwiki.embarcadero.com/Libraries/Rio/en/System.Net.HttpClient.THTTPClient_Methods Обычно кроме самого вызова происходит еще много всяких вещей, которые я выношу в отдельный поток, поэтому всегда использую синхронные методы. Если вы будете это делать из главного потока, то можно использовать асинхронные. Вопрос удобства и архритектуры. Но говорить, что "что там, фигня, один маленький запросик" нельзя. Если сервер недоступен, не отвечает, плохая связь и т.д., ваша программа тупо зависнет сек на 30. Несколько раз так зависнет, а потом Андроид предлагает удалить ее с устройства, т.к. в ней баги и вообще она плохая. Пользователи не очень любят такое))

он не в фоне докачивается, а синхронно но он точно рабочий) а вот сам запрос сделан именно в фоне. собсно как и должно быть всегда

код приложен, запускайте и играйтесь до просветления

10.3.3.

httpDemo.7z вот демо работает одинаково на Windows и Android

ок

не работает же конкретный кусок его можно вынести в отдельный проект или просто кинуть кусок кода, там же один код, компоненты не требуются. нужен только URL и все собсно

приложите мин пример, или если приватные данные, в личку, могу запустить на Android

это зависит от того, кто программировал этот сервер) но вы же ему по сути передаете "отвечай как хочешь". и первый в списке html

кстати, требуется же ответ сервера JSON ? тогда FHTTPClient.Accept:='application/json'

https://www.php.net/manual/ru/function.getallheaders.php

упс, опечатался, AcceptCharset конечно но тут есть нюансы поэтому я спрашиваю именно что реально приходит на сервер а не что настроено при отправке иногда это не одно и то же. я тоже долго разбирался с этой проблемой и там много всяких нюансов бывает. В последний раз убил два дня, чтобы понять, что реальный сервер делает redirect а по стандарту Delphi делает POST редирект как GET. И это все портило. Пришлось подкрутить немного...

вот мой рабочий код, который я использую в нескольких проектах https://bitbucket.org/vkrapotkin/commonapi/src/master/ он конечно посложнее, но идея та же заголовки, StringStream на отправку и на прием данных Разбор полученного текста в json если это json

А покажите заголовки, которые приходят вместе с вашим запросом на сервер ? Судя по ошибке, сервер отвечает вам не в кодировке UTF8. За это отвечает AcceptCharset

да что это за таинственные структуры, что так сложны? какой размер полученного JSON ? если бы все было так печально, то форумы бы ломились от одинаковых тем, но ведь не видно такого хотя родные либы json мне не нравится, я пользуюсь XSuperObject, но они 100% рабочие проблема 100% в коде

нормально у меня работают и Get и Post и кодировка нормально принимается. вам нужно проверить, что же реально уходит на сервер для этого есть эхо сервера например https://docs.postman-echo.com либо направить на любой свой сервер, сделать неск строк скрипт на PHP который покажет все заголовки и контент, который он получил Совершенно непонятно, для чего тут TBytesStream, TStringStream работает абсолютно прозрачно (под капотом ессно то же самое) Ну и делать общение с сервером в главном потоке - странное занятие конечно

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