Лидеры

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

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

Если вы часто работаете с данными, анализируете их - то советую обратить на бесплатную библиотеку классов и компонентов от Steema. Библиотека активно развивается и улучшается. Поддержка всех платформ(VCL+LCL+FMX) Описание функционала найдете на официальных источниках. GitHub https://github.com/Steema/BI/wiki g+ https://plus.google.com/communities/117324086536146457211 site http://www.steebi.com/ Download Size Date Description TeeBI for RAD Studio Beta 9 42MB 29th Feb 2016 Includes full source code for Delphi RAD Studio XE4 up to XE10 Seattle Update 1 ЗЫ: В дальнейшем сообщать о найденных интересных библиотеках для FMX?

Конечно, самое простое кинуть в Content TRectangle с Align = MostBottom, покрасить его в черный цвет. И конечно Content.Margins.Bottom := 0;

какой текст? другой компонент без фокуса?

Прости меня за непонятливость, но я вообще не врубился что вы написали))). Если хотите помощи, пишите понятнее и прилагайте фото.

Как-то так #include "Unit1.h" //--------------------------------------------------------------------------- #pragma package(smart_init) #pragma resource "*.fmx" TForm1 *Form1; int c=0; //--------------------------------------------------------------------------- __fastcall TForm1::TForm1(TComponent* Owner) : TForm(Owner) { } //--------------------------------------------------------------------------- void __fastcall TForm1::Timer1Timer(TObject *Sender) { c=c+20; Arc1->EndAngle=c; if (c<90) {Text1->Text="4";} else if (c<180) {Text1->Text="3";} else if (c<270) {Text1->Text="2";} else if (c<360) {Text1->Text="1";} else if (c==360) {Timer1->Enabled=False;Text1->Text="0";c=0;} } //--------------------------------------------------------------------------- void __fastcall TForm1::Button1Click(TObject *Sender) { Arc1->EndAngle=0; Timer1->Enabled=true; } //--------------------------------------------------------------------------- ArcTimer.zip

Клик по итему Как уже предыдущие пользователи правильно заметили, нажатие на итем в списке самый интуитивно понятный способ на мобильных платформах. По скольку это полностью совпадает с правилами построения пользовательского интерфейса на мобильных платформах. Не надо придумывать свои способы, когда уже есть стандартные. Этим вы только запутаете пользователя, привыкшего к общему принципу работы с любым приложением. Если вам такой способ нужен, то лучше перепроектируйте ваш интерфейс, чтобы этого избежать (смотрите пункт 1.) Открытие нового вида На счет этого, если вы делаете приложение под андроид, то я бы не рекомендовал для этих целей использовать TTabControl. По одной самой главной причине: Потребление дополнительных ресурсов. Заставляет форму создавать все контролы на всех вкладках, даже на тех, что не видны. Легко представить типичную ситуацию, когда ваше приложение довольно большое и содержит большое число форм ввода и редактирования данных. Теперь представьте, что все эти контролы создаются при запуске приложения и живут все время существования приложения. Это совсем не маленькие размеры памяти, особенно на Андроиде. Ресурсы мобильной платформа не равны ресурсам настольных платформ. И если на настольной системе вы можете особо не заморачиваться о размере потребляемой памяти, так как ее много. То на мобильнике это может привести к нехватке памяти и как следствие разрушение вашего приложения. Главная идея - это иметь в каждый момент времени только то, что нужно. Поэтому я бы лучше рассматривал либо создание отдельной формы, либо создание в рантайме специального слоя (вида), которые будет загружен по верх всего, а потом будет разрушен после окончания выполнения редактирования. Так же советую использовать фреймы для таких функционально законченных блоков (редакторы сущности): Позволяет быстро и удобно создавать в нужное время на мобильной платформе требуемый вид. Забирая от системы ресурсы только в тот момент, когда они действительно необходимы. Повторное использование в других местах приложения.