Rusland

Как-то вы поступили очень грубо
В ваших целях достаточно было воспользоваться директивами препроцессора:
http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devcommon/compdirsmemoryallocsizes_xml.html
 
type TTh = class(TThread) protected procedure Execute; override; end; implementation procedure Do; var I: Integer; begin for I := 1 to 5000 do TTh.Create(False); end; { TTh } {$M 16384, 65535} procedure TTh.Execute; begin while True do Sleep(50); end;  

думаю эти два куска показывают основную обработку OnCommandGet,
из хедера:
typedef std::deque< strDBQueueMember* > db_queue_deque; db_queue_deque db_queue; TCriticalSection *cs_pool, *cs_queue, *cs_files; TInterlocked *Interlocked; 3600 это запрос без обращения к бд, только данные из пула с критическими секциями 
ну и вот это обязательно в System.Classes.pas  в Embarcadero\Studio\17.0\source\rtl\common\
constructor TThread.Create(CreateSuspended: Boolean); -//- {$IF Defined(MSWINDOWS)} //#define STACK_SIZE_PARAM_IS_A_RESERVATION 0x00010000 - это для информации //#define CREATE_SUSPENDED 0x00000004 - это для информации // заменить FHandle := BeginThread(nil, 0, @ThreadProc, Pointer(Self), CREATE_SUSPENDED, FThreadID); // на FHandle := BeginThread(nil, 65536, @ThreadProc, Pointer(Self), $00010004, FThreadID); System.Classes.pas добавить в проект.
и будет вам счастье 

uses FMX.Utils; procedure TForm7.Button1Click(Sender: TObject); var gamecanvas: TBitmap; i, j: integer; bitData: TBitmapData; p: PAlphaColorArray; begin gamecanvas := TBitmap.Create(256, 256); try if gamecanvas.Map(TMapAccess.ReadWrite, bitData) then begin for i := 0 to 255 do begin p := bitData.GetScanline(i); for j := 0 to 255 do p[j] := TAlphaColorF.Create(random(255) / 255, random(255) / 255, random(255) / 255, 1).ToAlphaColor; end; gamecanvas.Unmap(bitData); self.Canvas.BeginScene(); self.Canvas.DrawBitmap(gamecanvas, gamecanvas.BoundsF, RectF(0, 0, 256, 256), 1); self.Canvas.EndScene; end; finally gamecanvas.Free; end; end;  

временное решение
DblClick.zip

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

des80, с такой позицией помощи можно не ждать.
хамству тут не место

не хорошо так выражаться, можно и бан получить
то что у тебя 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');
даже незнаю как можно сделать проще

Добавьте, пожалуйста, в список подсветки синтаксиса кода пункт Pascal/Delphi. Вроде самая необходимая на данном форуме подсветка, а её до сих пор нет 
 
Спасибо!

Windows, FMX
Возможно не совсем в тему форума, вопрос по архитектуре серверных служб, хотелось бы услышать мнения.
Ситуация:
IdHTTTPServer на каждый запрос создает поток, в этом потоке не обойтись без обращения к пулу данных в памяти. Пул - несколько наборов актуальных данных. Наборы данных асинхронно получаются из БД, имеют связи многие ко многим, один ко многим и периодически кэшируются в память в основном потоке. Т.к. обращение к пулу из потока - соответственно пул должен быть потокозащищенным. После обработки запроса, данные также отправляются в  основном потоке в очередь БД.
1. Если весь пул закрыть в TCriticalSection - то на время использования его одним потоком все остальные будут ожидать. Обращение к очереди БД из потока получается также должно быть потокозащищенным. Не изящно.
2. Можно задачу обработки положить в некую потокозащищенную очередь и остановить поток c помощью TSimpleEvent->WaitFor( INFINITE ). Далее в основном потоке работать с пулом данных и очередью БД без критических сессий и, после получения результата, запустить поток SetEvent(). Код будет проще и понятней, однако задачи будут выполняться синхронно, последовательно как и в первом случае.
3. Можно закрывать TCriticalSection отдельные наборы данных, это возможно несколько увеличит быстродействие (не факт!), усложнит код и увеличит вероятность deadlock, т.к. для обработки одного запроса используется несколько наборов данных. Deadlock не будет, если перед обращением к следующему набору ( critical_section->Enter() ) копировать что необходимо из предыдущего и отпускать его ( critical_section->Leave() ) - тут становится важна стоимость операторов копирования.При больших объемах, стоимость копирования может перекрыть весь профит от частного обращения к наборам.
TThread полезно использовать при длительных операциях ввода вывода и ресурсоемких операциях, т.е. когда нужно подождать, не останавливая основной поток. Выигрыша в производительности полагаю нет, к тому же переключения критических секций также имеют стоимость. 
Вопросы:
1. Какой вариант предпочтительней? Есть стандартные схемы?
2. Как влияет количество ядер, процессоров, на быстродействие во втором и третьем случае?

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

