kami

Не совсем. То есть - технически правильно, но идеологически - нет. Проведем мысленный эксперимент: что случится, если на BeginScene возникнет исключение? Правильно, битмап не будет уничтожен, потому что этот код не выполнялся внутри Try. Поэтому, если заниматься буквоедством, то код должен выглядывать так: MyBitmap := TBitmap.CreateFromFile(OpenDialog1.Files[0]); try Image1.Bitmap.Canvas.BeginScene; try Image1.Bitmap.Canvas.DrawBitmap(MyBitmap, MyRect, MyRect, 20); finally Image1.Bitmap.Canvas.EndScene; end; finally myBitmap.Free; end;

всё классно, за исключением: 2,3,6 - исключительно под win. 5 - судя по комментариям в исходниках - тоже только win. 4 - мормоты и не позиционировались как кросс-платформенные. Итого остается только TurboPack / TurboPower LockBox (подозреваю, что это одно и то же).

https://quality.embarcadero.com/browse/RSP-16036

Небольшая ремарка - когда я говорил "платформенные гриды не нужны" я имел ввиду - мне не нужна нативная реализация, а нужна стилизованная. Я придерживаюсь того же мнения, как и многие участники форума - грид на мобильной платформе зло. И если он используется - то данных в нем должен быть мизер, ибо неудобно работать. Ок, не вижу смысла заводить запрос в QC, возможно - когда действительно возникнет реальная необходимость (на текущий момент не могу придумать железобетонную аргументацию, чтобы запрос был принят). Последний вопрос, уже из чистого любопытства - не пойму, а как активируется iOS-овская реализация грида? Вот стилизованную - вижу, когда бросаешь грид на форму - там автоматом в uses падает FMX.Grid.Style и в initialization этого модуля идет регистрация. А вот iOS - да, тоже есть регистрация в initialization, но этот модуль нигде не фигурирует в uses, в т.ч. и в штатных исходниках... и получается, что компилятор его просто не включит в работу со всеми вытекающими. Его при необходимости использования нужно прописывать ручками?

Выравнивание одного - Client. Выравнивание второго - Top или Bottom. Элементарно, Ватсон! Примеры: 1. ListBox - Top , Panel - Client 2. ListBox - Client, Panel - Bottom. Всё зависит от того, кто должен менять размеры, а кто оставаться недвижим.

Она подъемная. Но зачем дублировать код того же TDefaultEditor, если можно было бы просто унаследоваться от него и дополнить нужным функционалом, если бы эти редакторы были объявлены в interface-секции. Допустим, в следующей версии RAD функциональность редакторов расширяется, они обрастают новыми интерфейсами. Копи/паст в свой модуль одного из редакторов об этом не узнает. И о том, что нам нужно заново производить копирование кода узнаем только в runtime, когда TStyledGrid не получит необходимый интерфейс у нашего inplaceEditor. Поправка - об этом узнают те, которые не боятся лезть в исходники FMX, остальные будут спрашивать "почему перестало работать". В общем, не знаю... Я сужу со своей колокольни - мне платформенные гриды не нужны. Возможно, если включить в мои рассуждения еще и необходимость их поддержки, то текущая картина действительно станет единственно верной. Но пока - объявления редакторов в implementation и жесткое задание "какой редактор какой колонке сопоставить" в TStyledGrid.GetEditorClass (пусть даже это виртуальный метод) мне кажется значительно усложняющим фактором.

Через Get It Manager можно поставить TurboPack LockBox. Это набор компонентов, реализующих различные виды шифрования, хеширования. И адаптированные для FMX.

LockBox для FMX через GetIt ?

Двусмысленно

Berlin Upd1 - всё на симуляторе запускается. Без проблем. А вот 7-й XCode у меня свалился напрочь после обновления MacOS до последней версии.

@Rusland, ага, спасибо. Сам нашел немножко раньше

