Лидеры

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

Конвертации вида: TTime <-> String TDate <-> String TDateTime <-> String являются базовыми операциями в RTL и не имеют отношения к компоненту TTimeEdit. Чтобы время перевести в строку с требуемым форматом, нужно использовать метод FormatString: TimeEdit1->Time.FormatString("hh:nn:ss"); По умолчанию все функции конвертации без параметров используют настройки формата из FormatSettings. Можете поменять стандартный формат в этой глобальной переменной, тогда все функции будут использовать ваш формат.

Клик по item в ListView самый удачный и интуитивно-понятный вариант.

Поняли правильно, системный диалог выбора времени на андроиде не дает возможности изменять секунды и миллисекунды. Чтобы заменить значение миллисекунд на свое вы можете воспользоваться функцией RecodeSecond или RecodeMilliSecond: #include "System.DateUtils.hpp" void __fastcall TForm1::TimeEdit1Change(TObject *Sender) { TimeEdit1->DateTime = RecodeSecond(TimeEdit1->DateTime, 0); }

Если у вас на клики по элементам ListView не будет больше никаких действий, то правильней будет если пользователь будет иметь возможность кликнуть в любую часть строки (для этого обработку клика надо делать всей строки, а элементам отключать HitTest). Галочек как и полос прокрутки на мобильных девайсах стоит по возможности избегать, по ним неудобно попадать. В качестве места для расположения редактора времени я бы предложил невидимую до нажатия панельку, это ускорит работу ибо не потребуются ресурсы на создания окна. Уточню, что я не в курсе как там дела именно на android-е, и можно ли там отрисовать панельку поверх других элементов формы. Но если можно это на мой взгляд лучший вариант. А область за панелькой просто затемнить в момент её появления, что бы сконцентрировать внимание пользователя на ней.

Хотелось бы чтобы в этиx статьях были бы и примеры кода на С++ для Builder. Ну хотя бы основные моменты. Иногда очень сложно понять как портировать код на паскале в проект С++. Бывает проект на паскале работает, а с кодом на С++ нет. Сейчас С++ Builder ХЕ6 полностью поддерживает все виды проектов FM, поэтому хотелось бы чтобы С++ также не обделили вниманием. Спасибо. Очень сильно поддерживаю - не забывайте за бульдозеристов - если будет код на делфи - рядом на с++