kami

Prof не бесполезна для работы под Windows. Если нужны мобильные платформы - придется брать Addon.

Вам нужны координаты клавиатуры (пересчитанные из Screen в Client) и AbsoluteRect поля ввода. if vkbdRect.IntersectsWith(EditAbsoluteRect) then // пересекаются. Однако, следует обратить внимание на оба issue в комментариях - сообщенный приложению размер клавиатуры не всегда соответствует действительности.

vkbdHelper имеет весьма интересный алгоритм - если он находит scrollbox и понимает, что тот в состоянии поднять поле ввода так, чтобы оно было над клавиатурой, то собственный Layout не создается, а прокручивается имеющийся ScrollBox. Но там какой-то алгоритм работы со scrollbox-ом, который отличается от штатной демки. Не проверял этот момент и не менял его, попробую посмотреть, когда разгребусь с текущими вопросами.

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

Поклонники синапса, извините. Roma77751 - у вас ничего не получится с синапсом. Если честно, я не понимаю, как он работает с любой Delphi версии больше 2007. Возможно, в полной библиотеке все нормально и это недостатки "портированной" для мобильных платформ. Вкратце - полный швах в модуле synabyte, класс (вернее record) TSynaBytes. Несмотря на явно используемую директиву {$IFDEF UNICODE}, считается что 1 символ = 1 байт. Отсюда все проблемы Roma77751, уходите с этой библиотеки. Не будет она работать на мобильных платформах.

Дайте ссылку на исходники синапса под андроид. Попробую покопаться в них.

Если русские символы - закорючки, значит, не UTF8: - либо у вас при загрузке в StringList и Memo, - либо у сервера. Написать в ответе Content-Type:"text/html; charset=utf-8", а содержимое отдать в UTF16 ума много не надо. Повторю - в StringStream ошибки нет, потому что в приведенном коде не используется работа со строками. Попробуйте получить p.DataString - ошибка возникнет? По поводу замечания "в memo в винде проблем нет" - винда использует UTF16. И Delphi под винду тоже использует UTF16. Возможно, дело в этом. Update: вполне возможно, проблема прячется внутри портированного на мобильную платформу синапса. Предположительно, после получения ответа от сервера может вызываться перекодировка UTF8 ->UTF16 и уже бинарное содержимое UTF16 запихиваться в выходной поток. Ну, это из разряда фантазий уже, не работал я с синапсами.

Потому что в приведенном коде StringStream не задействует работу со строками, а работает как TByteStream, наследником коего он, собственно, и является. А StringList пытается преобразовать набор байт в символы используя TEncoding, что и приводит к ошибке. Вердикт один - несовпадение кодировки. Видимо, сервер отдает не UTF8, принятый по умолчанию на Android.

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

Да, потокобезопасный "классовый" метод. Однако, в связи с соседней темой есть важные дополнения: 1. этот метод не записывает преамбулу. 2. Для записи используется кодировка UTF8 3. Метод создает файл с эксклюзивным доступом к нему. Пока метод работает, попытка достучаться до файла (например из другого потока) провалится с выбросом исключения. Кроме того - нежелательно пользоваться методом TFile.AppendAllText без явного указания кодировки (буквально недавно здесь и здесь была куча споров. Жалко, половину комментариев потерли...)

if not TEncoding.IsStandardEncoding(Encoding) then Encoding := TEncoding.GetEncoding(Encoding.CodePage); Абсолютно излишняя попытка действий. Более того, если бы код отработал, то вы получили бы утечку из-за утери первого Encoding. Чем сейчас и занимаюсь - портирую код для опознования кодировки с с# Имхо - работы много, а пользы будет мало. Файл не обязан содержать преамбулу. Совсем. Даже для well-known кодировок типа UTF8 преамбула является необязательной.

Так и делайте. ParseItem(i). Емнип, значение будет размещено в стеке, так что последующие изменения переменной на уже созданный таск не повлияют.

В общем случае - никак. Если файл не содержит преамбулу (1-3 байта) - идентификатор кодировки, то предстоит только догадываться. Если содержит - посмотрите исходники TStringList или TFile.AppendAllText. Вкратце - для автоматического "угадывания" используемой кодировки задействуется TEncoding.GetBufferEncoding

