kami

Да! Я знал, что мыслю в нужном направлении

Да! Я знал, что мыслю в нужном направлении

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

хм... ну сравните:
 
lbOptionCaption:=TLabel.Create(Panel); lbOptionCaption.Parent:=Panel; lbOptionCaption.Text:='some option'; cbOption1:=TCheckBox.Create(Panel); cbOption1.OnChecked:=.... cbOption1.Caption:='asdfasdf'; ...
с этим:
 
< накидали контролов на фрейм> fr:=TOptionsFrame.Create(Panel); fr.Parent:=Panel; И ВСЁ! Весь функционал реализуется внутри модуля фрейма. НЕЗАВИСИМО от всего остального.

Нет, конечно вы можете сделать свой компонент на основе панели, в нем реализовать нужный функционал, зарегистрировать его в IDE,.. но зачем переусложнять?

хм... ну сравните:
 
lbOptionCaption:=TLabel.Create(Panel); lbOptionCaption.Parent:=Panel; lbOptionCaption.Text:='some option'; cbOption1:=TCheckBox.Create(Panel); cbOption1.OnChecked:=.... cbOption1.Caption:='asdfasdf'; ...
с этим:
 
< накидали контролов на фрейм> fr:=TOptionsFrame.Create(Panel); fr.Parent:=Panel; И ВСЁ! Весь функционал реализуется внутри модуля фрейма. НЕЗАВИСИМО от всего остального.

1. Фреймы просто создавать динамически, в рантайме. Панельки с содержимым обычно накидывают на саму форму. С учетом кучи пунктов опций - получается гигантская каша, в которой без 100 грамм не разберешься.
2. Каждый фрейм - в отдельном модуле. Очень просто искать, редактировать, править функционал и при необходимости - удалять. В отличие опять-таки от этих панелек. Только не надо сами фреймы кидать на форму, как это делается с другими визуальными компонентами!

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

То есть - куда он пойдет гулять никто не знает? На любую из точек?
В таком случае, имхо, есть смысл сделать как это делается в оффлайн-навигаторах: приложение скачивается отдельно, а карты (аудиофайлы в нашем случае) - отдельно, по желанию пользователя.

То есть - куда он пойдет гулять никто не знает? На любую из точек?
В таком случае, имхо, есть смысл сделать как это делается в оффлайн-навигаторах: приложение скачивается отдельно, а карты (аудиофайлы в нашем случае) - отдельно, по желанию пользователя.

Нет, окончательное решение должно быть Ваше
Зачем? ноутбук + Connectify, все мобилки подключаются к 192.168.0.1 (адрес бука), на буке - простейший http-сервер на том же Delphi крутится сервисом. На get-запрос от приложения отдает в теле ответа аудиофайл. До начала экскурсии, в месте сбора. Можно даже сделать как "мобилка спрашивает - а куда сегодня пойдем", а сервер отвечает "пойдем туда-то, вот тебе файлы на сегодня", чтобы не перегружать пользователя лишними действиями.
Все довольны, все смеются.

Нет, окончательное решение должно быть Ваше
Зачем? ноутбук + Connectify, все мобилки подключаются к 192.168.0.1 (адрес бука), на буке - простейший http-сервер на том же Delphi крутится сервисом. На get-запрос от приложения отдает в теле ответа аудиофайл. До начала экскурсии, в месте сбора. Можно даже сделать как "мобилка спрашивает - а куда сегодня пойдем", а сервер отвечает "пойдем туда-то, вот тебе файлы на сегодня", чтобы не перегружать пользователя лишними действиями.
Все довольны, все смеются.

Добрый день,
На андроиде в принципе не поддерживаются синхронные диалоги. И причина прежде всего в архитектуре андроид приложения.
Если говорить о нативном приложении, то оно состоит из двух потоков Java UI Thread  (Он же главный поток приложения) и Delphi Thread. FireMonkey работает в делфи треде. В то время, как все нативные вещи (диалоги, пикеры, браузеры, карты, медиа проигрыватели и тд) все они работают в Java UI Thread. Помимо этого, когда активити (работает в так же в java UI thread) меняет своё состояние (запущена, приостановлена, остановлена, возобновлена и тд), она должна синхронизировать это состояние в делфи треде. Или другими словами передать эту информацию в делфи тред. Для передачи используются пайпы с событиями. Поэтому пока делфи тред не прочитает новое состояние активити, Java UI thread будет находится в режиме ожидания. Чтение в делфи потока нового состояния происходит в цикле ProcessMessage.
Теперь возвращаясь к диалогам. Диалоги нативные, поэтому они должны быть синхронизированы (с ожиданием) с java UI thread. С другой стороны, в момент отображения диалога происходит событие из java ui thread Window Gained Focus, возникающее, когда в приложении меняется фокус между окнами (диалоговое окно в данном случае перехватывает фокус). Но как мы выяснили, это приводит к обратной синхронизации с делфи тредом.
Отсюда возникает классический deadlock. 
P.S. Это верно до версии Берлин включительно.

