kami

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

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

  • Посещение

  • Days Won

    14

kami last won the day on 11 февраля

kami had the most liked content!

3 подписчика

О kami

  • Звание
    Продвинутый пользователь
  • День рождения 16.06.1981

Информация

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

Контакты

  • StackOverflow
    http://ru.stackoverflow.com/users/192901/kami

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

409 просмотров профиля
  1. SDK в среду подтянул? http://cc.embarcadero.com/Item/30680
  2. Возможно, причина как раз в этом. Восьмой XCode не гарантирует работу с 10.2, о чем честно пишет в окне Devices при подключении устройства. Требуется обновить XCode и установить hotfix для PAServer. Альтернативный вариант, который я использовал до появления hotfix: запустить XCode - Windows - Devices - выбрать подключенное устройство, нажать "+", найти сформированный ipa-файл (в первую очередь он деплоится именно в эту папку, и только потом копируется на комп с IDE и на устройство) и выбрать его. Путь, по которому лежит ipa на маке - сейчас не подскажу, завтра утром могу глянуть.
  3. Понимаю, что предложение не по теме, но все же - почему не воспользоваться дженериками?
  4. А там что? Обращение к визуальным компонентам?
  5. Ох уж эти любители "удалить себя из себя". dim - обрати внимание на тему
  6. а если сделать не при запуске, а (временно) по нажатию на какую-нибудь кнопку, чтобы до перехода по URL WB 100% полностью инициализировался, отобразился и так далее.
  7. Нет, не пойдет. Потому что DoOnCloseInfo по прежнему вызывается из внутренностей TButton.Click. Если ваш код отрабатывает на Windows - это ваша недоработка, а не показатель правильности. Причины я изложил выше. А на мобильных платформах с фреймом визуально просто ничего не произойдет. Причины опять-таки изложил выше. И в таком виде тоже не пойдет. Потому что Synchronize и Queue, будучи вызванными из главного потока, моментально передают управление в метод, а не дожидаются очередного витка выборки сообщений у Application. В таком виде вы просто добавляете несколько вложенных вызовов, увеличивая занятость стека. Не меняя при этом концепцию работы.
  8. так не пойдет На Windows - получим тот же AV, ибо по нажатию на кнопку вызовется DoOnCloseInfo, по завершению которой фрейма и кнопки на нем уже не будет. А во внутренностях TControl по завершению вызова OnClick еще идет обращение к себе. На мобильной платформе - ничего не случится, потому что ARC и фрейм еще присутствует у своего родителя, простое за nil-ивание ссылки ничего не даст. Правильный выход - непосредственно в обработчике кнопки сделать fr.Release;
  9. Да, было. Более того - с подобным борюсь сейчас, переделывая логику уже работающего приложения :). Правда, баги не "непонятные", а вполне себе адекватные, видимо из-за того, что изначальная архитектура была неплоха. Такая ситуация говорит о том, что не продумана логика взаимодействия этих частей. И очень хорошо, что это вылезло до релиза.
  10. Я искал (перед тем, как написать предыдущее сообщение) - не нашел. Посему - мой предыдущий пост написан именно на основе собственных умозаключений. В частности: в Windows сообщения отправляются окну, которое описывается хендлом этого окна. Каждый хендл принадлежит какому-нибудь конкретному процессу и потоку. Поэтому Windows может и переключает контекст потока для выборки сообщения оконной процедурой. В FMX сообщения отправляются объекту. Объект - существо интернациональное, оно существует без привязки к какому-нибудь потоку, а некоторые - так вообще не могут существовать в пределах одного (TThread). Собственно, именно поэтому я и пришел к выводу, что раз нельзя определить, в каком потоке сообщение должно быть принято объектом, значит всё происходит именно в текущем.
  11. SendMessage через механизмы FMX !=SendMessage через механизмы Windows. Да, в Windows получатель обработает сообщение в том потоке, в котором принявшее сообщение окно было создано. Боюсь, что SendMessage из FMX не учитывает это, так что прием сообщения осуществляется в контексте вызывающего потока. Со всеми вытекающими.
  12. первое вычеркнуть. Остановилось в развитии, команда разогнана, перспектив нет.
  13. никак. Нужно смотреть библиотеки, позволяющие работать с OpenDocument (или как-то так) форматом, и создавать документ самому. Стартер не дает возможности пользоваться COM-объектами.
  14. вот именно, что это - компонент, а не контрол. И его достаточно иметь в любом "общем" модуле, возможно - даже создать в runtime. В общем, его достаточно иметь в одном экземпляре. Но - дело ваше.
  15. Чего-то вы вообще не в ту степь полезли. Не надо подменять понятия и считать что кто-то сделает за вас всю работу. Еще раз - язык программирования, фреймворк, набор каких-либо исходников и т.п. не является устойчивым к взлому. Устойчивость придают усилия программиста, который намеренно защищает критичные участки своего кода различными доступными ему средствами. Это и только это придает устойчивость. Чтобы начали ломать софт на FMX - софт должен стать популярным. Вероятность популяризации софта в какой-то мере пропорциональна количеству написанного софта. Количество написанного софта тем больше, чем популярнее язык/фреймворк. Посему - фразу следует построить так "Когда (если) FMX станет популярным - появится и взломанный софт, написанный на нем". Все правильно.