freepascal.ru

Вообще изначально "паскалевских" типов у меня небыло, в основе были GDBDouble, GDBInteger и т.п.
Сейчас планирую ввести "паскалевских" типы в основу всего - поплотнее завязаться с ртти.
Если претензии просто к названии - планирую глобальное переименование, но на чтото умнее zeDouble у меня ума не хватит, рассмотрю любые варианты.
Или ты про убрать тип из названия и подставлять single\double по ситуации?

Просто спросил...
Я уже говорил, у меня от кода зкад крыша едет)
У меня во всем правило - не повторяться. Т.е. если нужен тип данных свой для градусов, то

Какой там на нижнем уровне тип не должно быть видно в названии верхнего. Палки в колеса такие вещи вставляют, обычно.
Я тебя про single спрашивал когда то. К примеру если у тебя везде GDBAngleDouble и решил сделать на базе исходников своих маленькую программу где не Double на нижнем уровне нужне, а single. То название будет всех путать, а переименования.. это трата времени.

>>Т.е. если нужен тип данных свой для градусов, то
Да, соглашусь. вырисовывается чтото наподобии
"абсолютные" - double, single...
"относительные" - ДляУглов, ДляКоординат, ДляРастояний...

>> а переименования.. это трата времени.
Переименования + какой-никакой рефакторинг очень полезно. По крайней мере мне, но сил отбирает много.

>>Я уже говорил, у меня от кода зкад крыша едет)
К сожалению у меня не получается всё изначально продумать. Делаю чтоб работало, потом переделываю-уродую - всё всегда просит переименований и рефакторинга((
Очень медленно, но "спокойные" места в коде появляются))

http://www.yworks.com/products/yed
Чтобы продумать. Время отнимает, но зато наглядно можно описать разные структуры взаимодействий и взяться за работу имея план.

Sharfik, если бы такая прога была бы для Lazarus, та еще и интегрированная...

Лекс Айрин
В соседней теме решают что бы написать такое, на хлеб с маслицем))

Sharfik
Если бы автоматически строить хотя бы зависимости юнитов друг от друга...
Зачем тратить время на картинку никак не связанную с кодом? Мне с кодом проще. Картинки нужны для наглядности, но либо они генерятся из кода, либо код из них.
Давай для эксперимента какой момент зкада отрисовать? Хоть я и невижу пользы, но попробую

zub, вот честно, самому хочется, но мне еще учиться, учиться и учиться((((

zub писал(а):Давай для эксперимента какой момент зкада отрисовать?

Суть этого не в авто создании связей(это бонус), а в документировании и переносе всех идей, рисований на бумажке в файл-схему.
Дом без проекта строить не стоит, можно, но получается колхоз. А схемы подобные как проект для программы.
Так что, мое дело предложить.

Поддерживать 2 сущности вместо одной я не могу. А еще и синхронизировать их через голову - это уже даже не двойная работа((
По запросу - пожалуйста, а просто так вдруг кому пригодится - спасибо.
"Долгий" и "мучительный" путь мне ближе)) - неумею проектировать. Писать раз и навсегда думаю никто не умеет.

Кроме того подход "код как модель - его и рисую", тоже имеет место быть и инструменты тут помощнее.

Добавлено спустя 1 минуту 17 секунд:
зы
>>Дом без проекта строить не стоит
С проектом, но наняв бригаду таджиков типа меня - не лучше))

zub "Вид"-"Зависимости модуля"-"Проекты и пакеты"... не смотрели?

п.с.
не фонтан, конечно. Но увидеть зависимые модули вроде как можно.

Смотрел конечно + cody (проект\показать используемые файлы PPU) для этого пользую

В первом приближении добавил регистрацию типов данных на основе RTTI, сделал пример использования http://svn.shamangrad.net/zcad/trunk/ca ... inform.pas

От предидущего примера с загрузкой информации о типах из внешнего файла отличается парой строк
было

стало

и наличием снаружи файлика runtimeloadeddata.pas

С одной стороны новый способ надежнее - не надо синхронизировать описание данных в внешнем файлике. С другой стороны RTTI не хранит информацию о именах полей записей, ее всеравно придется передавать руками((

Sharfik
на тему рисования чеголибо в yEd`е. какимито странными способами мне удалось скормить еду граф зависимостей юнитов зкада между собой. Практической ценности это не представояет, просто чтобы оценить размеры бедствия.

В других вариантах раскладки нагромождение линий связи. круговой понравился больше всего. модули зкада - маленькие квадратики по окружности, лучи это разные fpc и lcl модули.
Незнаю, плакать или смеяться))

А граф классов получился очень даже ничего

Добавил еще один пример создания "команды" https://svn.shamangrad.ru/zcad/trunk/ca ... ample2.pas
Отображает параметры в инспекторе, добавляет кнопки, по нажатию которых вызываются соответствующие процедуры. В зкаде регистрируется под именем ExampleCom.

Вдогонку к постам про лог годичной давности.
Разделение в логе по уровням хорошо работает, но по сути... В штатном режиме лог почти пустой, при ошибках включаю LM_Trace и снова тонна сообщений от всего подряд. Походу нужно разделение сообщений на подсистемы и отдельное управление попаданием в лог сообщений от разных подсистем. Например при вылете есть подозрения что падает инспектор объектов - включаю сообщения только от инспектора...