Добрый день всем! RAD 10.1 Upd1, платформа Win32, создаем пустое приложение. dpr выглядит так: program Project5; uses System.StartUpCopy, FMX.Forms, Unit11 in 'Unit11.pas' {Form11}; {$R *.res} begin Application.Initialize; Application.CreateForm(TForm11, Form11); Application.Run; end. Допустим, нам нужно в dpr использовать модуль FMX.Styles. (например, для выполнения TStyleManager.SetStyle(TStyleStreaming.LoadFromResource(HInstance, 'DEFAULT_STYLE', RT_RCDATA)); Если вставить его в uses ДО FMX.Forms, то получаем AV на завершении приложения. Если после - то всё хорошо. Блин, 4 часа убил на поиски... Или не надо так делать (я про загружать стиль до инициализации приложения)? Когда-то на вебинарах говорили, что вот такое действие более правильное, чем использовать StyleBook... Как ошибки-то сообщать в Embarcadero? Опять я ничего не пойму по навигации на их сайте.

Ну, для моих нужд хватило следующего: type TStringColumn = class(FMX.Grid.TStringColumn) protected // function CreateCellControl: TStyledControl; override; // это было в Seattle public function RefreshEditor(const InplaceEdit: TFmxObject; const Value: TValue): Boolean; override; end; function TStringColumn.RefreshEditor(const InplaceEdit: TFmxObject; const Value: TValue): Boolean; var ivk: IVirtualKeyboardControl; begin // здесь уже создан штатный контрол-редактор из числа имеющихся в Grid.Style.pas if InplaceEdit is TStyledControl then begin TStyledControl(InplaceEdit).StyleLookup := 'editVariableHeightStyle'; // свой стиль if InplaceEdit.GetInterface(IVirtualKeyboardControl, ivk) then begin ivk.ReturnKeyType := TReturnKeyType.Done; // клавиатурные настройки ivk.KeyboardType := TVirtualKeyboardType.NumberPad; end; end; Result:=inherited RefreshEditor(InplaceEdit, Value); // и штатный вызов. end; Будет время (ох, вряд ли...) - попробую разобраться со всем остальным.

Нет, конечно можно воспользоваться событием OnCreateCustomEditor. Но сделать свой редактор на основе уже существующих - нельзя. Они все (существующие редакторы, включая TDefaultEditor) объявлены в implementation FMX.Grid.Style.pas То есть - придется копировать код оттуда, дабы забрать функциональность ICellControl... А единственное место, где можно достучаться до редактора - это перекрытие TColumn.RefreshEditor. Но это может быть поздно - там уже почти все действия с контролом произведены, осталось только показать его... Как-то предыдущая архитектура грида мне больше нравилась... Пока не получилось, будет результат - отпишусь.

Ну вот зачем надо было выносить создание редакторов в FMX.Grid.Style.pas, в TStyledGrid? Да еще жестко зашивать "какие редакторы могут быть созданы" в function TStyledGrid.GetEditorClass? То есть теперь, получается, если нужен свой InplaceEditor, то мало создать свой класс TColumn, нужно еще перекрывать TStyledGrid...

Добрый день всем! В Seattle у TColumn была возможность создать свой контрол для редактирования содержимого, перекрыв CreateCellControl. TStringColumn = class(FMX.Grid.TStringColumn) protected function CreateCellControl: TStyledControl; override; end; Пытаюсь перейти на Berlin Upd1 - и вижу, что этого метода нет. Пошерстил по форуму, по исходникам, погуглил - да, грид переписан чуть более чем полностью. В стандартных примерах (если быть более точным - то по гриду только один) используются штатные колонки с их "штатными" редакторами. Мне же нужно установить редактору мой StyleLookup, выставить тип клавиатуры и пару других параметров. Собственно, вопрос - как? P.S. Да, гриды - зло, знаю. Но это узкоспециализированное приложение, работающее только на планшетах.

Коллеги, добрый день! Подскажите, кто с iOS работает - в http://edn.embarcadero.com/article/44715 (Feature and bug fix list for RAD Studio 10.1 Berlin Subscription Update 1) видно, что появилась поддержка iOS10. Супер, замечательно и великолепно. А вот про "какой xCode использовать" - ни слова. Может, как обычно не там ищу (навигация по сайте Embarcadero каждый раз вгоняет в тоску...)? Теоретически, раз поддержка iOS10 появилась только в XCode 8, то логично было бы предположить, что и RAD Studio должен работать с ним же. Но суровая реальность, как известно, может отличаться... Понятно, что поставлю 8 рядом с 7.3, но все же...

а где было сказано, что нужно держать несколько копий наборов данных?

Так рассуждая, можно вообще до низов дойти Просто если у вас http - то я на текущий момент ничего лучше чем mORMot-ы не нашел. Да и не искал, если честно. Стабильность работы - 101%, в отличие от Indy и Synapse (до этого работал только с ними). А вот если TCP (своя надстройка над ним), то тут уже есть варианты. Но индейцы все равно в пролете, как и ScktComp.pas в режиме stBlocking. Всё вышесказанное - imho.

Так вам http или tcp?

MS - это Microsoft. http.sys и великолепная надстройка над ним в виде THttpApiServer из состава mORMot. Естественно - заточено только под Windows.

Поэтому нужно использовать или асинхронную работу, или пул потоков. Я в последнее время остановился на последнем. Благо, MS имеет великолепную реализацию для http.

На Indy, которые генерят на каждый запрос отдельный поток? Хммм....Несколько тысяч потоков, инициализация каждого - затратная операция с т.з. ОС... ну да, ну да...

И телепаты сразу угадали, что это за ошибка, и дали четкий и исчерпывающий ответ на все поставленные (и не поставленные) вопросы.

Зато - сохраняется ссылочная целостность в этих связанных наборах. А вот вариант 3 ее лишен. Если обработка данных потоком подразумевает длительные операции - возможно, стоит использовать что-то вроде п.2? Необходимые данные копируем (с блокировкой пула), работаем с ними, копируем обратно (с блокировкой пула). ?