kami

Project-Options-VersionInfo. что там в CFBundleIdentifier прописано для требуемого Target?

Работу с прибором сделать в потоке. Результаты поток через Queue отдает в основной поток. И уже в потоке - Sleep, это будет точнее чем таймер, который (к слову) на винде весьма не точен.

Он никуда не мог деться:

MyControl.Release; Это отложенное удаление, реализованное самой платформой. Надо только не забывать после Release заNil-ить ссылку на объект в массиве. Ну и вместо массива лучше использовать дженериковский список.

если уж до конца соблюдать стилистику магистра Йоды, то надо говорить примерно так: "в раздел интересующий зайти должен ты, сверху-справа кнопку нужную найдешь".

Писал как-то (кажется, не раз) в чате - нельзя ставить без оглядки последние SDK. К примеру, Berlin Upd2 вроде как работает с XCode 8.2 Приложение компилируется, запускается, вроде как работает. Но иногда вылетает. С рекомендованным XCode 8.0 проблема вылета наблюдается гораздо реже. В тестовых условиях, когда делается все что угодно. А в боевой эксплутации (пользователи все-таки не жмакают все подряд, в отличие от тестеров) - жалоб на вылеты не поступало

Так куда уж подробнее? 1. Ставим правильный XCode 2. Запускаем XCode, идем в меню (кажется) Tools - Preferences, лезем во вкладку Locations, выбираем в выпадающем списке CommandLineTools правильную версию. Применяем, все закрываем. 3. Запускаем PAServer (до этого он должен быть выключен). 4. Запускаем IDE, подтягиваем нужные SDK. Емнип, прямо при подтягивании можно выставить чекбокс Make Active. Если нет - после подтягивания на правильной SDK правой кнопкой и делаем активной.

Да. + подтянуть актуальные для версии XCode SDK и сделать их активными. И не забыть выставить правильный параметр в XCode - Preferences - Locations - CommandLineTools.

Да. К сожалению, не скажу где. Для Berlin требуется XCode 8.0. Не 8.1, не 8.хз. А именно 8.0

Я бы не стал доверять стандартному диспетчеру задач. Не знаю, что означает "пиковая память", но скорее всего - это максимальное значение памяти, которое процесс занимал в физической оперативке. Это совсем не соответствует тому, сколько процесс реально взял памяти у системы. 32 разрядному процессу доступно в теории 4Гб. На практике - больше 2Гб (а в подавляющем большинстве случаев - 1,5Гб) получить не удается. Пардон, а как работать дальше? На каждый чих, на почти каждую строчку кода требуется выделение памяти. Где ее взять, если она закончилась? Правильно процесс вылетает.

Вот вам наглядная причина, от которой открещиваются разработчики индейцев. Они пишут "создание потока на каждый чих - это нормально, в операционной системе толпы потоков, одним больше-одним меньше разницы нет". Представьте: 1500 потоков. Помимо того, что создание потока сама по себе затратная операция, на каждый из них выделяются системные ресурсы, в том числе - память. Каждый поток инициализирует свои данные, это еще память. По завершению обработки поток скорее всего не убьется сразу, а пройдет энное количество миллисекунд (чем загруженнее процессор - тем больше времени). Вот вам и постепенное накопление требуемой памяти. Скорее всего, в ProcessExplorer вы увидите, что ваш процесс "сожрал" гектара полтора в PrivateBytes. Собственно, об этом я раньше уже писал. В этой теме.

Выбрать целевую платформу Меню Project - Deployment Убедиться, что в списке файлов есть файл без расширения с именем проекта, у него стоит галочка и путь к этому файлу соответствует тому, что показано на скриншоте в теме вопроса Основные файлы - не нужно. Они помещаются сами. Обычно туда лезут, если нужно задеплоить что-то "левое", свое. И - ответьте на вопросы Vitaldj. Возможно, вы работаете не с тем XCode.

В деплоймент не всё что нужно попало? Посмотрите там.

