САПР на Lazarus

[zub]

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

Cheb
Сторонние - да, под снос. LCLные терпим и строчим репорты и патчи

[olegy123]

Что конкретно?

при запуске попросило *.pas, пришлось докачывать сырцы.. непонятное меню..
Вся база в txt..
нет UUID, что поволяет даже в far-е найти ссылки на файлы, тем самым построить логические цепочки..

[zub]

>>пришлось докачывать сырцы
Докачивать пришлось не сорцы, а рантайм файлы. голый ексешник нерабортает, ему нужно некоторое окружение.
я везде озвучиваю что чекаутить надо http://svn.shamangrad.net/zcad/trunk/ там и рантайм, и пакеты, и исходники. Откуда взялось мнение что хватит только http://svn.shamangrad.net/zcad/trunk/cad_source/ ?

>>непонятное меню..
Соглашусь с тем что оно скудное, но непонятное...))

>>нет UUID
пока не было большой нужды в нем. но он есть в некоторых не очень важных местах. типа калькулятора расхода памяти и бд оборудования.

посмотрите simplecad - это пример использования движка, там никаких заморочек

[olegy123]

>>нет UUID
пока не было большой нужды в нем. но он есть в некоторых не очень важных местах. типа калькулятора расхода памяти и бд оборудования.

Потому что пока не занимались вопросами интеграции в различные структуры, передачи данных между ними..
Как пример приведу: чтобы указать конкретную деталь вам нужно "Название/Тип/Тип2..Кто делает/Когда выпущен". Чем больше полей, тем точнее поиск.
Чтобы найти в базе - вам нужно конкретизировать, в своей базе -понятно, найти можно. Но когда вам нужно вести обмен данными то либо согласуете поля "Название/Тип/Тип2..Кто делает/Когда выпущен.." либо передаете один UUID. Или у вас запрашивают UUID и вы в 3,4×10^38 уверены, что тот конкретный объект.
Даже в проекте всего здания, разбив файлы по этажам - проще между ними найти связи объектов, чем иметь обычный ID счетчик - его обязательно нужно будет конкретизировать дополнительными полями.

[zub]

В бд у меня 2 идентификатора на изделие. первый общий на все модификации, второй у каждой модификации свой. я вбиваю туда "человекобезопасный" текст, никто не запрещает вбить туда полноценный guid, но пока нужды невижу

[olegy123]

2 идентификатора - это уже очень много..
первый общий на все модификации - в рамках чего общий? В рамках одного zCad? или всего предприятия где установлен zCad(несколько рабочих мест)?

Добавлено спустя 5 минут 52 секунды:
В бд у меня 2 идентификатора на изделие. - а понятно. Т.е. если изделие составное - то части уже не имеют ID?

[zub]

Базу данных оборудования в зкаде нужно брать в кавычки - название условное, базой данных в прямом смысле это не является. Она сделана чтобы более-менее работала и не тратила моего времени. В текущем состоянии без изменений она существует уже очень долго (все изменения там это просто переименования и разные "чистки"), в дальнейшем она будет углублена и развита, или выкинута и переделана. поживем увидим. Кстати это какраз то место где работает "скрипт" и в рантайме парсятся файлы с синтаксисом похожим на паскаль))

Зкад в принципе может считать в чертежах хоть что, но я пользую эту фичу только для кабелей, поэтому на примере кабелей:
http://svn.shamangrad.net/zcad/trunk/ca ... stract.pas - там определен DbBaseObject - базовый объект "бд" зкада
http://svn.shamangrad.net/zcad/trunk/ca ... cebase.pas - тут он чуток расширен DbBaseObject->CableDeviceBaseObject до заготовки под кабельное оборудование
это определено в исходниках и скомпилировано.
Потом в рантайме "скрипт" читает файлы определения устройств (лежащие тут http://svn.shamangrad.net/zcad/trunk/cad/programdb) и расширяет CableDeviceBaseObject до какогото конкретного кабеля какогото конкретного производителя
например http://svn.shamangrad.net/zcad/trunk/ca ... abel/1.pas содержит определение вот этого кабеля http://www.saranskkabel.ru/katalog-prod ... ep,-tppepz в нем к CableDeviceBaseObject добавлен перечислимый тип с сочетаниями именно его жильности-сечений прилагаю скрин как это выглядит в программе

Добавлено спустя 5 минут 40 секунд:
идентификатор этого кабеля - SARCABLETPPep
уникальный идентификатор после того как я счелкну в открытом чекбоксе 20х2х0.5 (20 пар по 0.5мм) станет SARCABLETPPep-20х2х0.5
ну и после добавления этого кабеля в "бд" чертежа он получит еще один идентификатор _EQ000000 - (префикс _EQ + порядковый номер операции добавления _EQ)

Добавлено спустя 4 минуты 14 секунд:
итого аж целых 3 идентификатора:
1 - SARCABLETPPep - идентифицирует оборудование в обобщенном виде
2 - SARCABLETPPep-20х2х0.5 идентифицирует оборудование в конкретном исполнении и получается автоматом по заданой в файле оределении маске из первого определения
3 - _EQ000000 - по нему примитивы с чертежа ссылаются на запись в "бд" чертежа, просто постоянно инкрементируемый идентификатор

[veb86]

при запуске попросило *.pas, пришлось докачывать сырцы.. непонятное меню..
Вся база в txt..
нет UUID, что поволяет даже в far-е найти ссылки на файлы, тем самым построить логические цепочки..

кто же сказал что в zcad-е все гладко. Непонятное меню это не страшно его можно привести к нормальному, там есть файлик тоже в txt который позволяет достаточно быстро добавлять кнопки и изменять меню. Меню надо причесать, но как по мне причесывать пока особо нечего, позже обязательно будет приводится к нормальному виду.
База в txt << мой внутренний голос подсказывает что все таки БД лучше делать как БД, но гораздо больше напрягает отсутствующее меню позволяющее из zcad расширять эту БД. Потому что дырявая память, заставляет снова и снова вспоминать как это вообще делается ручками). В целом добавлять не сложно ручками, но интерфейс нужен им скорее всего и буду заниматься после лета
Существующая БД слабо развита, однабока в сторону слаботочных сетей, о каком UUID идти речь может. Все надо развивать.

