Страница 35 из 57

Re: САПР на Lazarus

СообщениеДобавлено: 04.09.2017 16:46:37
zub
Проблема в доступе к памяти а не в математике, к томуже математика вся на моей стороне, из easylazfreetype я беру только контура глифов, безье считаю сам. Да и с отображением букв проблем никаких нет

Добавлено спустя 8 часов 37 минут 12 секунд:
2 дня коту под хвост изза дурацкого устройства EasyLazFreeType. Он при своей финализации уничтожает все что в нем прокешировано:
Код: Выделить всё
finalization

  if FreeTypeInitialized then
  begin
    TT_Done_FreeType;
    FreeTypeInitialized := false;
  end;

end.

после этого классы TFreeTypeFont не могут быть униичтожены - некоторые элементы (а может и все) их FGlyphTable уничтожаются повторно. Все созданые TFreeTypeFont нужно уничтожать до финализации EasyLazFreeType.
Мой FontManager ниче о форматах шрифтов поддерживаемых программой не знает, и uses EasyLazFreeType не делает... если сделать такой усес то проблемы нет - EasyLazFreeType будет финализирован гарантировано позже FontManager со всеми его загружеными TFreeTypeFont.
Но блин без uses EasyLazFreeType внутри FontManager компилятор почемуто упорно финализирует EasyLazFreeType раньше FontManager как бы я не тосовал цепочки uses. Придется делать патчик на EasyLazFreeType позволяющий позже убивать TFreeTypeFont.
Си не фонтан, а его тупой перевод на паскаль и попытка завернуть в классы - вообще говно((

Добавлено спустя 24 минуты 13 секунд:
https://bugs.freepascal.org/view.php?id=32371
чудес как всегда небывает))

Re: САПР на Lazarus

СообщениеДобавлено: 05.09.2017 09:02:03
MylnikovDm
А зачем ты вообще уничтожаешь объекты класса TFreeTypeFont, если их должен уничтожать EasyLazFreeType?
Или ты свои объекты класса TFreeTypeFont создаёшь? Так это не правильно. Ты должен получить готовый объект, который тебе создаст EasyLazFreeType, который его потом и уничтожит.
Другое дело, что у них нет системы оповещения о том, что объект уничтожен, чтобы у себя, если что, ссылки поправить. Но в данном случае это не критично, поскольку созданные объекты класса TFreeTypeFont до завершения работы программы модулем EasyLazFreeType не уничтожаются.

Re: САПР на Lazarus

СообщениеДобавлено: 05.09.2017 10:46:47
zub
Их не уничтожает EasyLazFreeType, их нужно уничтожать самостоятельно. Но при "классическом" использовании они будут уничтожены до финализации EasyLazFreeType, и проблема незаметна

Re: САПР на Lazarus

СообщениеДобавлено: 05.09.2017 11:14:50
MylnikovDm
Значит придётся уничтожать FontManager руками из процедуры закрытия приложения, а не в секции finalization модуля.

Re: САПР на Lazarus

СообщениеДобавлено: 05.09.2017 11:23:54
zub
Очень не хотелось бы, темболее патч в багрепорте решает проблему.

Добавлено спустя 2 часа 54 минуты 35 секунд:
Вроде патч приняли, извиняюсь за переполох

Re: САПР на Lazarus

СообщениеДобавлено: 05.09.2017 16:50:02
Лекс Айрин
У меня залился.

Re: САПР на Lazarus

СообщениеДобавлено: 03.10.2017 01:11:02
zub
Захотелось еще чуток упростить-универсалить внутреннюю структуру. В голове крутится мысль внутри программы для взаимодействия различных не связанных частей ввести события и подписчиков на эти события.
Например сейчас инспектор объектов и командная строка жестко прописаны в логике программы, хотелось бы иметь возможность легко выкинуть их оттуда без костылей которые нагорожены сейчас.
С командной строкой все просто - она например должна реагировать на сообщения:
-GUIDisable - общее сообщениие запрещающее гуй перед выполнением долгих операций, чтоб нажатия кнопок не влияли
-GUIEnable - обратное предидущему
-CommandRunStart - начало выполнения команды (например спровоцированное нажатием кнопки в гуе) - прячем приглашениие про ввод команды
-CommandRunEnd - конец выполнения команды (обратное предидущему) - возвращаем приглашениие на ввод команды
и генерировать событие
-CommandRun(ТоЧтоВвелПользователь) а командный процессор подписаный на это событие будет пытаться его интерпретировать.

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

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

