Перейти к содержанию
Fire Monkey от А до Я

krapotkin

Пользователи
  • Постов

    2 187
  • Зарегистрирован

  • Посещение

  • Победитель дней

    209

Весь контент krapotkin

  1. вот кусок из рабочего кода. если протрассировать по FindObject, то можно найти все элементы, которые создаются автоматом при создании итема и заполнить тут, в коде
  2. да. в onUpdate или в onUpdating я их все время путаю фигачим по 10 однотипных строк на каждый элемент итема и получаем полный контроль
  3. OFF. вот сто раз уже писали, LiveBinding is DeadBinding )) Надо все руками. Быстро и надежно
  4. Ну вообще для меня вот неочевидно, что размер невидимого компонента должен быть определен. если у меня три панели и две из них невидимы, то это сильно влияет на размеры и положение третьей
  5. а этап выравнивания это когда? может, найти другой момент для расчетов? типа onresize
  6. ну, к вопросу это непосредственно не относится, скорее к методологии, когда на frame2 мы обращаемся к frame1.comboBox1.Itemindex или еще хуже к frame3.edit1.text. и тут выясняется что frame1/3 не создан/находится не в том состоянии, и т.д. и т.п. Или классика "Почему в FMX нет button1.Click() ?" ))) Если данные как положено - в переменных, то они доступны вне зависимости от наличия и видимости на экране разных UI
  7. про чарт ничего не знаю, не юзал а вот про табы истину говорю, пустые все кроме первого нужны)) удалять обычно уже нет смысла, они памяти не много жрут. дело во времени создания и самое главное - применения стиля. кроме того фреймы это единственный способ разнести логику этой огромной формы на 8 страниц ну и неплохо бы еще чтобы модель данных жила отдельно от форм и фреймов ...
  8. на мобильной форме ну просто не должно быть много компонентов чаще всего приложение строится на переходе по формам или по табам в табконтроле, тогда тем более вспоминаем про фреймы и создаем их на нужных вкладках динамически
  9. я теряю нить. какое смешивание, если просто TRectangle накатить на кнопку? или если вместо кнопки использовать TRectangle ??
  10. что значит без модуляции ? наоборот. обрабатываем события OnMouseEnter, OnMouseLeave и меняем Fill.Color вот и готова кнопка при желании можно и по OnClick создать TCircle полупрозрачный с анимацией, но это прямо желание нужно иметь
  11. он и так не во всех темах есть... а стандартный олдскул - 4 цвета в соответствии с состоянием кнопок делать 5 сек
  12. положить в нее ректангл а самый простой - это просто использовать ректангл вместо кнопки
  13. гораздо проще '1234567890'.Contains(ch)
  14. ссылок было уже до кучи header это такой же итем, и у него точно так же достается текст как и у всех остальных Name для элемента тоже показывается в редакторе итема Можно даже просто в обработчике перечислить и посмотреть все имена всех элементов итема, чтобы понять, как там что устроено
  15. я заполняю структуры данных, не имеющие отношения к форме, да еще и в главном потоке, так что все пучком пока.
  16. а почему поток должен крешить систему, я не пойму? не нужно из потока обращаться к переменным. можно задать ему обработчик OnTerminate конечно и форма, из которой его вызвали может перестать существовать, но тогда просто обработчик вешать на то что существовать точно БУДЕТ
  17. вот мне тоже интересно как это чего разорвать?
  18. повис, да и пусть висит себе. все равно прервать системную функцию вам не удастся раньше её функции желания зато вы легко можете игнорировать результат выполнения такого потока, если/когда он все же вернется
  19. да. предлагаю. А если вам лень и вообще bindSource, то вы же сами себе выбрали технологию ))) сами ее и пользуйте. Тут особо никто с liveBinding не играется, т.к. они уж больно подозрительные, а если что, как известно, никто в делфи ошибки не исправляет. Да и производительность решения должна быть крайне невысокой. Предложение в лоб - перейти по датасету на N-ую запись от начала, и дальше оттуда брать все данные. N=index Если бы вы сами создавали итемы, то вы могли бы вообще все данные вставить в свойство Data item.Data['xxx'] := yyy ... aaa := item.Data['xxx'].AsInteger; Мне при разработке всегда было приятнее иметь железобетонные технологии, даже если они не самые передовые. Так что модель данных это гораздо лучше прямой работы с датасетом
  20. нет. 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;
  21. и это "где-то" - не лист-вью и я первый раз слышу, что разработчик листвью дал вам вводить данные прямо в листвью... зачем листью KeyID? У него есть индекс. Этот же индекс есть и у вашей структуры, в которой вы храните свои данные. А там уже KeyID или что хотите храните
  22. тут же все уже написано выше все данные складывайте в переменные и без всяких потоков. одним простым таймером выводите значения переменных на экран раз в 300-500 мсек
  23. более правильный - это СОЗДАВАТЬ лист по мотивам некоей структуры в программе, она же - модель данных. и брать все нужные значения оттуда. модно. стильно. молодежно а хранить данные на экране - моветон
×
×
  • Создать...