Равиль Зарипов (ZuBy)

не хорошо так выражаться, можно и бан получить
то что у тебя 100 форм это твоя проблема то что тебе лень прописать одну строчку в создании одного типа компонентов, то думаю что там говно-код и если бы ты понял, что я предлагаю, ты бы уже давно реализовал, а не писал на форуме "остроумный" пост, в коде добавляется только одна строчка и это не ApplyFontToForm (если там не говно-код) я бы предложил еще один кардинальный вариант, но не буду

"я не хочу думать! я хочу кнопку, нажимаешь и все работает"
как я вижу эту реализацию:
делается отдельный модуль, в который перемещается код
procedure ChangeFont(const aControl: TControl; const aFontName: string); const StyledSett = [TStyledSetting.Size, TStyledSetting.Style, TStyledSetting.FontColor]; var aTextSettings: ITextSettings; I: Integer; begin if aControl is TListView then begin (aControl as TListView).ItemAppearanceObjects.ItemObjects.Text.Font.Family := aFontName; (aControl as TListView).ItemAppearanceObjects.ItemObjects.Detail.Font.Family := aFontName; end else begin if Supports(aControl, ITextSettings, aTextSettings) then begin aTextSettings.StyledSettings := StyledSett; aTextSettings.TextSettings.Font.Family := aFontName; end; for I := 0 to aControl.ControlsCount - 1 do ChangeFont(aControl.Controls[I], aFontName); end; end; .................................................. procedure ApplyFontToForm(const aForm: TForm; const aFontName: string;); var I: Integer; begin for I := 0 to aForm.ComponentCount - 1 do begin if aForm.Components[I] is TControl then ChangeFont(aForm.Components[I] as TControl, aFontName); end; end; прописываем ChangeFont и ApplyFontToForm до implementation
и в форме после создания дин. компонентов и/или в OnShow пишем ApplyFontToForm(Form30, 'Roboto');
даже незнаю как можно сделать проще

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

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

Delphi умеет наследование форм.
Делаете основную форму с общим поведением для всех форм и все формы проекта наследуете от этой формы.
 

Эх, попкорн закончился) Доброго вечера всем.
Вот вы тут развели ср..., прям диву даешься. Неужели тут кто то всерьез верит, что Rad Studio похоронят - вы чего? СМена кадровой политики - абсолютно нормальное явление в любой организации, которая не сидит на месте. Другой вопрос - что послужило толчком? Но не суть. Тут прочитал - вот мол никто на FMX не пишет - вы судите по тому, сколько информации (удивленный смайл). Неужто кто то всерьез думает, что солидные компании, которые базируются на Rad Studio, будет трубить на каждом углу - смотрите, у нас софт написан на Rad Studio? (если быть точным, то с использованием, не придирайтесь)) ЗАЧЕМ оно им?
С такой ценовой политикой, достаточно нескольких сотен пользователей для безбедной жизни, хотя думаю их в разы больше.
А вот про баги и тд - улыбнуло. Есть у меня опыт небольшой работы и с FMX под ANdroid, и куда больший по десктоп, естественно под VCL. Есть опыт с плюсами и шарпом на Visual Studio тоже под десктоп. Ну и Qt немного. И судя по своему скромному опыту, еще вопрос - где больше багов, когда начинаешь копать глубже. Тута вон галку снял, и софт с 99% уверенностью запустится у всех, а Visual Studio - без опыта, один процесс настройки зависимостей проекта в новых версиях - тот еще гемморой. А потом начинаешь пользователям долбить - скачайте рантайм, а вот еще ддлку эту, а у вас версия Фреймворка не та))) Адекватно собрать статически слинкованный Qt мне так и не удалось, точнее удалось под MinGW - не впечатлило.
Похоже многие забыли - FMX, Rad, Visual, pascal,  c++, c#, и тд, и тп - это только инструмент, все зависит от того, кто его держит. 
Kitty - мне очень интересно - отчего такая потребность - закопают или нет? А кто мешает перебраться, в случае необходимости в другую среду - знания то лишними не будут. Напоминает покупку первой машины - месяцами выбирают (количество критериев зашкаливает - и чтоб то не сломалось, и не устарело, и тд), в итоге покупается что то непотребное, просто из-за подхода, при этом количество нервов потраченных...) вы же не на всю жизнь покупаете) Так и тут - ну случится беда, закопают - так правильно сказали: может через пару лет и Андроид гавкнет - что теперь не писать под него.
В крайнем случае можно на время перебирания в другую среду остаться на старой версии. Хотя, вынужден извиниться, возможно у вас действительно вперед смотрящие, долгосрочные проекты, тогда стоит думать сейчас (ни в коем случае не сарказм). Но положа руку на сердце, поверьте - выбор то не велик, к сожалению, когда дело доходит до чего - то большего, чем Hello World.
 
P.S. не первый год пытаюсь переползти в Visual Studio - именно написание кода там куда более комфортное, но увы - так и не смог) сошелся на Dll-ках, из Visual Studio, и основе в Rad Studio - довольно удобно и комфортно.

ребята ну вы чего?
http://docwiki.embarcadero.com/RADStudio/Berlin/en/Running_Your_iOS_Application_on_the_iOS_Simulator
 

Вот патч от @Brovin Yaroslav 
iOSapi.CoreTelephony.pas.patch.zip
 

Вот патч от @Brovin Yaroslav 
iOSapi.CoreTelephony.pas.patch.zip
 

Вот патч от @Brovin Yaroslav 
iOSapi.CoreTelephony.pas.patch.zip
 

Как уж так с Api Yandex разобрались, а с TMapView нет?
TMapsEngine точно смотрели?