Люди, помогите понять. Вот топикстартер - создает трехзвенку, работает с датаснап, mySQL, делает приложение под Андроид... то есть - довольно-таки сложные вещи. И не может прочитать сообщение об ошибке, путает компиляцию с исполнением ? о_О...

Люди, помогите понять. Вот топикстартер - создает трехзвенку, работает с датаснап, mySQL, делает приложение под Андроид... то есть - довольно-таки сложные вещи. И не может прочитать сообщение об ошибке, путает компиляцию с исполнением ? о_О...

Чтобы появилось на устройстве, Delphi должна увидеть это устройство. Если в Target для iOS32 пусто (не отображается нужное устройство) - нужно правой кнопкой на этом "Target" и нажать "Обновить". Если устройство таки не обнаружилось - переходим в XCode, Window - Devices, выбираем нужное устройство, нажимаем кнопочку "+", выбираем ipa файл (по умолчанию он емнип в "Устройство-пользователи - пользователь - PAServer-ScratchDir").
Ээээ... а кроме компиляции деплой делался?

Чтобы появилось на устройстве, Delphi должна увидеть это устройство. Если в Target для iOS32 пусто (не отображается нужное устройство) - нужно правой кнопкой на этом "Target" и нажать "Обновить". Если устройство таки не обнаружилось - переходим в XCode, Window - Devices, выбираем нужное устройство, нажимаем кнопочку "+", выбираем ipa файл (по умолчанию он емнип в "Устройство-пользователи - пользователь - PAServer-ScratchDir").
Ээээ... а кроме компиляции деплой делался?

Берлину нужен XCode 8. С 8.1 у вас просто не подтягивается список устройств симулятора. Любому берлину, начиная от просто и заканчивая Upd2.
Можно поставить 8.0 рядом с 8.1, зайти в XCode - Preferences - Locations и в Command Line Tools выбрать XCode 8.0.
После этого - перезапустить PAServer, в Delphi подтянуть новые SDK и обновить список устройств в TargetPlatforms для  симулятора

Берлину нужен XCode 8. С 8.1 у вас просто не подтягивается список устройств симулятора. Любому берлину, начиная от просто и заканчивая Upd2.
Можно поставить 8.0 рядом с 8.1, зайти в XCode - Preferences - Locations и в Command Line Tools выбрать XCode 8.0.
После этого - перезапустить PAServer, в Delphi подтянуть новые SDK и обновить список устройств в TargetPlatforms для  симулятора

Вот-вот. Не раз говорил именно это, Но диванные эксперты знают лучше.

Господа, спасибо за участие в обсуждении!
 
Принимая во внимание кучу параметров, я "заморочился" на написание собственной клавиатуры. Проанализировав и продебажив кучу кода FMX, удалось подменить стандартную клавиатуру собственной.
 
На текущий момент концепт готов и работает, но обладает одним недостатком - из-за особенностей работы процедуры RegisterShowVKProc стандартный вызов клавиатуры теряется без возможности восстановления.
Посему - я буду реализовывать нужные мне виды + повторять стандартные Ru и Eng, возможно - с некоторыми изменениями.
 
Концепт предназначен для работы только под iOS.
 
Использование: подключаете к проекту модуль из архива... и всё. Кастомная клавиатура теперь будет показываться вместо стандартной во всех контролах, в которых вообще показывается клавиатура.
 
Известные недостатки:
1. Нет анимации появления/скрытия.
2. Не реализовано нажатие кнопки Return (пока не думал, как это делается)
3. Не реагирует на флаги TVirtualKeyboardStates
4. Не уверен в корректном удалении фрейма при завершении приложения.
5. Нет тулбара (не уверен, правда, что он нужен в собственной клавиатуре)
 
Если необходимо - готов дать пояснения по коду.
Ввиду того, что я только начинаю работать с FMX, любая критика приветствуется!
iOSCustomKeyboard.zip

Не буду разводить холивар, тем более что with или не with имеет кучу обсуждений, в которых высказывались и именитые разработчики. Скажем так - использование with делает код не явным  (например - в классе, где используется эта конструкция с with тоже есть метод SaveToFile или свойство Text) и плохо читается сторонним разработчиком. Но - каждый решает для себя.

И это будет гораздо более правильно. не используйте with!

Не буду разводить холивар, тем более что with или не with имеет кучу обсуждений, в которых высказывались и именитые разработчики. Скажем так - использование with делает код не явным  (например - в классе, где используется эта конструкция с with тоже есть метод SaveToFile или свойство Text) и плохо читается сторонним разработчиком. Но - каждый решает для себя.

Не буду разводить холивар, тем более что with или не with имеет кучу обсуждений, в которых высказывались и именитые разработчики. Скажем так - использование with делает код не явным  (например - в классе, где используется эта конструкция с with тоже есть метод SaveToFile или свойство Text) и плохо читается сторонним разработчиком. Но - каждый решает для себя.