Лидеры

unit modURL; interface uses System.SysUtils {$IFDEF ANDROID} , Androidapi.Helpers, Androidapi.JNI.GraphicsContentViewText; {$ENDIF} // ... {$IFDEF MACOS} {$IFDEF IOS} , Macapi.Helpers, iOSapi.Foundation, FMX.Helpers.IOS; {$ELSE} , Posix.Stdlib; {$ENDIF} {$ENDIF} // ... {$IFDEF MSWINDOWS} , ShellAPI; {$ENDIF} procedure openUrl(const aURL: string); implementation {$IFDEF ANDROID} function andUrl(const aURL: string): boolean; var Intent: JIntent; begin Intent := TJIntent.JavaClass.init(TJIntent.JavaClass.ACTION_VIEW, StrToJURI(aURL)); TAndroidHelper.Context.startActivity(Intent); end; {$ENDIF} {$IFDEF IOS} function iosUrl(const aURL: string): boolean; var NSU: NSUrl; begin NSU := TNSURL.Wrap(TNSURL.OCClass.URLWithString(StrToNSStr(aURL))); if SharedApplication.canOpenURL(NSU) then SharedApplication.openUrl(NSU); end; {$ENDIF} {$IFDEF MSWINDOWS} function winUrl(const aURL: string): boolean; begin ShellExecute(0, 'open', pchar(aURL), nil, nil, 0); Result := True; end; {$ENDIF} {$IF defined(MACOS) AND not defined(IOS)} procedure macUrl(const aURL: String); begin _system(PAnsiChar(AnsiString('open ' + aURL))); end; {$ENDIF} procedure openUrl(const aURL: string); begin {$IFDEF ANDROID} andUrl(aURL); {$ENDIF} {$IFDEF MACOS} {$IFDEF IOS} iosUrl(aURL); {$ELSE} macUrl(aURL); {$ENDIF} {$ENDIF} {$IFDEF MSWINDOWS} winUrl(aURL); {$ENDIF} end; end. вот так на делфи

Ну так поставь FGX - этот код как раз с него взят.

Есть. И? Вы пользовались TLang? Полноценно, или так... "поиграться"? Не хочу обидеть эмбаркадеро, - но это самый бестолковый и самый косячный компонент...

Вот посмотрите справку System.Classes.TThread.Synchronize Примеры на С++: ThreadSynchronize (C++) и TThreadYield (C++)

Уже создавал тему по этому вопросу, надеялся, что в ХЕ8 рендеринг исправят, но нет. Кроме того, проблема обросла подробностями. Итак, та же моделька того же человечка в шлеме, собрана на TPlane'ах, код текстурирования тот же, всё так же не рендерится голова внутри. В тот раз проблема решилась случайно и я сам не понял, что же именно привело к решению. С тех пор форму старался не трогать, но рано или поздно дошёл и до неё черёд. И как результат, та же проблема - уже в ХЕ8. Подробнее о том, как организована модель: Viewport3D, внутри него лежит TDummy, в котором собрана TPlane'ами модель, а также камера, которая на это безобразие смотрит: Теперь непосредственно к проблеме: Смотрим на скрин: По вайрфреймам можно понять, что боковые плоскости головы не рендерятся вообще (а не пропадает текстурка, как я полагал раньше). Интересно, а что "внутри" шлема? Чтобы узнать, сделал возможность в рантайме, не закрывая программу, "снять" шлем (Visible для всех граней в False). Смотрим: Оп! Все грани на месте, всё отлично прорендерилось! А если снова "надеть" шлем? Нет, надевание шлема привело всё к той же грустной картине на первом скрине - боковые плоскости просто отсеклись и упрямо не хотят рендериться... Следующим шагом попробуем уменьшить прозрачность одной из плоскостей шлема и посмотреть сквозь неё на отсечённую плоскость головы: Так точно, и полупрозрачность не заставляет включаться рендеринг "внутренних" граней. А что будет, если поменять разрядность платформы? Выставим Win64/Debug и - о чудо! - рендеринг внезапно заработал! И под конец экспериментов всплыл не такой страшный, но всё же назойливый баг, из-за которого иногда не прорисовываются те или иные графические элементы: к примеру, здесь не прорисовались текстуры модельки, иногда не прорисовываются некоторые превьюшки списка серверов, но это лечится обновлением битмапа. Итак, что же мы узнали из этих исследований? Ровным счётом ничего. Рендеринг или, наоборот, нерендеринг не имеют никаких закономерностей. Какими способами удалось повлиять на прорисовку этих поверхностей: 1) Изменение целевой платформы (Win32/Win64/Debug/Release) дают разный результат - практически всегда из четырёх комбинаций есть удачная, где всё рендерится 2) Изменение формы - добавление новых элементов или удаление существующих, помогает не всегда. На рабочей конфигурации может наоборот привести к отсечению граней 3) Изменение кода. ЛЮБОЕ. Даже никак не связанное с рендерингом. Достаточно воткнуть в произвольное место что-то типа Inc(Variable), чтобы рендеринг починился. Этого же, впрочем, достаточно и для того, чтобы рендеринг сломался. Что НИКАК не влияет на рендеринг: А не влияет всё то, что должно было бы повлиять, а именно: 1) Расстановка в любых мыслимых и немыслимых местах BeginUpdate'ов и EndUpdate'ов 2) Repaint'ы и Invalidate'ы всего и вся 3) Обновление текстур (грубо говоря, заливка модели новой текстурой) 4) Использование StyleBook'a Исходя из вайрфреймов, нарисованных на каждой плоскости, мы видим, что не прорисовываются сами TPlane'ы. Могу предположить, что движок считает их невидимыми и отсекает как ненужные для оптимизации, но почему, в таком случае, рендерятся передняя и задняя плоскости головы? Итак, вопрос - классика: кто виноват и что делать. Баг ли это в движке FMX, или же всё учтено и достаточно задать волшебную опцию, которая разом всё починит - я так и не узнал. Приветствуется любая помощь, а также хотелось бы раз и навсегда закрыть вопрос: в каких случаях нужно делать BeginUpdate/EndUpdate и влияет ли он на обработку отрисовки унаследованных объектов.

У меня была похожая проблема. За Tplane с альфа каналом ничего не рисовалось (Сразу фон). Помогла смена материала с TLightMaterial на TTextureMaterial.

главное найти от куда плясать и все. а что ты хотел то? fmx это такой зверь которые надо пилить и пилить, не зря наши делали. это как и наши машины, купил а потом напильником подгоняй что бы работало