Перейти к содержанию
Fire Monkey от А до Я

AngryOwl

Пользователи
  • Постов

    394
  • Зарегистрирован

  • Посещение

  • Победитель дней

    45

Весь контент AngryOwl

  1. По поводу Sony - я уже писал, и не раз (просто у меня несколько таких девайсов было). И по моему опыту - это касается не только Sony. На чем я вообще тестил (лично) свои программы: Sony (Xperia L, SP, Tablet Z), Huawei (G7, P7), Samsung (много), Highscreen (Zera S, Spider), Fly (tornado slim octa)... Всех не упомнишь... И пришел к однозначному выводу - не использовать градиенты ни каким образом. Намного проще и быстрее (в работе) - готовые изображения (png). Это же касается и TCircle. И, например, - прямоугольник с "закругленными" углами. Можно и без них обходиться, и при этом все будет более "гладким" и без багов.
  2. Вы знаете... На самом деле, за последний год изменилось очень многое. Я искренне рад за компанию 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] и поддерживаю - благодарю ребят за то, что они создали и ведут этот ресурс!
  3. [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)]); и все... З.Ы. и никакой "четкой привязки"... любые тексты, выводить можно куда угодно и как угодно...
  4. В первом случае посмотрите, чтобы "кликабильные" компоненты располагались на компоненте, имеющем свойства 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; Хотя, терзают меня смутные сомнения, что это где-то в стилях "собака зарыта"... И ведь главное - делал как-то! Но, блин, не помню уже как...
  5. "новый язык добавить в ресурсы?" - из возможных? просто пропишите его аналогично в RC файлик (в демо-примере все есть) Что касается всего, что является "не простым компонентом" или просто нужным текстом - переводите используя GetValue, которая использует перевод из файла, с соответствующим индексом.
  6. Есть. И? Вы пользовались TLang? Полноценно, или так... "поиграться"? Не хочу обидеть эмбаркадеро, - но это самый бестолковый и самый косячный компонент...
  7. А в чем проблема? Создайте свое TPopupMenu и привяжите его к свойству PopupMenu у TEdit...
  8. С удовольствием бы, но уж очень все подвязано на рабочий проект, а вырезать фрагменты - не получится быстро. Если будет достаточно свободного времени - постараюсь оформить как-нибудь. Смотрите форум un4seen.
  9. Есть библиотека BASS, которая умеет все вышеперечисленное. И захват с микрофона в потоке, и определение уровня громкости и много чего еще. Кроме того, в реальных условиях работы в сети Интернет, при передаче через UDP, не забывайте о максимальном размере пакетов (размер MTU в байтах) - обычно он 1450-1500, но я бы рекомендовал использовать значение 1400 (по личному опыту). Иначе вы будете слышать именно те "щелчки", вместо нормального звука. Т.е. - нужно определить размер буфера принимаемого с микрофона, разбивать его на фрагменты, и отправлять так, чтобы на принимающей стороне собрать в нужной последовательности, а далее - воспроизвести.
  10. Проверить - попадает ли в OnClose и OnDestroy приложение при попытке убить процесс, думаю, не сложно. Можно просто тост в них воткнуть.
  11. Может быть из-за того, что в настройках стоит ограничение на количество "фоновых" программ. Т.е. посмотрите в настройках (возможно настройки для Разработчика), либо - в настройках приложений "разрешить работу приложения в фоновом режиме" (или типа того - у всех по разному) З.Ы. И не верьте всему - что показывает оболочка по поводу того - сколько "свободного ОЗУ" ))
  12. Да, всегда. Пока не замечал подобного бага. И по поводу kill - модуль прикрепил. android.KillMainProcess.zip P.S. Кстати, версии Android на которых проверял (с 4.0.2 по 6), а устройства - не очень много, но "разношерстные": Sony, Huawei, Samsung, Fly и т.д....
  13. Вы не замечали - эти 10% случаев не попадают ли на "вторые" запуски приложения? В смысле - если вы запускаете приложение впервые - оно однозначно запускается, а если в последующие разы - не всегда? (это пример из личного опыта) Если именно так и происходит - то рекомендую "убивать" приложение при выходе. Т.е. сделать все как положено, кроме последнего Close. А вместо него - killprocess. Мне это помогло. По крайней мере в своем приложении не наблюдаю такого эффекта (ни на одном девайсе)
  14. Перебор в чем? В запуске в отдельном потоке? Ну если открыть диалог, то основное приложение приостановит свою работу - для многих приложений это критично. Что касаемо присвоению свойству визуального компонента значений, возвращаемых тех или иных диалогов, то лучше создать переменную, присвоить ей возвращаемое значение диалога, а затем другому визуальному компоненту присвоить значение этой переменной. Я на такие грабли наступал уже... И не поймешь - почему падает.
  15. Вы визуальному компоненту (EditPath) присваиваете значение, которое возвращает диалог. Думаю, стоит сделать так, чтобы значение Text компонента изменялось в основном потоке (синхронизировать). Можно вызов диалога делать в отдельном потоке, чтобы не тормозить всю программу (я так и делаю обычно), но вывод в GUI обязательно с синхронизацией главного потока.
  16. Установить PAServer на удаленной машине (ПК/планшет) и все. Как сделать тут и тут. И вообще много в сети примеров, в том числе и на этом форуме где-то было.
  17. Как один из вариантов решения подобных проблем - как можно меньше создавать/размещать на "двигающихся" элементах различных компонент. Чем меньше компонент - тем меньше "перерисовок". Отсюда - какие именно компоненты, тоже играет роль. Если это TLabel или TPanel, или другие несложные компоненты, то это "простые" элементы. Соответственно их перерисовка не сложна. Если это элементы посложнее, типа TListBox, в котором у всех его TListBoxItem определены свойства Text, Detail и, возможно, другие, типа вставлены еще и картинки и т.д., то это будет уже "весомый" элемент. Что еще важно - какой стиль вы применили к тому или иному компоненту. Если у вас простой TPanel имеет сложный стиль, переопределенный вами, то и его "прорисовка", соответственно, будет дольше происходить. Не забывайте о том, что можно сделать предварительную загрузку стиля. Это сильно уменьшит время первого отображения вашего элемента. Ну есть еще вариант... Он будет, относительно, "мудреней"... Все зависит от вашего желания) Пример, насколько я помню, можно посмотреть тут. Суть заключается в том, что можно сделать скрин вашего элемента (панели) и работать с ним (показывая его в момент анимации и отключая поле выполненной анимации). Подобных примеров достаточно, в том числе на сайте Embarcadero.
  18. Думаю, Вам в помощь библиотека BASS. Качестве примера использования самой библиотеки, рекомендую посмотреть пример, написанный ZuBy. "у меня на гитхабе лежит пример работы с BASS, она же используется в этом приложении" (c) ZuBy
  19. Поздравляю! Желаю здоровья, успехов в работе, счастья в личной жизни! Так держать!
  20. По поводу тормозов. Если у вас простое приложение - возможно вы и не заметите ничего. Если приложение достаточно активно работает с GUI, или не дай Бог с видео, - "пиши пропало" . Я на своем убедился на 100%. Большие и сложные списки, видео, и т.д. - и все... Так-что это альтернатива только для таких случаев, когда ну уже никак не обойтись, даже жертвуя скоростью работы GUI.
  21. Можно. Можно и GlobalUseDXInDX9Mode := True; прописать Проблема в другом! Это будет работать везде, так как это требуется прописать ДО инициализации приложения. Вообще ДО всего! Т.е. это условие сработает для всех платформ Windows. И тогда граблей будет намного больше, не говоря уже о тормозах приложения.
  22. Вообще это далеко не единственная проблема с Vista. У меня ряд других проблем возникало с ней. Но в итоге я просто решил отказаться от поддержки Висты. По крайней мере - не уделять ей особого внимания. Если посмотреть на инфографику, то процент ее использования крайне низок. И исчисляется единицами (это и по личному опыту). Думаю - это больше проблемы этих пользователей, чем софта. Многие разработчики ПО аналогично - не уделяют ее поддержке особого внимания. Понимаю - что это не выход из положения... Будем и с ней разбираться, по мере возможности...
×
×
  • Создать...