krapotkin

я наоборот, справился без грида, выбрал LV, Равиль вообще написал ModernLV где всё, говорят, еще проще та же фигня. код надо писать ))

вот кусок из рабочего кода. если протрассировать по FindObject, то можно найти все элементы, которые создаются автоматом при создании итема и заполнить тут, в коде

да. в onUpdate или в onUpdating я их все время путаю фигачим по 10 однотипных строк на каждый элемент итема и получаем полный контроль

OFF. вот сто раз уже писали, LiveBinding is DeadBinding )) Надо все руками. Быстро и надежно

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

а этап выравнивания это когда? может, найти другой момент для расчетов? типа onresize

ну, к вопросу это непосредственно не относится, скорее к методологии, когда на frame2 мы обращаемся к frame1.comboBox1.Itemindex или еще хуже к frame3.edit1.text. и тут выясняется что frame1/3 не создан/находится не в том состоянии, и т.д. и т.п. Или классика "Почему в FMX нет button1.Click() ?" ))) Если данные как положено - в переменных, то они доступны вне зависимости от наличия и видимости на экране разных UI

про чарт ничего не знаю, не юзал а вот про табы истину говорю, пустые все кроме первого нужны)) удалять обычно уже нет смысла, они памяти не много жрут. дело во времени создания и самое главное - применения стиля. кроме того фреймы это единственный способ разнести логику этой огромной формы на 8 страниц ну и неплохо бы еще чтобы модель данных жила отдельно от форм и фреймов ...

на мобильной форме ну просто не должно быть много компонентов чаще всего приложение строится на переходе по формам или по табам в табконтроле, тогда тем более вспоминаем про фреймы и создаем их на нужных вкладках динамически

кроме того, уListView есть Overscroll

я теряю нить. какое смешивание, если просто TRectangle накатить на кнопку? или если вместо кнопки использовать TRectangle ??

что значит без модуляции ? наоборот. обрабатываем события OnMouseEnter, OnMouseLeave и меняем Fill.Color вот и готова кнопка при желании можно и по OnClick создать TCircle полупрозрачный с анимацией, но это прямо желание нужно иметь

он и так не во всех темах есть... а стандартный олдскул - 4 цвета в соответствии с состоянием кнопок делать 5 сек

положить в нее ректангл а самый простой - это просто использовать ректангл вместо кнопки

гораздо проще '1234567890'.Contains(ch)

ссылок было уже до кучи header это такой же итем, и у него точно так же достается текст как и у всех остальных Name для элемента тоже показывается в редакторе итема Можно даже просто в обработчике перечислить и посмотреть все имена всех элементов итема, чтобы понять, как там что устроено

я заполняю структуры данных, не имеющие отношения к форме, да еще и в главном потоке, так что все пучком пока.

а почему поток должен крешить систему, я не пойму? не нужно из потока обращаться к переменным. можно задать ему обработчик OnTerminate конечно и форма, из которой его вызвали может перестать существовать, но тогда просто обработчик вешать на то что существовать точно БУДЕТ

вот мне тоже интересно как это чего разорвать?

повис, да и пусть висит себе. все равно прервать системную функцию вам не удастся раньше её функции желания зато вы легко можете игнорировать результат выполнения такого потока, если/когда он все же вернется

да. предлагаю. А если вам лень и вообще bindSource, то вы же сами себе выбрали технологию ))) сами ее и пользуйте. Тут особо никто с liveBinding не играется, т.к. они уж больно подозрительные, а если что, как известно, никто в делфи ошибки не исправляет. Да и производительность решения должна быть крайне невысокой. Предложение в лоб - перейти по датасету на N-ую запись от начала, и дальше оттуда брать все данные. N=index Если бы вы сами создавали итемы, то вы могли бы вообще все данные вставить в свойство Data item.Data['xxx'] := yyy ... aaa := item.Data['xxx'].AsInteger; Мне при разработке всегда было приятнее иметь железобетонные технологии, даже если они не самые передовые. Так что модель данных это гораздо лучше прямой работы с датасетом

нет. for i:=0 to MySuperDataModel.ListOfSomething.Count-1 do begin CreateListViewItem(MySuperDataModel.ListOfSomething[i]): end; procedure TForm1.OnItemClick(...index:integer...); begin something := MySuperDataModel.ListOfSomething[index]; showMessage(something.SomeTextProperty); end;

и это "где-то" - не лист-вью и я первый раз слышу, что разработчик листвью дал вам вводить данные прямо в листвью... зачем листью KeyID? У него есть индекс. Этот же индекс есть и у вашей структуры, в которой вы храните свои данные. А там уже KeyID или что хотите храните

тут же все уже написано выше все данные складывайте в переменные и без всяких потоков. одним простым таймером выводите значения переменных на экран раз в 300-500 мсек

более правильный - это СОЗДАВАТЬ лист по мотивам некоей структуры в программе, она же - модель данных. и брать все нужные значения оттуда. модно. стильно. молодежно а хранить данные на экране - моветон