А зачем получать битмапы, чтобы их пихать в ListView? ImageIndex уже отменили?

Пардон, где? DisposeOf на ARC - плохая штука.

Не используйте в ARC для визуальных компонентов DisposeOf. Пользуйтесь Release. DisposeOf принудительно высвобождает все ресурсы, хотя сам объект благодаря ARC еще жив. Это может привести к попыткам доступа к высвобожденной памяти -> различные ошибки.

Update. Исправили недостаток на Android 5. Большое спасибо Rusland за тестирование. Итоговый файл прикладываю. По прежнему не рекомендую использовать этот модуль, если создаваемые в runtime контролы ложатся напрямую на форму. Перед написанием претензий, пожалуйста прочитайте known issues в комментарии в начале файла. vkbdhelper.zip

Rusland - изменил свое предыдущее сообщение.

Ну вот, собственно, что получилось. Решение, к сожалению, мне не нравится, поскольку основывается исключительно на том, что этот "левый" Rectangle лежит прямо на форме и имеет Align = Contents. В остальном - работает. Еще раз заострю внимание на своем предыдущем сообщении - если вы создаете контролы в runtime и выставляете родителем для них саму форму, то пользоваться этим модулем для вас противопоказано. Upd: заменил вложение. Прошу обратить внимание на комментарии в файле, касаемые known issues. vkbdhelper.zip

Крайне интересно. Основной принцип этого модуля - если нет скроллбокса, то положить всё, лежащее на форме, на созданный в Runtime TLayout и уже его двигать. Дык вот, если берем за основу форму из описания Rusland, то кроме Layout-а с какого-то перепугу на форме оказывается TRectangle. Вот из-за его перемещения на Layout изображение и пропадает. К сожалению, проблема конечно решаема, но только с некоторыми допусками. Совершенно непонятно, как отличить TRectangle, который служит фоновым изображением от TRectangle "своего", который может уже лежать на форме. Может, Ярослав чем поможет? Вечером постараюсь выложить решение. Вот сейчас пишу это и думаю, что у этого модуля есть один существенный недостаток - девелопер не знает, что после первого показа клавиатуры все его контролы уже лежат на TLayout. Если контролы меняются в runtime, то последовательное показ клавиатуры ->перенос всего на Layout->добавление нового контрола на форму->показ клавиатуры->перенос всего на Layout приведет к такой гребенке из вложенности TLayout-ов, что...

К сожалению, этот класс предназначен для "эффектной" работы с фреймами, на WB он влияния не оказывает. Более того, использовать его с фреймом, на котором лежит нативный контрол типа WB будет некрасиво, поскольку нативные контролы не будут поддерживать всякие "плавности" в появлении/исчезновении. С удивлением узнал, что TabControl содержит специальный код, анализирующий "а не находится ли на скрываемом/показываемом табе WB", а TFrameStand, afaik - нет. Даже с учетом "специального кода" анимация TabControl-а c WB оставляет желать лучшего (это не в упрек, не думаю, что можно качественно организовать работу с нативным контролом в полностью графической обертке), так что TFrameStand в этом плане отдыхает. Пытался решить вопрос на форуме TMS (в их FMX Pack есть веб-браузер, который позиционируется как замена "штатному"), но получил отлуп. Не дословно - "мы отошли от использования Chromium, наша браузерная обертка основывается на коде FMX, посему раз ошибка возникает и в стандартном TWebBrowser, в его реализации под Win - идите лесом, а у нас все классно".

Все придумано до нас http://stackoverflow.com/questions/35105713/delphi-set-the-texpander-height/35109511#35109511 берем protected - поле FIsExpanded и анализируем его в методе DoExpandedChanged. Хотите - добавьте свое событие, хотите - пользуйтесь так.

Многое железо гарантированно есть в компьютере. И так же гарантированно оно может из принципа не отдавать о себе информацию.

Подготовщик пишет в реестр случайную последовательность. Каждый раз - случайную (если он не видит записанное ранее значение). Эту же случайную последовательность в закодированном виде пользователь передает вам. Вы вносите в код программы полученное от пользователя значение. Программа проверяет совпадение того, что в реестре с тем, что зашито в коде. Если подготовщик запустить на другом компьютере - в реестре будет другая последовательность, отличающаяся от зашитой в программе. Какая же это не-защита?

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