AngryOwl

По поводу Sony - я уже писал, и не раз (просто у меня несколько таких девайсов было).

И по моему опыту - это касается не только Sony.

На чем я вообще тестил (лично) свои программы: Sony (Xperia L, SP, Tablet Z), Huawei (G7, P7), Samsung (много), Highscreen (Zera S, Spider), Fly (tornado slim octa)... Всех не упомнишь...

И пришел к однозначному выводу - не использовать градиенты ни каким образом. Намного проще и быстрее (в работе) - готовые изображения (png).

Это же касается и TCircle. И, например, - прямоугольник с "закругленными" углами. Можно и без них обходиться, и при этом все будет более "гладким" и без багов.

2 часа назад, POV сказал:

С мая FMX не пользую по ряду причин, может чего изменилось.

Вы знаете...

На самом деле, за последний год изменилось очень многое.

Я искренне рад за компанию Embarcadero, и, конечно, за сам продукт RAD Studio. Им есть над чем работать, возможно не хватает ресурсов и т.д. и т.п... Однако на все сложности, думаю, у них очень большие перспективы. Серьезно! На мой взгляд, на сегодняшний день, аналога RAD Studio просто не существует! Его просто нет! Ну вот хоть убейтесь - нет его! И это далеко не только мое мнение. Мнение очень многих серьезных программистов, которые используют и другие IDE и, тем-более, языки (и которые работают в очень серьезных компаниях). И "всепропальщиков" я слышу со времен моей работы с Turbo-Pascal 5.0... )

Недостатки есть у всех! Можно так охаять любую IDE и любой язык, - что мало не покажется. Это касается "любого" (я о всяких студиях... и мелкомягких и корпорацияхдобра)... Вопрос больше в ресурсах, которые есть у компании, чтобы оперативно решать проблемы: баги, обновления, документация, поддержка и т.д...

А если говорить непосредственно о FMX, то вообще - все остальные тупо в пролете!

И мы говорим о продукте компании, которая катастрофически уступает своими возможностями и ресурсами таким монстрам как Microsoft с их Visual Studio.

Сейчас уже все больше и больше и документации и информации и ресурсов по FMX, в частности. Это и китайские ресурсы, и японские и немецкие. Не думайте - что только в постсоветском пространстве популярен Delphi, в частности, и среда RAD Studio. Это не серьезно! )

Китай, Япония, Германия, Франция и т.д. и т.д.

Все больше и больше и открытых исходников и разнообразных ресурсов и компонентов. Тот же Boian Mitov - куча компонентов, уникальные инструменты. Большинство - с поддержкой, и под, FMX! (не реклама! ссылок не даю - сами найдете). Уникальный болгарский (если мне память не изменяет) программист - написал и развил огромную библиотеку... И таких как он - много.

К чему я все это... А к тому - что изменилось столько всего! что даже не уверен, что об этом вообще надо говорить. А уж я то за ней следил еще со времен библиотеки VG-Scene (Евгения Крюкова) и далее - с самой первой XE...

А уж текущий ресурс - считаю один из лучших. Главное - уметь пользоваться!

И я полностью согласен с [Kitty] и поддерживаю - благодарю ребят за то, что они создали и ведут этот ресурс!

[janovskis] "а если текст состоит из нескольких кусков каждый из которых должен бытъ переведен отдельно?"

ну так просто создайте в файлах перевода строки (типа):

в lang.ru

1000=Страна:

1001=Россия

1002=Англия

в lang.en

1000=Country:

1001=Russia

1002=England

а в программе пишите (допустим компонент на который надо вывести надпись label1 = TLabel):

label1 := Format('%s %s', [GetValue(1000, 'Страна:'), GetValue(1001, 'Россия')]); // ну или другой код страны ...

// ну можно чуть проще)) label1 := Format('%s %s', [GetValue(1000), GetValue(1001)]);

и все...

З.Ы. и никакой "четкой привязки"... любые тексты, выводить можно куда угодно и как угодно...

В первом случае посмотрите, чтобы "кликабильные" компоненты располагались на компоненте, имеющем свойства HitTest = True.

