Yarpda

Вот решение из StackOverflow: Сам не пробовал, но судя по тексту должно помочь.

Этот досадный глюк наблюдался в версиях XE5-XE6, в версии XE7 он помоему исправлен (правда сам не проверял). В любом случае где-то в инете встречал обход этой проблемы, но ссылки к сожалению дать не могу. Кстати она встречается начиная с версии minAPI 13, на 12 все нормально. Попробуйте, может в 12 версии не будет кнопки меню.

Спасибо, то что нужно!

С удивлением обнаружил, что на http://blogs.embarcadero.com публикуются весьма интересные статьи про FМ, да еще и на русском(!), например эта и эта. Однако, еще больше удивило то, что их нет на этом сайте, при то что автор их всем участникам форума хорошо известен )) Может быть ввести отдельную ветку, где бы дублировались материалы от туда? А если еще и с приложениями и возможностью обсуждать излагаемые там темы, то было бы совсем хорошо, мне кажется...

Спасибо, по второй ссылке думаю то что нужно.

Невероятно, но так действительно сработало! Правда не совсем так как предполагалось, но теперь ексепшн появляется гораздо быстрее чем установленный таймаут, но это как раз то, что нужно. Спасибо большое еще раз, сам бы не точно не догадался. ))

Хм... Я использовал просто Exception, не уверен что есть отличия, но Спасибо, попробую. Отпишусь.

Да, конечно.

Я так и делаю, но проблема в том что TIdHTTP (на андроиде, да и так походу тоже) не адекватно реагирует на ReadTimeOut, от этого порой процедура занимает под 40 секунд, при любых таймингах. Я даже тему поднял по этому поводу. Я почему-то думаю, что это можно сделать при помощи API или более красивым методом чем через Indy

UP. Использую IdHHTP, ставлю любые значения connectTimeOut, и ReadTimeout, но в итоге до появления ислкючения проходит совершенно хаотично время, то 10 секунд, то 22, а то 48, а то раз и 1 секунда, все это на один и то-тот же запрос. Как такое расценивать я даже не знаю. Такое ощущение что Indy эти таймеры глубоко побоку. Но чем то же это должно объясняться. Может кто вышел из положения, подскажите пожалуйста. Проверяю так. Отключая на роутере инет, мобильный подключен по WiFi, достучаться до сайта естественно не может, но откуда разные таймауты берутся вообще не понятно... Delphi XE7.1.

Подскажите, можно ли как-нибудь красиво (а лучше с помощью API) отловить в приложении есть ли доступ в интернет? Должно же быть что-то... Заранее спасибо.

Unsigned в данном случае означает, что пакет не подписан. Т.е. без подписи KeyStore.

Да, именно о обильных, под Win все ОК.

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

Заметил, что при использования программного скрытия клавиатуры методом: uses FMX.Platform, FMX.VirtualKeyboard; procedure TForm5.ButtonHideKeybordClick(Sender: TObject); var KeyboardService: IFMXVirtualKeyboardService; begin // Запрашиваем сервис виртуальной клавиатуры if TPlatformServices.Current.SupportsPlatformService(IFMXVirtualKeyboardService, IInterface(KeyboardService)) then KeyboardService.HideVirtualKeyboard; end; Наблюдаются устойчивые вылеты на разных устройствах. В пределах одноq формы все нормально, однако если скрыть клавиатуру таким способом и перейти на другую форму (особенно созданную динамически), и выделить какой либо контрол, вызывающий появление клавиатуры, начитаются вылеты программы по AV. Если не с первого раза, то со второй попытки результат близок к 100%. Мне кажется, что использование данного метода как-то перенастраивает стандартное поведение VK в приделах всего приложения. Если убирать клавиатуру обычным методом при помощи клавиши Назад, то такой эффект не наблюдается. Ярослав, подскажите, есть ли еще какой-нибудь способ убора и показа виртуальной клавиатуры под Андроид, отличный от приведенного? Либо может есть какие-то методы по обходу данного эффекта. Если необходимо приложу проект, где данное поведение VK наблюдается. Заранее спасибо.

Судя по описанию ScalledLayout это совсем другое... Он наоборот, влияет на размеры находящихся в нем компонентов. А мне нужно, чтоб компоненты, находящиеся в нем, влияли на размеры Layout"a

RubberLayout (резиновый layout) - это я сам придумал )). В общем это Layout который будет самостоятельно расширяться или сужаться если находящиеся в нем элементы увеличиваются или уменьшаются (добавляются, удаляются). Например накидываем в этот лэй несколько компонентов с разным выравниванием, а он подсчитывает общие габариты находящихся в нем компонентов по изменяется соответственно. В том числе и добавляемых в него динамически! Мне вот очень не хватает такого лея. Может я конечно еще не много понимаю в FM, но мне бы такая штука очень помогла бы в размещении компонентов под разные экраны (андроид). Изменяется размер шрифта, высота TText и т.д. А если бы еще и RubberListItem по аналогии сделать то, вообще бы цены не было.

Это понятно, просто такую штуку можно и на IOS и Win сделать, в общем то бывает полезной в некоторых случаях.

Toast сообщения под андроид (возможно и не только для него). Я был весьма удивлен, что их нет по умолчанию в FM.

FGX, посмотрите компонент TfgVirtualKeyboard и пример к нему. ©

Спасибо. Попробую

(почему-то нет ветки в андроид по производительности, поэтому написал сюда) Пробую писать под FM на Андрод и столкнулся с жуткими тормозами при прокрутке в TListBox. Динамически создаю TListBoxitem'ы и закидываю в каждый итем 4 Tlabel'я разных цветов методом MyListBoxItem.AddObject(MyLabel); И так для каждого Итема. Если список из 5-10 итемов прокручивается еще куда ни шло. Но список из 25 итемов и более просто дико тормозит при прокрутке. Подскажите, может быть я что-то не так делаю. Какие параметры или настройки могут влиять на производительность листбокса в частности, и на производительность FM для Андроид в общем? Заранее спасибо.

Тем что я просто не знал этого метода. )) Спасибо. Но по моему они в сущности ведут себя одинаково, но их сочетание в OnClose дало наилучший результат в расходе памяти (может стат погрешность конечно).

Так close в Андроид вызывается в XE7 при потере активности окна. Поэтому и Action:=TCloseAction.caFree и привлекательна, что вроде как не надо следить за уничтожением окна. А если вызвать Close принудительно из кода другой формы, так это совсем другая история...

)) Ну это понятно. Интересует когда вызвать вот это: Myform.DisposeOf; myForm := nil;