RoschinSpb

Пользователи
  • Публикаций

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

  • Посещение

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

    8

RoschinSpb стал победителем дня 24 января

RoschinSpb имел наиболее популярный контент!

3 Подписчика

Информация о RoschinSpb

  • Звание
    Embarcadero FireMonkey разработчик

Контакты

  • Сайт
    http://blogs.embarcadero.com/roschinspb

Информация

  • Пол
    Не определился
  • Город
    Санкт-Петербург

Посетители профиля

942 просмотра профиля
  1. Теоретически возможно всё. Практически, если бы это было возможно сделать без переписывания FMX, то это бы сделали с самого начала.
  2. Индусы в основном из незалежной... :o)
  3. RoschinSpb

    Windows на сенсорном экране и события мыши

    Как я понимаю здесь не применим и GetSystemMetrics(SM_TABLETPC)<>0, т.к. в общем случае можно курсор двигать и с помощью мыши и с помощью пальца. Существуют обычные настольные мониторы с сенсорной поверхностью. Тут наверно нужно учесть, что пользователь обычно не водит пальцем по сенсорному экрану, а просто тыкает пальцем на контролы, исходя их этого допущения можно что-то придумать с подсказками. Мой совет: лучше исхитряться в сторону использования стандартных высокоуровневых возможностей остаётся в силе
  4. RoschinSpb

    Windows на сенсорном экране и события мыши

    Если всё прикладное приложение обвешивать директивами условной компиляции, то реально работать будет невозможно, не говоря уже о том, что в этом случае надо будет изучить апи каждой платформы. Поэтому лучше исхитряться в сторону использования стандартных высокоуровневых возможностей. Директивы условной компиляции обычно используются только для тех случаев, где действительно логика работы зависит от платформы: {$IFDEF MSWINDOWS} Caption := Caption + ' for Windows'; {$ENDIF} В данном случае проверять наличие значения Touch в Shift.
  5. RoschinSpb

    Windows на сенсорном экране и события мыши

    Подозреваю Shift содержал значение ssTouch GetSystemMetrics(SM_TABLETPC)<>0 На андроиде работает? Это я к тому, что если Вы привязываете работу только к Windows, то лучше пользоваться VCL это и проще и стабильнее и сторонних библиотек немеряно написано. А при использовании FMX не стоит использовать системные функции т.к. это уничтожит одно единственное достоинство Fire Monkey - кроссплатформенность.
  6. RoschinSpb

    Ручная анимация прокрутки списка

    Можно попробовать TListBox.AniCalculations.MouseWheel См. также Платформонезависимый скроллинг в Fire Monkey
  7. RoschinSpb

    Canvas,

    Если всё сделать в одном блоке BeginScene EndScene, и без Application.ProcessMessages и Repaint не заработает? if panel.Canvas.BeginScene then try // рисовать всё finally panel.Canvas.EndScene; end;
  8. RoschinSpb

    Рисует за пределами канвы

    На всякий случай, напомню, если контрол или канву повернуть, то все обрезки перестают действовать на мобильных устройствах.
  9. RoschinSpb

    imagelist1 property source does not exists

    Да, именно так, сам на это напарывался, даже вроде баг заводил. Понять это невозможно, это надо знать! Раздел Uses может добавиться автоматически, например по Ctrl+A и он добавляется после implementation и перед %CLASSGROUP.
  10. RoschinSpb

    TGrid vs Тач интерфейс

    Да. Во всяком случае так было в той версии которая у меня и которой я занимался. Задержка порядка 50 мс. это мало, чтобы заметить но не 0. Если бы задержки не было вообще, то при любой попытке скрола, менялась бы выделенная ячейка. Вот видео, записал как смог. Это ни как не настраивается, просто после многих проб и ошибок подобрался наиболее оптимальный вариант. Похожий на стандартное поведение. Да, были с этим проблемы, при чем как всегда: "Не знаю, не знаю, у меня всё работает, что у вас за телефон?". Тут надо понимать, что это некие искусственные события которые эмулируют работу с мыши т.е. добавляют свою логику поверх системной, и там в зависимости от модели могут быть разные особенности, лучше обрабатывать жесты. Посмотрите исходники, можно сделать по образу и подобию. А чем собственно не удовлетворяет стандартное поведение? Я так и не понял.
  11. RoschinSpb

    TGrid vs Тач интерфейс

    Да, действительно в случае грида, перемещение пальца не рассматривается как клик по ячейке, а рассматривается как скроллирование. Если прикоснулся пальцем и держал на месте короткое время, или прикоснулся и сразу отпустил не перемещая, то это считается желанием выделить ячейку (начать редактирование), и приводит к событию OnCellClick. Если прикоснулся пальцем и сразу начал двигать, то считается что пользователь захотел переместить рабочую область таблицы (проскроллировать) и это не приводит к выделению ячейки и событию OnCellClick. Это нормальное и корректное поведение: ячейки "не кликаются", когда пользователь просто перетаскивает рабочую область таблицы. Если хотите странного, то обрабатывайте события OnMouseDown, OnTap и т.п. по своему собственному усмотрению на свой страх и риск игнорируя всю остальную логику работы таблицы.
  12. RoschinSpb

    Фоновый цвет TGrid

    Потому, что изначально все контролы были заточены на использование стилей. Подмена стиля влечет за собой изменение всех цветов оптом. Если Вы прибиваете гвоздями некий цвет то при различных стилях это будет выглядеть непредсказуемо. Например: хотите сделать желтый грид в то время как умолчательный цвет окна белый, вроде нормально... теперь допустим оказалось, что стиль какой-нибудь темно-зеленый фон со светло-салатным текстом, получаем ядовитую таблицу с практически нечитаемым текстом. Вам это надо? Не обязательно даже использовать какой-нибудь экзотический стиль. В IOS и Android в зависимости от системных настроек может быть светлый и темный стиль, т.е. белые окна с черным текстом и черные окна с белым текстом. Кроме того как такового цвета грида не существует, т.к. в качестве фона используется картинка. При использовании стандартных стилей она представляет из себя сплошную заливку, но в некоторых стилях там присутствует некоторый фоновый рисунок. Обработчик события по которому можно самостоятельно рисовать ячейку имеется, но он не работает для случая нативного грида по причине тормозов с отрисовкой. Вообще рисование на канве мобильных устройств выполняется очень медленно отсюда и жалобы на неадекватные тормоза гридов и прочего, что сподвигло на широкое использование родных-нативных контролов. Почему изначально всё заточено на стили, ну... так исторически сложилось, за подробностями обращайтесь к автору.
  13. Для придания завершенности Вашему контролу надо бы еще реализовать интерфейс ITextSettings чтобы можно было использовать его как в примере:
  14. Ячейка/эдит/мемо с данными, которые не могут меняться, нужны для того, чтобы хотя бы скопировать весь, или часть текста в буфер обмена, для этого и существует свойство ReadOnly. Только текст который не содержит меняющихся данных (метка/заголовк) практически ни когда не требуется копировать в буфер обмена, но такие элементы пользовательского интерфейса не требуют и получения фокуса ввода. Запрет на выделение ячейки легко делается OnSelectCell. Ввод новых свойств с мутным смыслом всегда дело неблагодарное. Например: Enabled := False; Editing := True; Серая колонка, нельзя войти в режим редактирования ячейки -> Баг! Я поставил Editing в True, очевидно что должна быть возможность войти в режим редактирования. Вы там с логикой дружите? Серая колонка, можно войти в режим редактирования -> Баг! Колонка выглядит как недоступная, тем не меняя можно войти в режим редактирования. Что за дизайн? Обычная колонка, нельзя войти в режим редактирования -> Баг! Enabled у меня стоит False, а колонка выглядит как доступная, очевидно что если Enabled = False, должна быть серая как и все элементы управления. Вы лучше баги правьте, а не ломайте то, что работает! Обычная колонка, нельзя войти в режим редактирования, Enabled становится False -> Баг! В очередной версии почему-то свойство Enabled самопроизвольно меняет своё значение. Почему в каждой версии что-нибудь да отваливается? TGridOption.Editing = not Grid.ReadOnly - полезно для ситуаций, когда надо явно переходить в режим изменения данных с использованием блокировок. Нажимаем кнопку "изменить" - можно вводить данные, нажимаем кнопку "применить" - нельзя вводить данные, но по прежнему можно смотреть. Было бы не плохо, если бы Вы тут выложили пример своей идеальной колонки, это бы ввело обсуждение в конструктивное русло. А то после всего написанного Капитан Очевидность шепчет о том, что к программированию Вы имеете весьма опосредованное отношение, но я конечно не верю. В конце концов хороший программист не обязан писать повести как Лев Толстой и тут простого примера было бы достаточно, чтобы расставить все точки над Ė, да и след в истории будет хороший. За сим прощаюсь, т.к. действительно общение вышло за рамки заявленной темы и превратилось в оффтоп переходящий в троллинг.
  15. Может но не обязан, так же как и Ваше идеальное событие. Так же как аналогичное VCL-ное событие работает с прошлого века, странно, что Вы этого не знаете программируя начиная с Delphi2. Т.е. свойство которое запрещает редактирование доступного столбца (любопытно, должно ли оно разрешать редактирование недоступного столбца?). Да, как-то за пять лет заявок не эту тему не припомню. У TEdit, кстати тоже есть только ReadOnly и Enabled, а что-то среднее называется TLabel и ни кто не жаловался. Конечно реальная жизнь сложна и многогранна наверняка найдется пользователи которым это понадобилось бы, кому-то и розовый котенок в пятом углу нужен, но данный функционал не особо востребован. Так или иначе есть возможность создать своего наследника колонки и в Runtime, и зарегистрировать его в IDE для работы в DesignTime.