Wovan2
-
Постов
45 -
Зарегистрирован
-
Посещение
Весь контент Wovan2
-
Разумеется и новый ответ. А первое соединение должно закрыться по ошибке. Видимо.
-
На сервере проблем в этом нет. Событие procedure IdTCPServerExecute(AContext: TIdContext) в параметре принимает контекст соединения. Там вся информация о соединении инициировавшем это событие.
-
To:Евгений Корепов Спасибо. Обязательно посмотрю.
-
Ну это вопрос к Indy. Моего кода в приложении очень мало. Indy утверждает, что для каждого подключения создается отдельный поток, который обрабатывает это соединение, что впрочем, логично Знаете. Сейчас посмотрел. Сервер запущен на Win10. Без подключений 8.2 Мб. Один клиент 8.3 Мб. Два клиента - тоже 8.3 Мб.
-
Для меня потоки не новость. Работать с ними приходилось. Но в данном случае это как-то усложняет все дело. Еще потерять кучу времени, чтобы понять как работают новые компоненты? На данный момент я убрал или сделал проверки на существование внутренних объектов IdTCPClient и IdTCPServer, где они проскакивали в коде - вываливания и на сервере и на клиенте прекратились. Подключение проверяю при каждом обращении к серверу, при отсутствии происходит переподключение.
-
Да. Похоже на это. Ну нафиг эти красивости
-
Перед долгим кодом делал r1.Visible:= true; //TRectangle r1.BringToFront; ai1.Enabled := true; В конце ai1.Enabled := false; r1.Visible:= false; В результате вообще ничего не видно. Ну почему все так не очевидно и не понятно. Неужели какой-нибудь стандартной анимашки нет??? Пробовал и через BitmapListAnimation1.Enabled := true; Результат примерно такой же отображается первый кадр и все. Может через поток надо как-то это делать??? Блин по полдня надо тратить на тривиальные вещи
-
Не знаю глюк это или что, но в приложении я этот объект даже не могу в run-time увидеть Еще здесь на форуме упоминается какой-то ProgressDialog, но я у себя не могу его найти.
-
И еще подскажите, кто знает, аналог виндовских часиков ожидания на Androidе как реализовать. Видел какие-то вращающиеся кружки, или что-то подобное.
-
To Rusland Тут, видимо, на месте уголков надо явно задать адрес сервера... Я, по крайней мере, так и сделал.
- 44 ответа
-
- 1
-
-
- connect
- idtcpserver
- (и ещё 1 )
-
Просветите, пожалуйста, насчет IOHandler. Я явно его не задаю, однако код IdTCPClient.IOHandler.Write(s, s.Size, True); отрабатывает без ошибок и корректно. Нужно его задавать явно? И еще на сервере ошибка происходит при закрытии формы на коде if Assigned(IdTCPServer) then IdTCPServer.Active := False; а именно на IdTCPServer.Active := False, поскольку сам объект существует. (ошибка обращения к памяти, посмотрел по отладчику пару раз проходит по exception и в конце концов AV). Если убрать вообще остановку сервера, то при закрытии ошибок нет. Интересно как в этом случае насчет утечки памяти?
-
Не знаю как в D10 в D7 это просто вызов процедуры с пустым параметром. Формально туда можно было засунуть Sender от вызывающей процедуры, если бы этот параметр как-то обрабатывался в TimerTimer. А раз он никак не обрабатывается, то можно втиснуть пустышку.
-
Вариант обхода с помощью стартового таймера, в общих чертах понял. Я, собственно, и читаю этот файл один раз. Второй раз, что встречается в коде, это изменение настроек в этом файле. Возможно используется 1 раз за все время жизни программы. И это есть в коде. Хотя и не совсем красиво. В Window я обычно так не делаю. Этот пункт самый непонятный. Не понимаю как получать ответ с сервера в асинхронном режиме. Ведь так или иначе запрос и ответ надо как-то синхронизировать? И не понятно причем здесь отказ от GetFromServer, это всего навсего процедура реализующая запрос - ответ в одном месте (асинхронность, наверное, можно организовать и в ее рамках?). В итоге, на мой взгляд, получилась ситуация как в Tethering, запрос в одной процедуре, ответ в другой, и не понятно какой ответ от какого запроса(если запросов было несколько). Как это можно соединить? На клиенте потоки используются исключительно для уменьшения подвисаний интерфейса программы? Ведь соединение с сервером принципиально одно. Спасибо за проявленную заинтересованность
-
Согласен. Здесь поторопился. Если нет соединения, то и свойства все эти - швах. Надо просто свойства клиента Host и Port. Спасибо. Но основная проблема, я так подозреваю, не в этом.
-
Привычка, выработанная годами Маленький монитор как бы способствует В Delphi 10 плохо разбираюсь в файлах проекта. Запаковал всю папку проекта. Но кода, конечно, стало больше. Спасибо за проявленное внимание. Socket.7z
-
На самом деле таймер я подготовил, но не использую (не активирую) его. Просто один раз вызываю в начале его функцию TimerTimer. Добавил файлы. Код довольно короткий. Частности по работе с данными убрал. Все что касается работы клиента и сервера осталось. Напомню Сервер приложение Win32 VCL. Клиент приложение для Abdroid FMX. Пакеты данных размером от нескольких десятков байт до 5 килобайт максимум и редко. Это процедура срабатывания таймера? Desktop.7z
-
Так выхода нет? Нужно с головой погрузиться в изучение реализации Indy?
-
В том то и дело, что до настоящего времени я это делал неосознанно. Понятно, что каждая сторона канала должна работать на понятной ей кодировке. Сейчас, с Вашей помощью, я достиг некоторого понимания вопроса, и проблема рассосалась. Спасибо. Тот код, что выложил я тоже вполне себе работоспособен. Ну, собственно, что-то подобное я и сделал. Автоопределение, согласен, крайне ненадежная штука.
-
Наверное должны дружить, раз написаны компоненты. На Windows что проверять там связь стабильная. На Android из-за непостоянности связи происходят всякие непонятные зависоны,то на сервере, то на клиенте. Тонкостей Indy не знаю, к сожалению. Наверняка есть какой-то алгоритм, ну там последовательность вызовов всяких там индийских событий и функций для обеспечения стабильности работы в нестабильной сети. Разбираться в нюансах ну очень долго и не продуктивно для разового применения в простеньком приложении. Подозреваю, что обеспечение стабильности связи займет больше кода, чем само приложение...
-
А разве в Indy не реализована многопоточность в самих компонентах? Я так понял из описания компонентов. И Android как-то не понятно отрабатывает блоки try. Наверное у кого-то уже есть наработки по управлению соединениями в Indy? Ну там, как проверить соединение, как отработать разрыв связи и т.п. Пока получается стабильная работа так: соединение создается перед командой и закрывается сразу после ответа.
-
Доброе время суток. Борюсь с Indy 10 на FMX. Обмен данными между сервером и клиентом наладил. Все работает стабильно. Стал экспериментировать с разрывом связи. И тут программы ведут себя не очень понятно, особенно на клиенте. Если сервер не запушен. Клиент на команде IdTCPClient.Connect; закрывается. ???? Делаю обработки так procedure TfrmMainClient.TimerTimer(Sender: TObject); var Server : string; begin if not IdTCPClient.Connected then try IdTCPClient.Connect; except on E : Exception do lblInfo.Text := e.Message; end; Server := 'Сервер ' + IdTCPClient.Socket.Binding.PeerIP + ':' + IntToStr(IdTCPClient.Socket.Binding.PeerPort); if IdTCPClient.Connected then begin lblInfo.Text := Server + ' подключен!'; lblInfo.TextSettings.FontColor := TAlphaColors.Green; end else begin lblInfo.Text := Server + ' не доступен!'; lblInfo.TextSettings.FontColor := TAlphaColors.Red; end; end; Никаких сообщений не появляется. Программа подвисает вместе с Адроидом, потом тупо окно закрывается. Молча. Таймауты на клиенте выставил ConnectTimeOut = 5000; ReadTimeOut = 5000; В общем вопрос. Как правильно организовать на Indy управление соединением? Чтобы не тормозило, Была возможность переподключиться. PS. Почему-то в Delphi 10.2 не могу найти компонент AntiFreeze. ????
-
Как какая? Android по умолчанию искренне считает, что там UTF8. И в сеть выбрасывает UTF8. Сделал, на мой взгляд, довольно компактно. Клиент function TfrmMainClient.GetFromServer(Command : string) : string; var s : TStringStream; begin s := TStringStream.Create('', TEncoding.UTF8); try //запрос на сервер s.WriteString(Command); s.Position := 0; IdTCPClient.IOHandler.Write(s, s.Size, True); s.Clear; //читаем ответ сервера IdTCPClient.IOHandler.ReadStream(s); s.Position := 0; Result := s.ReadString(s.Size); finally if Assigned(s) then s.Free; end; end; Сервер procedure TfrmMainServer.IdTCPServerExecute(AContext: TIdContext); var s : TStringStream; Command, Param1, Param2 : string; Response : string; procedure ResponseClient(Response : string); begin s.WriteString(Response); s.Position := 0; AContext.Connection.IOHandler.Write(s, s.Size, True); end; begin s := TStringStream.Create('', TEncoding.UTF8); mem.Lines.Add(AContext.Connection.Socket.Binding.PeerIP); AContext.Connection.IOHandler.ReadStream(s); s.Position := 0; Command := s.ReadString(s.Size); mem.Lines.Add(Command); //Utf8ToAnsi SeparateNameValue(Command, ':', Command, Param1); s.Clear; //реакция на разные команды клиента case AnsiIndexStr(Command, ['GETISPOOLEXISTS', 'UPDATEISSET', 'GETCELLS']) of 0:begin //тут код получения строки Response ResponseClient(Response); end; 1:begin //тут код получения строки Response ResponseClient(Response); end; 2:begin //тут код получения строки Response ResponseClient(Response); end; end; s.Free; end; С кодировкой проблем нет. Спасибо всем, кто откликнулся и помог. Объекты перегоняю через JSON. Спасибо. Вот не знал.
-
Спасибо. Все это конечно хорошо, но уж больно далеко и не интуитивно.
-
Здравствуйте. Хотелось бы поделиться своим пониманием проблемы кодирования строк. Может я что-то не понимаю. Чтобы как-то прояснить для себя. Тип string в delphi и кодировка символов, это две разные вещи. String (в Delphi 10 по сути это UnicodeString) - это указание компилятору сколько памяти выделить под переменную, заданного типа. Для Delphi 10 это 2 байта на символ. А что конкретно в этих байтах - это уже кодировка. Латиница практически во всех кодовых таблицах имеет они и те же коды (в unicode первый байт заполнен нулями). Поэтому с ней и проблем, практически не бывает. Кириллица же в разных кодовых таблицах имеет разные коды. Из-за этого и все проблемы. Это все понятно. Мне не понятно, например, в какой кодировке хранится текст в таком коде: var s : string: s := 'Привет'; Это зависит, видимо от ОС, в которой запущено приложение. На Android, по видимому, это UTF8. На Windows - ANSI(первый байт 0). Но это по наитию. Как все же правильно работать с кодировками, чтобы всегда знать, в какой кодировке находятся строки в которыми ты работаешь в данный конкретный момент, на данном конкретном компе? Если это понять, то скорее всего и проблемы с "крякозяблами" должны пропасть сами собой. Вы согласны? Поделитесь пожалуйста своими соображениями, кто в курсе. Спасибо.
-
Спасибо. Действительно, если при создании потока указать s := TStringStream.Create('', TEncoding.UTF8), то все пляски с перекодировками оказываются не нужными. В общем первоначальный код работает с указанной поправкой корректно.