А во втором случае (о высоте). Тут, мне кажется, - это высота по дефолту!

Копать в этом направлении:

unit FMX.Edit;

function TCustomEdit.GetDefaultSize: TSizeF;
var
  DefMetricsSrv: IFMXDefaultMetricsService;
begin
  if SupportsPlatformService(IFMXDefaultMetricsService, IInterface(DefMetricsSrv)) and DefMetricsSrv.SupportsDefaultSize(TComponentKind.Edit) then
    Result := TSizeF.Create(DefMetricsSrv.GetDefaultSize(TComponentKind.Edit).Width, DefMetricsSrv.GetDefaultSize(TComponentKind.Edit).Height)
  else
    Result := TSizeF.Create(100, 22);
end;

Хотя, терзают меня смутные сомнения, что это где-то в стилях "собака зарыта"...

И ведь главное - делал как-то! Но, блин, не помню уже как...

"новый язык добавить в ресурсы?" - из возможных? просто пропишите его аналогично в RC файлик (в демо-примере все есть)

Что касается всего, что является "не простым компонентом" или просто нужным текстом - переводите используя GetValue, которая использует перевод из файла, с соответствующим индексом.

5 минут назад, chaplin.u@gmail.com сказал:

в книжке "Д. Л. Осипов. - Delphi. Программирование для Windows, OS X, iOS и Android (Профессиональное программирование) - 2014" есть глава про TLang.

 

Есть. И?

Вы пользовались TLang? Полноценно, или так... "поиграться"?

Не хочу обидеть эмбаркадеро, - но это самый бестолковый и самый косячный компонент...

А в чем проблема?

Создайте свое TPopupMenu и привяжите его к свойству PopupMenu у TEdit...

3 часа назад, Rusland сказал:

Готовый пример можно? )

С удовольствием бы, но уж очень все подвязано на рабочий проект, а вырезать фрагменты - не получится быстро.

Если будет достаточно свободного времени - постараюсь оформить как-нибудь.

Смотрите форум un4seen.

RTC

Есть библиотека BASS, которая умеет все вышеперечисленное. И захват с микрофона в потоке, и определение уровня громкости и много чего еще.

Кроме того, в реальных условиях работы в сети Интернет, при передаче через UDP, не забывайте о максимальном размере пакетов (размер MTU в байтах) - обычно он 1450-1500, но я бы рекомендовал использовать значение 1400 (по личному опыту). Иначе вы будете слышать именно те "щелчки", вместо нормального звука. Т.е. - нужно определить размер буфера принимаемого с микрофона, разбивать его на фрагменты, и отправлять так, чтобы на принимающей стороне собрать в нужной последовательности, а далее - воспроизвести.

Проверить - попадает ли в OnClose и OnDestroy приложение при попытке убить процесс, думаю, не сложно. Можно просто тост в них воткнуть.

2 минуты назад, Alex7wrt сказал:

То есть в теле процедуры TForm.OnFormClose нужно разместить процедуру KillMe из данного модуля?

Да

2 часа назад, kami сказал:

Думаю, причина проще и сложнее одновременно. Просто что-то портит память.

Легко

Может быть из-за того, что в настройках стоит ограничение на количество "фоновых" программ. Т.е. посмотрите в настройках (возможно настройки для Разработчика), либо - в настройках приложений "разрешить работу приложения в фоновом режиме" (или типа того - у всех по разному)

З.Ы. И не верьте всему - что показывает оболочка по поводу того - сколько "свободного ОЗУ" ))

27 минут назад, Alex7wrt сказал:

А у Вас всегда нормально стартуют с первого раза? И, если не секрет, как Вы организовывали kilprocess? 

Да, всегда. Пока не замечал подобного бага.

И по поводу kill - модуль прикрепил.

android.KillMainProcess.zip

P.S.  Кстати, версии Android на которых проверял (с 4.0.2 по 6), а устройства - не очень много, но "разношерстные": Sony, Huawei, Samsung, Fly и т.д....