Самое главное для меня на данном моменте, так это то, что в ZCADе реально работать (программа ворочает огромные объекты), но увы не полноценно. То что было автоматизировано очень радует, и сильно помогает. То что нет надо либо самому, либо ждать когда кто то сделает. Как по мне (я конечно никому ничего не диктую) лучше что бы zub приложил усилия к другой части программы, а не к созданию полноценной БД.

[olegy123]

Существующая БД слабо развита, однабока в сторону слаботочных сетей, о каком UUID идти речь может. Все надо развивать.

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

[veb86]

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

Я понял о чем Вы говорите, и согласен с Вами. Если стоит задача сделать все уникальным в рамках предприятия, то нужно делать именно так. Если Вам нужно сделать нормальную БД, к zcadу я думаю zub будет не против. Тем более на ранних стадиях можно оставить и старую базу тоже, а потом перейти на новую. Подход с EQ000000 позволяет без навыков программирования присваивать датчикам и прочему те имена, которые нужны в спецификации или в КЖ, на сколько я понял на данный момент БД и работает только больше на спецификацию и КЖ. Лично у меня, пока еще не сложилась работа с данной базой, но это по другой причине, мне кажется слишком долгим процесс привязывания датчика к БД, а уж тем более кабелей, с учетом их частой перекладки. Поэтому в будущем обязательно буду решать совместно с zub как этот процесс упростить и автоматизировать. Но в начале я хочу сделать интерфейс для удобного расширения данной базы, но все может изменится.

[zub]

>>с UUID вы можете
Это всё понятно. Против ничего не имею, но пока особой нужды в них нет. и как уже было сказано есть гораздо более страшные проблемы

Добавлено спустя 2 минуты 49 секунд:
Например тотже докинг - работать он не мешает (1 раз настроил и забыл), а вот праздно интересующихся художников типа виталика отпугивает. Хотя может это и к лучшему))

[vitaly_l]

праздно интересующихся художников типа виталика отпугивает

Зуб-ик, это художников не пугает. Просто художники знают что, ControlBar - работает лучше чем, тот который установлен в zCad.

Вот мы проверили, возьмите: в тот пример, что художники давали выше, нужно следующий код добавить и тогда ControlBar будет меняться с вертикального на горизонтальный. И полосочка, таскательная - её тоже можно менять, этим же методом, прилепляя: то к верху, то к боку. И тогда у Вас исчезнут проблемы с докингом, т.к. у ControlBar их нет, от слова СОВСЕМ! Сделайте уже нормально, если будете продолжать проект:

Код: Выделить всё

procedure TForm1.ControlBar2DockDrop(Sender: TObject; Source: TDragDockObject;
  X, Y: Integer);
begin
  ToolBar1.Height:=99;
  ToolButton1.Wrap:=true;
  ToolButton2.Wrap:=true;
  ToolButton3.Wrap:=true;
  Caption := 'ControlBar2';
end;

procedure TForm1.ControlBar1DockDrop(Sender: TObject; Source: TDragDockObject;
  X, Y: Integer);
begin
  ToolBar1.Height:=25;
  ToolButton1.Wrap:=false;
  ToolButton2.Wrap:=false;
  ToolButton3.Wrap:=false;
  Caption := 'ControlBar1';
end; 


И ID замените, чего там сложного? Поменять EQ000000 на уникальный UUID - дело 5 минут. И при этом можно сделать так чтобы и старые файлы с EQ000000 - тоже открывались при новом UUID, записанном в туже самую переменную.

PS: Эти программисты - хуже детей! Всему их приходится обучать

/

[Лекс Айрин]

Просто художники знают что, ControlBar - работает лучше чем, тот который установлен в zCad.

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

[vitaly_l]

анхордокинг позволяет расчленить приложение на части и тасовать его составляющие как колоду карт

И ControlBar - тоже это делает. Установите уже и проверьте!

[zub]

>>ControlBar - работает лучше чем, тот который установлен в zCad.
Ты путаешь мягкое с теплым. в зкаде есть докинг, но нет "тулбаров" есть формы с кнопками. ControlBar никак докинг не заменит.
И причем тут ToolButton.Wrap? ControlBar неумеет отображать вертикальные панели, "граббер" за который панель таскается всегда рисуется слева, а на вертикальной панели он должен быть сверху.

>>Сделайте уже нормально
Повторяю - сделать нормально можно будет только после появления TAnchorDockPanel и реализации вертикальности в ControlBar

>>И ID замените, чего там сложного?
Ниче сложного, просто одного твоего и olegy123 желания для этого мало, нужна объективная необходимость. Пока существующая реализация мне удобней чем UUID - при отсутствии гуя для работы с "БД" строчки наподобии EQ000000 или EQPriborC2000 гораздо информативней чем '{B7E2C17F-1C24-472F-8179-8DF591121D9E}'. Вот ктонибудь напишет гуй который спрячет внутреннюю реализацию, тогда будем подумать))

Добавлено спустя 30 секунд:
>>И ControlBar - тоже это делает. Установите уже и проверьте!
Не смеши.