Сразу разочаровался: нечто отдаленно напоминающее boost.signals в текущем fpc не сделать(( - плохо разбираюсь в "недавних" дельфийских нововведениях, эта возможность появится после появления синтаксиса reference to?

Какие есть еще способы организации подобного?

Re: САПР на Lazarus

СообщениеДобавлено: 03.10.2017 01:28:22
olegy123
del

Добавлено спустя 13 часов 23 минуты 24 секунды:
zub писал(а):Захотелось еще чуток упростить-универсалить внутреннюю структуру. В голове крутится мысль внутри программы для взаимодействия различных не связанных частей ввести события и подписчиков на эти события.
Ух, собрался ввести децентрализованную систему, сменить жескую вертикаль в принятии решений на самостоятельность объектов?
А не приведет ли это к анархии и сепаратизму. Как в Испании и Каталонии? Мол они больше производят и им нужно больше ресурсов и памяти?

zub писал(а):Сразу разочаровался: нечто отдаленно напоминающее boost.signals в текущем fpc не сделать(( - плохо разбираюсь в "недавних" дельфийских нововведениях, эта возможность появится после появления синтаксиса reference to?

Какие есть еще способы организации подобного?
boost это не стандарт. это скорее LCL пакет - набор инструментов облегчающих жизнь С++ кодеру.

Добавлено спустя 3 минуты 37 секунд:
zub писал(а):Некий абстрактный модуль зкада подпишется на требуемые ему события, будет их "слушать" преодически генерируя чтото сам = красота и независимость.

У меня реализована эта часть. По принципу Windows сообщений между окнами-приложениями.

Re: САПР на Lazarus

СообщениеДобавлено: 03.10.2017 15:21:04
zub
>>А не приведет ли это к анархии и сепаратизму. Как в
Не приведет. Текущая ситуация ИМХО гораздо опаcней - сейчас зкад это сборище умников, очень хорошо знакомых между собой - описаная выше командная строка хорошо знакома с командным процессором и вместе они могут замутить багу - мало не покажется. Хочу организовать сборище "дурачков" ничего кроме своих функций неумеющих и общающихся через посредника.

>>boost это не стандарт. это скорее LCL пакет - набор инструментов облегчающих жизнь С++ кодеру.
это понятно, я хотел такогоже синтаксиса - использовать процедуры как тип, ну нет, так нет - сделаю постаринке

>>У меня реализована эта часть. По принципу Windows сообщений между окнами-приложениями.
Это когда упаковка всего в msgstruct (а то что невпиихуемо - пиихаем указателями) и ветвистые кейсы? не, я так нехочу, хочу подписывать конкретные процедуры с конкретными сигнатурами на конкретные событиия

Re: САПР на Lazarus

СообщениеДобавлено: 03.10.2017 18:05:38
serbod
zub писал(а):Это когда упаковка всего в msgstruct (а то что невпиихуемо - пиихаем указателями) и ветвистые кейсы? не, я так нехочу, хочу подписывать конкретные процедуры с конкретными сигнатурами на конкретные событиия

В fpc можно "подписывать" методы на текстовые сообщения. Смотри TObject.DispatchStr()

Re: САПР на Lazarus

СообщениеДобавлено: 03.10.2017 22:37:41
zub
>>В fpc можно "подписывать" методы на текстовые сообщения. Смотри TObject.DispatchStr()
Имхо разницы особой нет какой будет "идентификатор" сообщениия - string или int, но я за int и подобное.

Механизм событий в lcl немного для другого - там обработчики перекрываются в наследниках для реализации новых контролов, у меня этого близко небудет - нужно только обезличеное взаимодействие разных кусков программы.
Кроме того лцл сообщения предполагают статическое присвоение идентификаторов в compiletime, мне нужно динамическое присвоение в runtime

Re: САПР на Lazarus

СообщениеДобавлено: 03.10.2017 23:33:33
serbod
нужно только обезличеное взаимодействие разных кусков программы.
Кроме того лцл сообщения предполагают статическое присвоение идентификаторов в compiletime, мне нужно динамическое присвоение в runtime


Ну так в DispatchStr() ты можешь любую текстовую команду передать, не заботясь о том, какой потомок TObject ее будет обрабатывать и есть ли вообще обработчик. И не обязательно идентификаторы заранее придумывать. Можно в рантайме назначить привязку в TObject.StringMessageTable, но это извращение. Лучше переопределить DefaultHandlerStr, там же можно сделать что-то вроде парсера командной строки.

Re: САПР на Lazarus

СообщениеДобавлено: 04.10.2017 00:04:13
zub
>>Ну так в DispatchStr() ты можешь любую текстовую команду передать
емнип там shortstring - уже не любую. Ну и командная строка и процессор это частности, больше собственно стринг в параметрах нигде наверно и не понадобится

Re: САПР на Lazarus

СообщениеДобавлено: 04.10.2017 02:02:30
olegy123
zub писал(а):Это когда упаковка всего в msgstruct (а то что невпиихуемо - пиихаем указателями) и ветвистые кейсы? не, я так нехочу, хочу подписывать конкретные процедуры с конкретными сигнатурами на конкретные событиия

Плотно подсели на функциональном программировании? Любим строгий вертикальный функциональный тоталитаризм берущий начало с расово-верной функции майн(камп *ф)?

Добавлено спустя 7 минут 5 секунд:
Так может быть демократия? где каждый объект имеет свою индивидуальность?

Re: САПР на Lazarus

СообщениеДобавлено: 04.10.2017 02:16:55
zub
Мне секса с указателями и кастованием их к разным сушьностям уже давно хватает. ненадо это еще разнообразивать

Добавлено спустя 5 минут 25 секунд:
>>Так может быть демократия? где каждый объект имеет свою индивидуальность?
В зкаде скорее анархия))

Добавлено спустя 4 минуты 40 секунд:
viewtopic.php?f=10&t=5917&start=255#p101566
Вот этот заштрихованный шарик - это граф внутренних зависимостей, так что вобщемто не до шуток((