Maximus

Что значит ничего? Покажите ошибку. Доступ в сеть для программы ничего не блокирует, антивирус например?

Работает всё Другие сайты грузит, яндекс, гугл?

Вкратце вот здесь можно почитать http://proghouse.ru/programming/36-delphi-xe7-ppl Например, если таск организован как бесконечный цикл, то после завершения каждого таска, в главном потоке увеличивать счётчик. Как только он станет равным количеству запущенных, можно будет обновлять информацию на экране и делать повторный запуск. Разумеется доступ к главному потоку должен быть синхронизирован. А если в таске конечная последовательность действий, то можно просто проверять статусы всех тасков. Логично. WaitForAll приостанавливает поток в котором был вызван до тех пор, пока не будут завершены все таски.

Во-первых ни в коем случае нельзя обращаться к визуальным компонентам напрямую без синхронизации, да и вообще к любым разделяемым ресурсам. Во-вторых deadlock в FMX ничем не отличается от deadlock на VCL или на WinAPI, почитать можно здесь http://forum.vingrad.ru/topic-60076.html Конкретно в приведённом примере достаточно обернуть изменение метки в Synchronize TThread.Synchronize(nil, procedure begin Form4.Label1.Text:=i.ToString; end); и после запуска потока вызывать MyThread.WaitFor; - получите deadlock.

На FMX этот компонент не завезли, студия же на VCL написана. В FMX можно попробовать заменить на TMenuBar.

Меню RAD Studio сделано на TActionMainMenuBar.

А что это вообще за метод TThread.ForceQueue? Где вы его взяли, его же нет в TThread.

Баг исправлен в Tokyo.

Вы же знаете длину и ширину своего "потомка", учитывайте её при проверке и всё.

Кажется баг исправлен в Tokyo.

Там теперь отображается не дата последнего поста, а дата создания темы. Зачем так сделали - непонятно.

Лучше сразу забыть про FMX в библиотеке dll. Корректно он не будет там работать.

Теперь в последних сообщениях вместо даты и времени последнего поста отображается дата создания поста, вообще не здорово.

Ну да, конкретно с калькулятором такой финт не прокатит, он явно запоминает свою позицию перед закрытием, а затем при запуске её восстановление происходит уже после применения заданных в CreateProcess параметров позиции. А вообще работает, например, если запустить своё же приложение, разумеется если в нём нет установки координат после запуска. Можно и MoveWindow или SetWindowPos использовать после запуска, только тогда придётся получить хендл окна.

CreateProcess предпоследний параметр lpStartupInfo, структура STARTUPINFO, в ней поля dwX и dwY. Ну и судя по описанию, для флага dwFlags нужно задать значение STARTF_USEPOSITION.

Правда после прерывания загрузки WinHttpReceiveResponse возвращает False и GetLastError возвращает код тайм аута, после чего выбрасывается соответствующее исключение, но возможно так оно и должно быть, сервер же не получил полный набор обещанных в WinHttpSendRequest байт.

Да, работает. Мне легче было просто файл поправленный к проекту подложить. Кстати, исходник со второго апдейта берлина, а то мало ли.

В общем, я бы исправил так: добавил локальную переменную Abort: Boolean; в TWinHTTPClient.DoExecuteRequest, до цикла передачи данных вызвал бы коллбек с объёмом файла, так же как происходит при загрузке файла на ПК - первый коллбек вызывается с нулевым объёмом переданных данных. LRequest.DoReceiveDataProgress(0, DataLength, 0, Abort); В цикл добавил бы проверку на прекращение загрузки while (LRequest.FSourceStream.Position < LRequest.FSourceStream.Size) and (not Abort) do В конце цикла вызывал бы коллбек с объёмом файла и количеством переданных байт. Первый параметр коллбека - StatusCode получить на данном этапе скорее всего нельзя, или я не понял как, поэтому передаю ноль. LRequest.DoReceiveDataProgress(0, DataLength, LRequest.FSourceStream.Position, Abort); Полный текст исправленной функции.

Да вот смотрю на то что они понаписали и думаю, то ли они вообще не предусмотрели вызов этого коллбека при отдаче файла, то ли забыли... Вот эта функция вызывается вне зависимости от того куда мы загружаем файл: к себе или на сервер. Разница начинается на этой сроке LExecResult := DoExecuteRequest(LRequest, LResponse, AContentStream); При загрузке на ПК эта функция не входит в блок кода, помеченный // Send data. TWinHTTPClient.DoExecuteRequest выполняется полностью и продолжается выполнение процедуры THTTPClient.ExecuteHTTPInternal, в которой выполнение доходит до строки if not SameText(LRequest.FMethodString, sHTTPMethodHead) then LResponse.DoReadData(LResponse.FStream); откуда вызывается функция где и начинается загрузка файла на ПК. Отсюда уже и происходит вызов нашего коллбека в цикле, пока файл не загрузится. FRequestLink.DoReceiveDataProgress(LStatusCode, LExpected, LReaded, Abort); С передачей на сервер всё обстоит не так. После того как мы попали в функции TWinHTTPClient.DoExecuteRequest в блок кода, помеченный // Send data, мы там и остаёмся в цикле, пока файл не будет загружен, там разумеется нет никакого вызова коллбека, и только после того как файл будет загружен и мы выйдем из TWinHTTPClient.DoExecuteRequest, то так же попадаем в TWinHTTPResponse.DoReadData и там вызывается FRequestLink.DoReceiveDataProgress(LStatusCode, LExpected, LReaded, Abort); который перед циклом и который вызывается в итоге после окончания загрузки файла на сервер. Дальше мы входим в цикл, но он досрочно завершается вместе с процедурой на строке if LSize = 0 then Break; Самое забавное, что в цикле при передаче на сервер, даже флага Abort нет, значит прервать никак передачу нельзя, ну разве что объект уничтожать прямо во время работы.

Доброго времени суток всем. Хочу замерять скорость загрузки файла на сервер, но OnReceiveData отказывается вызываться. Код простенький var Stream: TFileStream; begin Stream := TFileStream.Create('Файл', fmOpenRead); NetHttpClient.Put('Ссылка', Stream); end; При скачивании файла с сервера на компьютер через Get, коллбек OnReceiveData работает корректно, а вот с Put почему-то нет. Он вызывается только раз, перед окончанием загрузки и вызовом OnRequestCompleted. Он вообще должен вызываться или это нормальное поведение? По идее, если верить документации - должен: http://docwiki.embarcadero.com/Libraries/Berlin/en/System.Net.HttpClientComponent.TNetHTTPClient.Put Кто-нибудь пробовал у себя, работает этот коллбек при передачи файла, а то может быть я что-то не так делаю?

if ord(KeyChar) = vkSpace then

Здорово, спасибо большое, а то надоело мучаться с отображением хинтов через создание CalloutPanel.

Интересный способ, для PaintBox это удобнее чем попиксельно рисовать.

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