Y
Если я правильно понял. То интерфейсы ж напрашиваются.
Size: a a a
2020 November 30
Y
А когда оба независимых класса будут реализовывать один интерфейс то там уже пофиг Ёж или Уж.
z
интерфейсы всегда избегал использовать
Y
Ну с ними да, надо умеючи. Но дают гибкость. В данной задаче думаю самое-то.
Y
Щас профи проснутся, предложат, раскритикуют :)
MО
как местные профи скрещивают ужей с ежами?
есть векторный редактор в котором меня давно напрягвет такой варнинг
Warning: Class types "Tуж" and "Teж" are not related
суть такая: есть несколько рисовательных бакендов (сделаны в виде контролов) GDI, Canvas, OpenGL
GDI, Canvas - делал я, поэтому могу воротить что хочу. сделал базовый класс TCADControl=class(TCustomControl) от него наследую контролы для GDI, Canvas
Для OpenGL использую стандартный TOpenGlControl, соответственно наследовать его от TCADControl нет возможности (а делать своего клона лень)
Соответственно при преобразовании типов вышеуказаный варнинг. Но все работает, т.к. TCADControl ниче кроме стандартныйх onMouseЧетоТам пока не предоставляет. Но скоро будет и тогда работать данная порнография перестанет.
Для решения вижу только способ сделать "контрол в контроле", но это имхо черезчур. Посоветуйте еще варианты?
есть векторный редактор в котором меня давно напрягвет такой варнинг
Warning: Class types "Tуж" and "Teж" are not related
суть такая: есть несколько рисовательных бакендов (сделаны в виде контролов) GDI, Canvas, OpenGL
GDI, Canvas - делал я, поэтому могу воротить что хочу. сделал базовый класс TCADControl=class(TCustomControl) от него наследую контролы для GDI, Canvas
Для OpenGL использую стандартный TOpenGlControl, соответственно наследовать его от TCADControl нет возможности (а делать своего клона лень)
Соответственно при преобразовании типов вышеуказаный варнинг. Но все работает, т.к. TCADControl ниче кроме стандартныйх onMouseЧетоТам пока не предоставляет. Но скоро будет и тогда работать данная порнография перестанет.
Для решения вижу только способ сделать "контрол в контроле", но это имхо черезчур. Посоветуйте еще варианты?
>Для решения вижу только способ сделать "контрол в контроле", но это имхо черезчур. Посоветуйте еще варианты?
С объектами это стандартная практика.
С объектами это стандартная практика.
RS
интерфейсы всегда избегал использовать
Да не, насколько я вижу тут именно интерфейcы нужны. А в чем опасность у них?
Рекомендую
Рекомендую
{$interfaces corba}
http://newpascal.org/assets/modern_pascal_introduction.html#_interfaces там советы и правильная практикаz
неиспользую=незнаю=неумею((
RS
неиспользую=незнаю=неумею((
Я тоже до недавнего (относительно) времени не использовал. Все оказалось проще чем думал. Работает норм. Выбрать лучше именнно Corba для FPC. По ссылке описание. ТАм директива ModeDelphi, но это необязательно. Просто кроссIDE
MО
С AGG2D.pas кто-то работал? Может есть доработанный TAgg2D для поддержки штрихованных линий?
z
» штрихованных линий
z
кровушки штрихи попили у меня, но не в AGG2D))
SB
неиспользую=незнаю=неумею((
Завидую как человеку, который еще не смотрел твой любимый фильм. =)
AS
неиспользую=незнаю=неумею((
Слова профессионала!
SB
Если уж совсем религия запрещает интерфейсы, то придется делать класс-обёртку, где TOpenGlControl не предок, а приватное поле.
SB
Если у кого-то были проблемы с присвоением свойств COM-объекта в FPC, то я вчера это пофиксил - https://bugs.freepascal.org/view.php?id=38151
AK
в коммитах не видно, значит, не считается
z
Если у кого-то были проблемы с присвоением свойств COM-объекта в FPC, то я вчера это пофиксил - https://bugs.freepascal.org/view.php?id=38151
баг надо найти, пофиксить, настоять чтоб приняли патчик. третье самое трудное))
SB
Эта проблема известна с 2013 года, в гугле много вопросов без ответа на эту тему.
AK
проблема в "настоять, чтоб приняли патчик", боюсь, существует с более давних времён :D