Решил так:
procedure TForm1.FormKeyUp(Sender: TObject; var Key: Word; var KeyChar: Char; Shift: TShiftState); begin if Key = vkMenu then ... end;  

Toast message.Можно пользоваться с помощью библиотеки FGX - TfgToast

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

Вот из майки, в смысле Maya файл (первый попавшийся) .obj. Даже текстурку подхватило по умолчанию. НО навигация во вьюпорте - нет слов, одни эмоции Хотя, возможно я чего то не понял. Текстурка .tif - тут еще разбираться нужно, мне не охота, скорее всего далеко не все расширения прокатят.
Это и есть ответ на ваш вопрос - в 90% случаев .obj хватит за глаза, а его поддерживают при экспорте все адекватные редакторы)

Тут еще совет дали: Возможно пакет йос симулятора отключился. надо лезть в настройки реестра. И проверить, что нужные пакеты включены. Названия не помню, но точно в названии были слова ios simulator

@Brovin Yaroslav, [11.01.17 15:42]
Возможно пакет йос симулятора отключился
@Brovin Yaroslav, [11.01.17 15:42]
надо лезть в настройки реестра
@Brovin Yaroslav, [11.01.17 15:42]
И проверить, что нужные пакеты включены.
@Brovin Yaroslav, [11.01.17 15:42]
Я названия не помню
@Brovin Yaroslav, [11.01.17 15:43]
но точно в названии были слова ios simulator

Возможно, я рискую задать глупый вопрос, но что плохого в том, что Embarcadero переходит на аутсорсинг и переносит разработку из Испании и России в Украину? Оптимизация издержек. Главные архитекторы вроде Марко Канту остаются же, не?
ИМХО, продукт будет жить и развиваться (за счет продаж корпоративным клиентам).
TMS вон наклепали кучу компонентов для FMX. Если бы это было невыгодно, они бы не выпускали заплатки каждую неделю.
Delphi хоронят с 2000-х годов, а курилка жив еще.
Есть ли еще среды программирования, которые компилят программы под четыре разные операционки?

ну так... пользуйтесь на здоровье! она бесплатная, XML разметка есть, столь полюбившая Вам... не вижу ни каких препятствий!
нам то доказать, что хотите? не использовать RAD? так это у меня основная статья дохода от разработки на RAD!
Вот на Android Studio нет! А RAD приносит деньги! может просто не повезло?

В любом случае ваше желание я вас понимаю :-)
Поскольку рынок на делфи складывается в основном из старых проектов, то желания перенести старое на новое больше, чем написать это же с нуля. Была в свое время попытка сделать мида конвертер. Он, вроде, как умел базовые вещи делать: переименовывать свойства и тд. Но как-то новости о нём потихоньку затихли. Видимо, из-за  того, что после его работы нужно все равно потратить время на перевод кода.
На счет FMX я скажу так. Что мне лично не хватает в FMX тех минимальных вещей, которые в VCL работали хорошо: четкая графика на всех платформах, нормальный ввод текста, базовые настройки компонентов и скорости работы. Причем половина банально решается протягиванием или открытием скрытых свойств, что для меня тоже загадка (почему они скрыты).

Механизм будет работать. Это основа делфи, а не VCL. В VCL просто ее использовали, чтобы облегчить жизнь с доставкой сообщений. На текущий момент FMX использует мессаджи в презентационных контролах. Именно через ключевое сообщение message.
И этот вариант не то же самое, что TObject.Dispatch. Да, это скорее центр уведомлений.
Грид не плох на планшетах, но для своих задач. Но на мобильных телефонах много вы видели гридов? Да и грид переделали в последних версиях. Он по крайней мере стал на что-то похож. Про LiveBinding молчу, так как это вещь сама в себе. Вроде, как всех к ней привязали, как к новомодной фишки. Но по факту с ней возиться намного больше, чем с DataSource компонентами. Я уж  не говорю о скорости работы.
Вот это правильное замечание. Есть идеалогия мобильного приложения и она практически ничего не имеет общего с настольными ОС, кроме кнопок, конечно, и полей ввода  С другой стороны есть люди, которым мобильность не особо нужна. У них есть большие проекты на VCL и они в принципе были бы рады перевести на FMX, но если это просто взять и двумя кликами поменял. О чем @Haword и говорит. Это хорошее желание. Но никакой нормальный большой проект на VCL просто так не перевести на мобилки, какое бы соответствие не было на уровне АПИ компонентов. 
Когда появились первые КПК было очень модно похвастаться, что у тебя есть DOS на кпк. Можно было поставить Turbo Pascal или вообще запустить обрезанную винду. Классно, но только дальше этого реально
Хорошее замечание. Большинство библиотек косвенно или напрямую использует либо WinApi либо Dll. И такие библиотеки не взлетят на других платформах ну никак. 
Опять же повторюсь, что идея совместимости хорошая. Но на практике, даже, если бы она и была на уровне FMX, то она хорошо подходила бы для маленьких проектов. В то время, как для больших, она была бы почти бесполезна. Но при это эта совместимость потребовала бы своих костылей. Поверьте мне  

Кто-то ждет что делфи "оживет", а кто-то пишет на ней и радуется жизни. 

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

// uses FMX.Platform, FMX.PhoneDialer function DialerSupport: boolean; var FPhoneDialerService: IFMXPhoneDialerService; begin Result := false; if TPlatformServices.Current.SupportsPlatformService(IFMXPhoneDialerService, FPhoneDialerService) then Result := true; end;  

// uses FMX.Platform, FMX.PhoneDialer function DialerSupport: boolean; var FPhoneDialerService: IFMXPhoneDialerService; begin Result := false; if TPlatformServices.Current.SupportsPlatformService(IFMXPhoneDialerService, FPhoneDialerService) then Result := true; end;