А SDK к нему подтянуты? Одна из подтянутых сделана активной?

Мистика Отдельной опции "поставить симулятор" в менеджере платформ нет, скорее всего она идет в составе Delphi IOS (у меня установка через веб-инсталлер). Раз сама iOS платформа есть - значит, что-то тут не так. Может, студия криво встала?

К сожалению, кнопка "Жалоба" не работает, поэтому пишу прямо здесь: Господа модераторы, может хватит уже смотреть спустя рукава на непозволительный тон и оскорбительные высказывания от haword ? И вообще, коллеги - не кормите троллей. Человек для себя уже всё давно решил, а здесь просто пытается утвердить свое мнение. haword , идите на хабр. Там вас поддержат, они любят такие речи. Здесь не те, кто "колется, плачет, но продолжает жрать кактус", а люди несколько иного настроя.

System.IOUtils в uses поставить после модуля, в котором описан компонент TPath (делфи не под рукой, не скажу в каком конкретно).

Мда. Отлично поговорили. Поздравляю вас, вы пополнили ряды тех, кто при отсутствии нормальных аргументов выдает "Ой, всё!"

Нет реализации. Не вижу смысла продолжать спор в этом направлении, рекомендую почитать MSDN - как формируются и обрабатываются сообщения. В частности - про PostMessage, SendMessageTimeout и т.п. Где я сказал, что сделали хорошо? Давай ты не будешь приписывать мне результаты своих умозаключений? Он есть на мобильной платформе. Если ты собираешься идти в разрез с guidelines и плевать на удобство работы пользователя - пожалуйста, твое право, используй гриды. Много. Почти все. И далеко ходить не надо - IDE RAD Studio, MS Office, браузеры, бизнес-приложения, дизайн которых ориентирован на десктопы, и зачастую - на несколько десктопов. Да и проводником ты наверное ни разу в жизни не пользовался... Блин, вот кроме как иронизировать - ничего не остается. Вот возьмем любое финансовое приложение, коих очень много написано на VCL (все-таки легкость работы с БД подкупала очень многих). Портируй без изменений приложение, которое уже на старте выводит таблицу в 300 колонок и 10000 строк, и на каждое действие пользователя открывает еще одно окно с таким же количеством данных. Уже на третьей открытой форме смартфон скажет тебе "Уй!" и рубанет приложение по причине: а) оно не отвечает долгое время б) приложение захотело слишком много памяти. Поэтому с полпинка могли бы уйти только приложения уровня HelloWorld. Но их и с нуля написать проблем никаких нет. Любое коммерческое приложение, написанное на VCL, имеющее кучу сторонних компонентов, гигантское количество модулей, собственных библиотек (а как ты dll-ки будешь портировать и подключать на мобилах, где они в принципе не предусмотрены?) портированию просто не подлежит. Ни под каким соусом. Ах, да, забыл - особое удобство на телефонах тебе (и как пользователю, и как программисту) доставят риббоны. И тулбары. За сим я умолкаю. Не вижу смысла дальше спорить. Ты уперся в "вот если бы VCL была кроссплатформенной" и не хочешь слышать, что это нецелесообразно по целому ряду факторов. Давай так: FMX выросла из проекта ОДНОГО человека. Судя по тому, что ты пишешь - "закроссплатформить" VCL можно, было бы желание. Если я правильно понял - желание у тебя есть. Сделай, предложи Embarcadero, стань PM-ом у них и уже на официальном уровне продвигай свои идеи в массы, в общем - рули тем, куда пойдет и чем станет Delphi в будущем.

