Ghk

я бы кинул на форму лэйаут и на него уже накидывал бы все компоненты. Затем при старте формы - крутим этот лэйаут на 90 градусов и смещаем на ширину экрана. При реальном повороте устройства - крутим и смещаем обратно. Получилось бы всегда одна и та же ориентация - альбомная, не зависимо от реального положения устройства.

Накидайте просто пример - рисование линии в одну сторону и в другую по таймеру - ничего никуда не залипает и не зависает. Repaint по таймеру вызывается ? Вы бы код приложили ...

Да почти для любого "графического" компонента есть эти методы Откройте справку на Paintbox раздел методов - там есть описание обоих . Работаем на билдере так myPainbox->BeginUpdate(); //... тут код чо мы там рисуем - кривые . косые . графики окружности и прочие мегауравнения myPainbox->EndUpdate(); myPainbox->Repaint();// выводим на экран все что накалякали в буфере Оно и будет идти неравномерно ибо вашему приложению система не обязана давать 100% процессорного времени

Вопрос вот в чем. В портретной ориентации напихано дофига контролов и все красиво. Поворачиваю смартфон , и конечно же теперь большая часть контролов спряталась. воткнул вертикальный скролл под них , но не удобно . Мысля пришла перекомпоновать контролы под андройд - оказалось нифига! Иерархия должна остаться той же . Тогда появилась другая идея - налепить копий контролов как удобно именно в альбомной ориентации. налепил - они видны и в портретной. Если отключаю видимость отключаются в обоих ориентациях Отсюда вопросы: 1) Верно ли я понимаю, что в редакторе форм под андроид - ориентация , просто сделана чтоб посмотреть , как оно будет выглядеть. И нельзя сделать портретную-один вид , а альбомную -другой, именно используя визуальный редактор? 2) Разумно ли налепить копий контролов для удобства , которые видно в одной ориентации и не видно в другой , и включать/отключать их видимость по событию формы OnResize( вроде как можно определить смену ориентации) ? если мои предположения не верны , просветите плиз , как вообще это правильно и разумно сделать ?

Свой обработчик приема пишется с секундамерами и т.п. по другому никак ...

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

Интересно было обезьяну попробовать

Вообще-то тестирует как оно работает .... на XE8 тоже куча глюков было обнаружено , но костылями вылечено , но такое выпускать в свет явно нельзя , поэтому терь попытка 10.2.2 Если Здесь такая же ерунда , то я под андрюшу в андроидстудии лучше ваять буду - модель на плюсах , представление на джаве Ну я сужу по скачанным релизам и дате их создания - все очень и очень глюкавое. Под винду -хорошо , но под андроид - тихий ужас.

ну хорошо пусть 1.5k$ . Мне после покупки год-два ждать пока допилят и можно будет пользоваться или как ?

Итак отписываюсь о результатах: Все глюки связаны со средой RAD xe10.2 Tokyo Код и прочее абсолютно не причем. Все снес, выкачал другую версию 10.2.2 с хотфиксом Под андроид все скомпилилось и установилось без ошибок , отладка работает. Хорошо - допустим купил я лицензию на 10.2 и получил бы кучу вот таких вот глюков и узнал бы потом что билдер выпускают официально сырой и недопиленный, а пилят в процессе ( хорошо хоть на стековерфлоу написали об этом ) -эт получается заплати я почти 6k$ и потом еще год-два жди пока они все глюки допилят и наконец-то можно будет работать ? Я логики не пойму ... п.с. запустилось sdk 25.2.5 ndk r9c сейчас проверю на более свежих NDK

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

Пришел писец ! Переустанавливаю ...

Под XE8 все прекрасно компилится и встает на устройство , работает стабильно. Я на плюсах ваяю и кажись на дельфи такой проблемы нет. Нашел аналогичные проблемы на стековерфлоу, только там у чувака вылет идет именно при закрытии приложения ( тоже на С++ проблема ). Абракадабра написала , что -то там было недореализовано и они исправят в обновлении. Сейчас качаю хотфикс с рутрекера, поглядим что получится. Причем забавно вот что - если ставлю одну версию NDK , то приложение даже не стартует - по отладчику не доходит даже до создания форм сразу вываливает эту ошибку. При использовании другой версии NDK свистопляски начинаются при присваивании указателей и т.п.

Отладка заработала , после создания нового проекта и добавления туда файлов и форм из старого проекта. Теперь другая беда - под вин 32 компилируется без ошибок , а вот под андроид(в зависимости от NDK) лезет Class segmentation fault error(11) на разных этапах запуска приложения.

До этого стояла XE8 и все прекрасно собиралось и дебажилось. На днях качнул xe10 tokyo с рутрекера. Приложение (из начально делалось в XE8) скомпилилсоь собралось, установилось , но отладка не работает ( конфигурация debug) Попробовал новое приложение - форма и кнопка, то же самое - отладка не работает. Т.е. XE10 устанавливает и запускает приложение на телефоне и на этом все - студия отключается от телефона. Устройство redmi2 adnroid 5.1.1 Чего делать и куда копать ? п.с. отладка под винду работает РЕШЕНО: Чтоб сэкономить ваше время и чтобы вы не читали всю тему, вот краткое руководство. Для перехода с XE8 Создаем новые проект- приложение в XE10 затем добавляем туда все формы и файлы из старого проекта ( я имею ввиду макеты форм, cpp , h, ico и более ничего не добавлять!). Из деплоймент менеджера удаляем задеполеные файлы и ставим все по умолчанию. Компилим -билдим. Затем в деплоймент менеджер добавляем чего там раньше было. И удаляем из проекта лишнюю новую форму ( она у нас создается при создании проекта) Все - можно пользоваться . Кроме того версия Токио должна быть 10.2.2. с хотфиксом от 2018 года, версии ниже с рутрекера глючат