Глобальная оптимизация: друзья, в новой версии FastReport FMX изменения коснулись всего: от ядра отчетов до вывода текста на экран.
Подробнее обо всех изменениях можно почитать на сайте. 
Если вы еще не обновились, скорее же обновляйтесь! 
Напоминаю, что если вы испытываете трудности в работе с нашими компонентами - мы будем рады помочь вам на страницах форума!

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

Эх, попкорн закончился) Доброго вечера всем.
Вот вы тут развели ср..., прям диву даешься. Неужели тут кто то всерьез верит, что 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 - довольно удобно и комфортно.

Вам надо было чаще посещаться веббинары эмбакрадеро, чтобы быть в курсе, а не заниматься словоблудием.

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

Вставлю свои пять копеек.
Про изначально не понравилось в FireMonkey...
Да, действительно, сначала было как у классика - "Да ты же, парень, прыгаешь в длину!" Т. е. брал Андроид и лепил десктопное приложение под него. Потом пришло понимание того, что так делать не надо. Взял тот же Андроид и начал смотреть, а как же там сделан GUI. После этого как-то отпала необходимость в гридах и прочих прелестях VCL. а вот не нравится то, что LiveBinding использовать невозможно. в принципе. Т. е. сейчас я ручками заполняю контролы из датасетов, и опять же ручками обрабатываю. Не сложно, но долго. Даже возникла идея, а не вооружиться ли старыми мануалами и не написать ли свои db-aware контролы. Отсюда сразу вопрос, нет ли каких-то принципиальных ограничений для этого? Почему пока есть  только одна реализация чего-то подобного, которая нереальных денег стоит.
Вторая вещь, которая мне не нравится, скорее организационная. Отсутствие преемственности кода. Вот ни разу не удалось запустить приложение, собранное на предыдущей версии FM без каких-либо правок. ну, да ладно.
Потом я немного полистал литературу по Android Studio. И вот теперь задумался. Ведь FM приложения они по архитектуре несколько отличаются... А действительно, можно ли на FM написать всё то, что можно сделать в той же Андроид Студии? ну, пусть не сейчас, пусть в перспективе. Т.е. возможно ли это в принципе? Или это жертва, которую придётся приносить на алтарь кросс-платформенности?
 

Есть часть правды в этих словах. Сейчас вижу как лагерь Дельфи программистов разделился на две части - те кто решили использовать FMX для мобильной разработки и старая гвардия, которая осталась сидеть на VCL. Причем вторые люто ненавидят саму Firemonkey (и их можно понять - первые версии больше походили на недоделанную игрушку, поэтому такое и восприятие)  А был бы один  фреймворк, пришлось бы всем плыть в одной лодке. Но видимо не так то просто было сделать это, поэтому имеем то что имеем.  
PS. А вдруг кто-то сольет все исходники студии, компиляторов и т.д. в интернет и начнут Дельфи развивать энтузиасты. Сразу небывалый интерес проявится 

не скажи. на 7 делфи можно было писать код для CLX и он работал. этот же код просто перекомпилируешь под Kylix и он работал. мне нравилось. 
а внутрь реализации FMX не смотрел? там тоже много чего реализовано на сообщениях - TMessage используется очень часто. Все проблемы решаемы. И костыли так же. За то проблем с переходом бы не было, а это огромный плюс к развитию платформы. А это новые компоненты и так далее. Да и херн с этими TMessage, можно же было реализовать СОВМЕСТИМЫЕ параметры и методы? МОЖНО! Сделали? НЕТ!
да и что дал подход нового фреймворка? НИЧЕГО!! Под FMX за все время его существования написано столько компонентов что их можно просто по пальцам пересчитать!!! за 5 лет существования!!! А если бы людям не пришлось с нуля переписывать свои программы тогда как бы это все обернулось? Тогда бы новая платформа получила свою путевку в жизнь. Все зависит от популярности продукта. Когда продукт малопопулярен он долго не живет.
Да и этот подход использован в Лазаре, да они правят косяки НО один и тот же код работает везде и при этом по максимуму совместим с Делфи. При этом интерфейсы были реализованы и для QT и для GTK1 и GTK2 и Cocoa  и были попытки под Android сделать. При этом все это делалось на голом энтузиазме. 

Разные. Человек среду использует, судя из поста, как "чёрный ящик" , он туда код оттуда форма. 
Да и суть фразы про линух в другом- как только берутся за реализацию в линух после этого Delphi загибается. Спорный момент - для Delphi это только второй подход к линукс. 
 
Delphi не первый раз "хоронят", так что - "поживем увидим, выживем учтем". Тенденция направленности маркетинга мне абсолютно не нравится, ставка сделана на корпоративный сектор. С такими ценами, в нашей стране по крайней мере,  нет смысла развиваться индивидуальному разработчику. 

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;  

Привет.
0 - Default Style он содержит на всех платформах и версиях. ( Win 7, 8, 10, macOS, Android и iOS )
1 - Custom Style он содержит уникальный стиль для платформ и работает только на этой платформе. ( Windows 10 Desktop )
 

Добрый день,
Пока находится на доработке. Финальные штрихи.