Да, смотрел. Более того - даже правил некоторые вещи. И что? TMessage в FMX - совсем не то, что WM_XXX Я хотел бы посмотреть, как ты реализуешь WM_PAINT собственными силами. На всякий случай - WM_PAINT имеют особенность складываться друг с другом, оставаясь в очереди в единственном экземпляре. А WM_TIMER - откладываться в конец очереди сообщений. Помимо этого - механизм получения сообщений, реализованный в VCL (на основе methodname(var MSG: TMessage); message WM_траляля;) на мобильных платформах просто не будет работать. А это - основа ВСЕГО VCL. Ага. Особенно не пришлось бы переписывать интерфейс. Очень удобно на мобильных платформах работать с таблицами. Ну и на телефоне несколько окон рядом показать тоже - раз плюнуть. Приложение в любом случае пришлось бы писать почти заново. Потому что программистов, которые в VCL проектах используют MVC можно пересчитать по пальцам. Остальные мешают в кучу бизнес-логику и интерфейс. Повторю вердикт - порт VCL на мобильных платформах не взлетел бы.

VCL чуть более чем полностью завязан на WinAPI и виндовый механизм обработки сообщений. Обеспечение совместимости вылилось бы в гораздо большее количество костылей, имеющиеся баги при их "исправлении" порождали бы новые в абсолютно "не связанных" областях , ну и прочие прелести "гибкого" решения не заставили бы себя ждать. Посему - создать абсолютно новый фреймворк было правильным и взвешенным решением.

я бы так не сказал. Это еще и вопрос самолюбия. Ярославу, наверное, интересно читать что тут за него нарешали, но все же озвучу свою мысль: далеко не каждый, которому сказали (мягко и корректно) "спасибо, в ваших услугах мы больше не нуждаемся", а потом "Аааа.... вернись, я всё прощу, хреннилион денег дам и личного повара" ответят "да, я вернусь" из-за прозвучавшего ранее "не нуждаемся". Это если смотреть со стороны разработчика - наемного работника. Со стороны компании же позвать обратно всех будет означать "да, мы крупно облажались и хотим вернуть всё взад". Даже если первая часть фразы (облажались) является правдой - далеко не каждый сможет признать подобное. Для того, чтобы эта фраза не имела больших последствий, нужно иметь сильные личностные качества.

непосредственно они, профессионально - нет, не будут. В качестве хобби - да, возможно. На встрече Ярослав рассказывал, что у него куча наработок, которые он хочет довести до ума. А "заниматься RAD" подразумевает, насколько я понимаю, вкладывать свой труд в ядро - в сами исходники Delphi. Я просто не представляю, как это может выглядеть - филиал расформирован, но пуллреквесты приветствуются? Скажем так - в ближайший год всё должно стать гораздо лучше, чем сейчас. И только ближе к концу наступившего года можно будет делать какие-то прогнозы и выводы. Я вот буду поглядывать, как быстро Embarcadero будет реагировать на новые версии iOS, а то Apple в последнее время штампует их как...(очень быстро штампует), и из-за этого появляются частичные несовместимости с новым xCode. Имхо, выпустить hotfix на минорную версию iOS не должно потребовать множество усилий. Увы - пока тишина...

так не получится. Ни своими силами, ни используя тетеринг. В случае разных подсетей как минимум будет нужен свой велосипед. А как максимум - полноценный сервер, выполняющий возложенные на него задачи, одна из которых - пробрасывать трафик от одного клиента к другому (при необходимости). Но в любом случае - клиенты коннектятся к серверу. Если мы говорим про сетевые технологии, то клиентский сокет может соединиться только с серверным. И тут два варианта: 1. либо они оба находятся в одной подсети, при этом порт для броадкаста открыт. 2. Либо у сервера выделенный статический белый IP или постоянный URL (в этом случае IP не обязан быть статическим, но вот белым быть обязан). Серверный сокет не соединяется ни с кем, он только принимает входящие подключения от клиентских сокетов. да.

В данном случае под сервером понимается серверный сокет с необходимыми обработчиками событий. Смотрите индейцев и выбирайте любой понравившийся. Но гораздо проще взять готовую технологию - AppTethering. С самостоятельной реализацией вы рискуете погрязнуть в энтомологоии, особенно - если возьмете минималистичный протокол (TCP/IP). Обратите внимание, что в любом случае устройства сконнектятся друг с другом только если они находятся в одной подсети.