kami
-
Постов
643 -
Зарегистрирован
-
Посещение
-
Победитель дней
41
Весь контент kami
-
Ох уж эти любители "удалить себя из себя". dim - обрати внимание на тему
-
а если сделать не при запуске, а (временно) по нажатию на какую-нибудь кнопку, чтобы до перехода по URL WB 100% полностью инициализировался, отобразился и так далее.
-
Нет, не пойдет. Потому что DoOnCloseInfo по прежнему вызывается из внутренностей TButton.Click. Если ваш код отрабатывает на Windows - это ваша недоработка, а не показатель правильности. Причины я изложил выше. А на мобильных платформах с фреймом визуально просто ничего не произойдет. Причины опять-таки изложил выше. И в таком виде тоже не пойдет. Потому что Synchronize и Queue, будучи вызванными из главного потока, моментально передают управление в метод, а не дожидаются очередного витка выборки сообщений у Application. В таком виде вы просто добавляете несколько вложенных вызовов, увеличивая занятость стека. Не меняя при этом концепцию работы.
-
так не пойдет На Windows - получим тот же AV, ибо по нажатию на кнопку вызовется DoOnCloseInfo, по завершению которой фрейма и кнопки на нем уже не будет. А во внутренностях TControl по завершению вызова OnClick еще идет обращение к себе. На мобильной платформе - ничего не случится, потому что ARC и фрейм еще присутствует у своего родителя, простое за nil-ивание ссылки ничего не даст. Правильный выход - непосредственно в обработчике кнопки сделать fr.Release;
-
Да, было. Более того - с подобным борюсь сейчас, переделывая логику уже работающего приложения :). Правда, баги не "непонятные", а вполне себе адекватные, видимо из-за того, что изначальная архитектура была неплоха. Такая ситуация говорит о том, что не продумана логика взаимодействия этих частей. И очень хорошо, что это вылезло до релиза.
- 2 ответа
-
- 1
-
-
Я искал (перед тем, как написать предыдущее сообщение) - не нашел. Посему - мой предыдущий пост написан именно на основе собственных умозаключений. В частности: в Windows сообщения отправляются окну, которое описывается хендлом этого окна. Каждый хендл принадлежит какому-нибудь конкретному процессу и потоку. Поэтому Windows может и переключает контекст потока для выборки сообщения оконной процедурой. В FMX сообщения отправляются объекту. Объект - существо интернациональное, оно существует без привязки к какому-нибудь потоку, а некоторые - так вообще не могут существовать в пределах одного (TThread). Собственно, именно поэтому я и пришел к выводу, что раз нельзя определить, в каком потоке сообщение должно быть принято объектом, значит всё происходит именно в текущем.
-
SendMessage через механизмы FMX !=SendMessage через механизмы Windows. Да, в Windows получатель обработает сообщение в том потоке, в котором принявшее сообщение окно было создано. Боюсь, что SendMessage из FMX не учитывает это, так что прием сообщения осуществляется в контексте вызывающего потока. Со всеми вытекающими.
-
первое вычеркнуть. Остановилось в развитии, команда разогнана, перспектив нет.
-
никак. Нужно смотреть библиотеки, позволяющие работать с OpenDocument (или как-то так) форматом, и создавать документ самому. Стартер не дает возможности пользоваться COM-объектами.
-
вот именно, что это - компонент, а не контрол. И его достаточно иметь в любом "общем" модуле, возможно - даже создать в runtime. В общем, его достаточно иметь в одном экземпляре. Но - дело ваше.
-
Чего-то вы вообще не в ту степь полезли. Не надо подменять понятия и считать что кто-то сделает за вас всю работу. Еще раз - язык программирования, фреймворк, набор каких-либо исходников и т.п. не является устойчивым к взлому. Устойчивость придают усилия программиста, который намеренно защищает критичные участки своего кода различными доступными ему средствами. Это и только это придает устойчивость. Чтобы начали ломать софт на FMX - софт должен стать популярным. Вероятность популяризации софта в какой-то мере пропорциональна количеству написанного софта. Количество написанного софта тем больше, чем популярнее язык/фреймворк. Посему - фразу следует построить так "Когда (если) FMX станет популярным - появится и взломанный софт, написанный на нем". Все правильно.
- 24 ответа
-
- 1
-
-
- лицензия
- лицензирование
- (и ещё 2 )
-
ну, это уже ваша задача - выяснить, почему не происходит SetEvent, в результате чего ожидание висит все 15 секунд. И где оно вообще должно происходить. И должно ли.
-
ну почему? стандартная практика выполнения следующего действия, если выполнено предыдущее. Вернее, один из стандартных приемов, если разработчик отрицательно относится к слову exit. читать следует так: если получилось FJGatt.discoverServices, то пробуем чего-то дождаться. Если дождались успешно - то делаем все остальное. Т.е. до "всего остального" очередь дойдет только если выполнились успешно оба предыдущих условия. При этом второе условие выполнилось только в случае успешного выполнения первого.
-
Да. Сравнение одного значения с другим, получается True или False и записывается в Result. Что ж здесь неправильного?
-
да, будет. Вопрос про логику - на quality.embarcadero.com. без понятия. Но с учетом того, что перед этим идет FLastStatus := TBluetoothGattStatus.Failure; то другой поток все-таки по мнению авторов кода существует. И в нем статус может (и по идее - должен) поменяться. На основании каких условий - нужно разбираться с классами этого синезуба.
-
ну, это же не гарантированная задержка. Если какой-либо другой поток сделает этому FServicesEvent.SetEvent, то будет выход из WaitFor.
-
Давайте сперва уточним, что именно вы подразумеваете под взломом? Потому что если рассматривать взлом, как его понимаю я - то всякие "проверки сертификатов" будут убраны в ходе этого взлома. Поскольку являются неотъемлимой частью хака приложения. Взлом и дальнейшее распространение на мой взгляд - это "сделать так, чтобы программа всегда считала себя лицензионной и работала как ни в чем ни бывало".
- 24 ответа
-
- 1
-
-
- лицензия
- лицензирование
- (и ещё 2 )
-
Вы подменяете терминологию. Никакое приложение само по себе не является устойчивым к взлому, если оно не содержит средства защиты от этого взлома. На каком бы языке ни было написано. Более того, нужно отличать хак приложения (чтобы оно запустилось вне зависимости от наличия лицензии) и получение данных, с которыми работает это приложение.
- 24 ответа
-
- 2
-
-
- лицензия
- лицензирование
- (и ещё 2 )
-
клиентскую часть, т.е. непосредственно само приложение - никак. Без доступа к серверу в моем случае оно бесполезно. Сервер может обладать информацией о всех устройствах, которые когда-либо к нему подключались и может блокировать новые, если лимит используемых устройств превышен. Или блокировать конкретные, если они выведены из эксплуатации. Или вообще залочить доступ всем устройствам клиента - по усмотрению. Но это в моем случае, т.к. приложение не общедоступно и не будет выкладываться в AppStore. Ну и "вылечивать" приложение в моем случае смысла нет - достаточно скоро его функционал просто устареет, и крякнутая программа просто станет не актуальной. В общем и целом, если программе требуется подключение к серверу - защиту нужно реализовывать имено на нем. Но от взлома защищаться бессмысленно - когда приложение станет действительно популярным, его все равно поломают. А до тех пор - можно спать спокойно, взломщики даже не посмотрят в вашу сторону.
- 24 ответа
-
- 3
-
-
- лицензия
- лицензирование
- (и ещё 2 )
-
Давайте вернемся к вопросу. Что конкретно не получается?
-
Работает. Правда, без симулятора и бывает приложение переклинивает, но я списываю это на активное использование TWebBrowser.
-
Сижу на XCode 8.0 Крайнее выпущенное обновление моего приложения совместимо с iOS 10.2, всё работает. Поясните более подробно, в чем именно выражается "не работает"?
-
Зачем вообще указывать имя компоненту, создаваемому в runtime? Они прекрасно живут и без этого, а для идентификации конкретного - есть куча свойств TagXXX
-
А можно и не выходить из IDE: Ctrl+Shift+F, выбираем Search in directories.