Вы не замечали - эти 10% случаев не попадают ли на "вторые" запуски приложения?
В смысле - если вы запускаете приложение впервые - оно однозначно запускается, а если в последующие разы - не всегда? (это пример из личного опыта)

Если именно так и происходит - то рекомендую "убивать" приложение при выходе. Т.е. сделать все как положено, кроме последнего Close. А вместо него - killprocess. Мне это помогло. По крайней мере в своем приложении не наблюдаю такого эффекта (ни на одном девайсе)

11 минут назад, ZuBy сказал:

это перебор кажется, оно запускается в главном потоке

Перебор в чем? В запуске в отдельном потоке?

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

Что касаемо присвоению свойству визуального компонента значений, возвращаемых тех или иных диалогов, то лучше создать переменную, присвоить ей возвращаемое значение диалога, а затем другому визуальному компоненту присвоить значение этой переменной.

Я на такие грабли наступал уже... И не поймешь - почему падает.

Вы визуальному компоненту (EditPath) присваиваете значение, которое возвращает диалог.

Думаю, стоит сделать так, чтобы значение Text компонента изменялось в основном потоке (синхронизировать).

Можно вызов диалога делать в отдельном потоке, чтобы не тормозить всю программу (я так и делаю обычно), но вывод в GUI обязательно с синхронизацией главного потока.

Установить PAServer на удаленной машине (ПК/планшет) и все.

Как сделать тут и тут. И вообще много в сети примеров, в том числе и на этом форуме где-то было.

Как один из вариантов решения подобных проблем - как можно меньше создавать/размещать на "двигающихся" элементах различных компонент.

Чем меньше компонент - тем меньше "перерисовок". Отсюда - какие именно компоненты, тоже играет роль. Если это TLabel или TPanel, или другие несложные компоненты, то это "простые" элементы. Соответственно их перерисовка не сложна. Если это элементы посложнее, типа TListBox, в котором у всех его TListBoxItem определены свойства Text, Detail и, возможно, другие, типа вставлены еще и картинки и т.д., то это будет уже "весомый" элемент.

Что еще важно - какой стиль вы применили к тому или иному компоненту. Если у вас простой TPanel имеет сложный стиль, переопределенный вами, то и его "прорисовка", соответственно, будет дольше происходить.

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

Ну есть еще вариант... Он будет, относительно, "мудреней"... Все зависит от вашего желания)

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

Думаю, Вам в помощь библиотека BASS.

Качестве примера использования самой библиотеки, рекомендую посмотреть пример, написанный ZuBy.

"у меня на гитхабе лежит пример работы с BASS, она же используется в этом приложении" (c) ZuBy

Поздравляю!

Желаю здоровья, успехов в работе, счастья в личной жизни!

Так держать!

По поводу тормозов.

Если у вас простое приложение - возможно вы и не заметите ничего.

Если приложение достаточно активно работает с GUI, или не дай Бог с видео, - "пиши пропало" .

Я на своем убедился на 100%. Большие и сложные списки, видео, и т.д. - и все...

Так-что это альтернатива только для таких случаев, когда ну уже никак не обойтись, даже жертвуя скоростью работы GUI.

2 минуты назад, ZuBy сказал:

GlobalGDIPlusEnabled := true или как то так, Делфи под рукой нет

Можно.

Можно и GlobalUseDXInDX9Mode := True; прописать

Проблема в другом! Это будет работать везде, так как это требуется прописать ДО инициализации приложения. Вообще ДО всего!

Т.е. это условие сработает для всех платформ Windows.

И тогда граблей будет намного больше, не говоря уже о тормозах приложения.

Вообще это далеко не единственная проблема с Vista.

У меня ряд других проблем возникало с ней.

Но в итоге я просто решил отказаться от поддержки Висты. По крайней мере - не уделять ей особого внимания.

Если посмотреть на инфографику, то процент ее использования крайне низок. И исчисляется единицами (это и по личному опыту). Думаю - это больше проблемы этих пользователей, чем софта. Многие разработчики ПО аналогично - не уделяют ее поддержке особого внимания.

Понимаю - что это не выход из положения...

Будем и с ней разбираться, по мере возможности...