SergeyIT

Спасибо. Элегантно! На уровне языка иметь специальный блок инициализации. Читал, но еще не успел опробовать, теперь знаю. А каковы традиции в передаче зависимостей форме? Виртуальность конструкторов озадачила мышление. После других языков. Главное аккуратно этим пользоваться. Быть может просто завести метод в форме вроде Inject или Init? Но возникает вопрос где его можно вызвать, если зависимость создается на уровне TApplication, а общедоступных (статических или коассовых по OP) свойств, методов заводить не хочется?

@zairkz На работу FM вообще и, в частности, на работу 2D, очень интересно смотреть с позиций сравнения с WPF Microsoft и JavaFX Oracle. В первой у меня, не скрою, большой опыт. Но и со второй было общение. Существует 2 клиентских модели рисования: умная (по необходимости обновления экрана) и игровая в вечно бегущем OnPaint (OnDraw, ...). Далее, если я ошибусь, то меня поправит, надеюсь, Ярослав. FM использует умную модель (как WPF и JavaFX) с тем, чтобы не нагружать процессор. Ну, в самом деле, клиентское приложение не игрушка и в FM team знают, когда надо перерисовать графику. В особых экстраординарных случаях есть спец. методы принудительной кастомной прорисовки. Но уж не знаю как в OP работал OnPaint раньше (я неделю назад влюбился в OP окончательно и бесповоротно), но возможность рисовать в OnPaint оставлена. Причем, вызов OnPaint работает по "умной" схеме (по необходимости) и второе, тяжелые компоненты (контролы по факту) не создаются, а вместо этого идет указание DirectX или OpenGL набросить легенький примитив, не отягощенный никакими атрибутами UI контрола и пр. Иначе, FM team оставила все возможности. Хочешь ловить события кликов по линии - пожалуйста, контрол TLine. Хочешь рисовать что-то в псевдоигровом стиле - Canvas.Draw... В WPF также широко представлена объектная (UI компонентная) модель для рисования умных контролов типа линий, эллипсов и пр. Однако отсутствует такой вот изящный псевдоигровой OnPaint. А что же со свойствами графики, рисуемой TCanvas. Они работают так, как это было принято всюду ранее - графический контекст. Чуть выше канвас получает атрибуты пера, далее рисует что-то, далее опять можно изменить эти свойства и нарисовать что-то другое. В общем, все очень красиво и элегантно. Когда познакомлюсь поближе, можно что-то и обзорное написать на эту тему.

Спасибо, ясность есть. Раз уж затронута эта особенность. Для абстрагирования и последующего приведения типов удобно иметь общего наследника (TObject). Но это дорогое и, уверен, не совсем уж нужное удовольствие. Совершенно ясно, что некоторые основные типы должны учитываться системой особенным образом, вне иерархии наследования от TObject. Возвращаясь к задаче приведения, будет ли хорошей практикой использование обобщенного объекта вида TSimpleObject<T> = class(TObject) constructor Create(wrappedPrimitive : T); property Value : T read GetValue; для передачи всего того, что не является TObject?

События в Object Pascal имеют следующую сигнатуру procedure of object Анонимные методы - reference to procedure (function) То есть, это различные сущности. В языке C# эти понятия тождественны, в Java AddListener принимает интерфейс типа ActionListener. Что помешало разработчикам отождествить эти понятия? Исторически унаследованная несовместимость? Чем отличается procedure of object от reference to procedure? Это важно с точки зрения организации приложения в стиле ООП. Спасибо большое!

Браво FM Team! Спасибо! Это гениально, говорю без лишнего пафоса. Искренне. Могу пояснить мое восхищение, если это будет кому то интересно.

Главный класс приложения - TApplication. В языках C#, Java используют этот класс для управления жизненным циклом объектов, которые не относятся к UI. Здесь, как правило, создаются различные хранилища, менеджеры, решается задача внедрения зависимостей. У меня, как у человека, влюбившегося в современный Object Pascal после другого... опыта, возникает вопрос, как правильно решить эту задачу, точнее сказать, где именно ее решать? Вмешательство в код вида begin Application.Initialize; Application.CreateForm(TForm1, Form1); Application.Run; end. хоть и работает, но как то в отладке ведет себя сложно. Например, закрытие приложения не ведет к остановке работы отладчика. Вопрос: Как правильно инициализировать приложение с возможностью создания менеджеров на уровне TApplication и передачи в конструктор формы важных параметров?

Приветствую. Речь пойдет о создании графики в коде. Когда интересно вывести в TPanel "полноценный" управляемый графический объект, скажем, линию, то мы должны поступать так: line:= TLine.Create(pnlDrawing); line.StrokeThickness:= 10; line.LineType:= TLineType.Top; line.Position:= TPosition.Create(TPointF.Create(130, 130)); line.RotationAngle:= 90; line.HitTest:= True; line.StrokeCap:= TStrokeCap.Round; line.Width:= 100; // line.Stroke:= не могу найти в доке правил описания кистей! line.Parent:= pnlDrawing; где pnlDrawing - TPanel контейнер. Однако же, если необходимо получить лишь визуальную - неуправляемую линию, на помощь приходит TCanvas (FM edition ) как аналог графического контекста в других языках. И по установленным правилам мы помещаем вот такую часть в OnPaint обработчик контейнера рисования. begin with Canvas do if BeginScene then begin try Canvas.DrawLine(TPointF.Create(100, 100), TPointF.Create(100, 100), 0.5); finally Canvas.EndScene; end; end; end; Эксперименты показывают, что Canvas "помнит" размер пена (ручки), установленный как line.StrokeThickness:= 10;, например, в обработчике OnCreate панели или формы. Опыт показал также, что вызов OnPaint работает в стиле SMART - только при необходимости перерисовать панель. Скажеи, при изменении размеров формы. Вопрос: Линия, которая создается в Canvas.DrawLine(...) - это ведь всего лишь примитив в терминах DirectX, если мы говорим о Windows исполнении? А вовсе не полноценный UI компонент TLine. Так?