Przechowywanie danych (nierysunkowych) w rysunku

[Martin_S]

a czy przydałaby sie też taka funkcjonalność ze nad opisami wymiarowania/wymiarem były by wyswietlane zmienne na tzw warstwie niedrukowalnej, wtedy było by jasne który wymiar podległ działaniu tego narzędzia i jakie zmienne były uzyte coś w stylu takim:

 

obrazki jako "analogia"

zmienne ujawnione na warstwie niedrukowalnej

 

ukryte (warstwa niedrukowalna wygaszona)

 

 

Wtedy nawet po roku po aktywacji tej warstwy wiadomo jakie zmienne były zastosowane.

[kojacek]

a czy przydałaby sie też taka funkcjonalność ze nad opisami wymiarowania/wymiarem były by wyswietlane zmienne na tzw warstwie niedrukowalnej, wtedy było by jasne który wymiar podległ działaniu tego narzędzia i jakie zmienne były uzyte coś w stylu takim:

 

obrazki jako "analogia"

zmienne ujawnione na warstwie niedrukowalnej

 

 

ukryte (warstwa niedrukowalna wygaszona)

 

 

 

Wtedy nawet po roku po aktywacji tej warstwy wiadomo jakie zmienne były zastosowane.

 

W mojej opinii nie. Mało tego, uważam że nie jest to dobry pomysł, w żadnej formie, a ten przedstawiony na obrazkach jest przykładem wręcz, jak tego nie robić. Uważam że powielanie tych samych danych, jest niepotrzebne a nawet szkodliwe. Domyślam się że "szpilki" mają osobne atrybuty na warstwie niedrukowalnej, wypełnione tymi danymi. Zastanówmy się co się będzie dziać gdy takich samych okiem mamy 100, i (nadal jednakowych) drzwi 200? Ano - mamy do każdego takiego samego (powtarzam) elementu dodatkowych 8 linii tekstu o takiej samej treści. Czas zadać pytanie - po co?

Zasadą powinno być jedynie odwołanie do jednego miejsca (np. Xrecord, w danych niegraficznych). Tych danych w rysunku (dla mojego przykładu) byłyby wtedy 2 typy 1 x okno + 1 x drzwi... zamiast 300 (100 okien + 200 drzwi)...

Wystarczy zdefiniować polecenie do "odpytania" wymiaru/okna/drzwi/czegokolwiek...

[Martin_S]

Własnie no bez przesady, ale wielokrotne uzycie tej samej pozycji skutkuje poprawną liczbą sztuk w tabeli zestawienia stolarki, a w ten sposób od razu widac na rzucie jak dana stolarka jest opisana, można alternatywnie podgladać te zmienne atrybutowe w okienku properties. Prosze też zrozumiec że na programowaniu CAD  nie znam sie całkowicie, ale ta metoda jest akurat wygodna i czytelna dla mnie. Poza tym te dane mają powiązania graficzne ze stolarką, i jak na razie od listopada 2013 nie było zastrzeżeń do tej funkcji dot. ZESTAWIENIA STOLARKI jako alternatywnej, uzupełniającej metody w ZWCAD ARCHITECTURE. Nie było chętnych do wykonania tego, ZWSOFT woli jak na razie swoją wersję anglosaską, pacyficzną.

[kojacek]

Własnie no bez przesady, ale wielokrotne uzycie tej samej pozycji skutkuje poprawną liczbą sztuk w tabeli zestawienia stolarki, a w ten sposób od razu widac na rzucie jak dana stolarka jest opisana, można alternatywnie podgladać te zmienne atrybutowe w okienku properties. Prosze też zrozumiec że na programowaniu CAD  nie znam sie całkowicie, ale ta metoda jest akurat wygodna i czytelna dla mnie. Poza tym te dane mają powiązania graficzne ze stolarką, i jak na razie od listopada 2013 nie było zastrzeżeń do tej funkcji dot. ZESTAWIENIA STOLARKI jako alternatywnej, uzupełniającej metody w ZWCAD ARCHITECTURE. Nie było chętnych do wykonania tego, ZWSOFT woli jak na razie swoją wersję anglosaską, pacyficzną.

 

Jestem nieprzekonany jeszcze bardziej... ;)

Wrzuć proszę (jeśli to nie problem) nawet ten jeden mały malunek (dwg) który pokazałeś na zrzutach. Jeżeli jest tak jak się domyślam, to w wolnej chwili spróbuję zrobić proste narzędzie, ilustrujące to o czym mówię. Jak się uda tak jak o tym myślę, potestujemy i zobaczymy co dalej.

 

[Martin_S]

Wybrałem 1 kondygnację i zrobiłem 2 zestawienia stolarki dla okien i drzwi (narzędzie do stolarki z nakladki e-cad drewno)

STOLARKA.dwg

 

 

miałem nadzieje ze ZWSOFT do ZWCAD ARCHITECTURE sie tym zajmie by zestawienia wygladały mniej wiecej tak

 

 

 

wiedząc jeszcze o wymaganiach rozporządzenia  z 2012r. i norm

 

a obecna wersja robi to tak

 

 

Sporo pisałem o tej problematyce tu:

http://www.zwsoft.com/forum/viewthread.php?tid=2972&extra=&page=2

 

i tu

 

http://forum.cad.info.pl/topic/815-co-warto-udoskonali%C4%87-w-zwcad-architecture/page-8

 

w postach z 21 i 30 listopada 2014, a dzis połowa czerwca 2014.

Edytowane 13 Czerwca 2014 przez Martin_S

[Martin_S]

Problematyka będzie służyła do programistycznego wbudowywania zmiennych w pliku DWG różnym obiektom CAD, by uzyskać efekt "pseudoBIM" by w przyszłosci mozna by konwertowac cały plik DWG z tymi zmiennymi w plik IFC *.ifc. Te zmienne atrybutowe na w/w przykładzie służą, póki co, do niezależnego zastawienia stolarki w pożądanym stylu nakładką na ZWCAD, zupełnie inaczej niz to robi oryginalnie program ZWCAD ARCHITECTURE. Dziekuję za przeniesienie wątku też.

[kojacek]

Zaczynamy zatem. Na początek ogólne uwagi. Nie wnikam w zasady działania nakładki wykonującej te zestawienia. Służą jedynie jako przykład. Niemniej uważam że, zastosowany przezeń model przechowywania pewnych danych, jest oględnie mówiąc zły. Z kilku powodów:

1. Dane które nie są danymi graficznymi (lub nie są wymagane jako elementy rysunku (wymiary/opisy)) są powielane wielokrotnie. To "nieekonomiczne" i całkowicie bezużyteczne. Nadmiarowość tych samych informacji jest szkodliwa ze swej natury.
   
2. Z uwagi na [1] dane mogą nie być spójne. Atrybuty w każdym wstawieniu bloku można w istocie przeedytować, w końcowym efekcie, traci się kontrolę nad tym które informacje są prawdziwe, aktualne, właściwe a które nie.
   
3. Pomimo tego że, dane przechowywane są w edytowalnych atrybutach bloków, ich świadoma edycja jest utrudniona (np. zmiana jednego opisu), wymaga (aby uniknąć [2]) przeedytowania wszystkich wystąpień.
   
4. "Atrybutyzacja" danych jest nieelastyczna. Sztywność polegająca na skończonej i ograniczonej liczbie atrybutów, nie pozwala na efektywne zarządzanie danymi.
   

Przedstawię tutaj sposoby przechowywania i manipulacji danymi niegraficznymi (takimi są tutaj opisy "szpilek" stolarki) w miejscach do tego przeznaczonych.

 

Kolejno wygląda to tak:

• W kopii rysunku STOLARKA.DWG, "wyczyściłem" wszystkie bloki "szpilek" ze zbędnych (w samej istocie przykładu) atrybutów. Inne atrybuty pozostawiłem (choć co do obecności niektórych mam swoje zdanie - ale to inna bajka).
  

Malunek poniżej ilustruje jak to wygląda:

 

[Martin_S]

W takim razie pokaże filozofię i idee działania tego modułu nakladki dotyczącego stolarki metodą graficzną , 

 

Dodam, że reprezentuję branżę konstrukcyjną (częściowo architektoniczną) i to był mój pomysł wdrożenia tego modułu, bo ZWCAD ARCHITECTURE nie robi zestawień wg formy

graficznej powszechnie stosowanej w Polsce.

 

 

Pierw wybieramy okno z etykietą do wstawienia

 

Wstawiamy etykiete do okna (opis zgodny z obowiązującymi normami)

 

Deaktywacja warstwy niedrukowalnej - graficznego nośnika danych w obszarze modelu

 

 

 

 

 

 

 

 

 

testowany plik DWG

stolarka01.dwg

 

P.S. Nie jestem programistą, jedynie przy moim wsparciu merytorycznym opracowano ten moduł z filozofią pracy tak jak

pokazałem mniej wiecej. Tak wydaje mi sie jest ergonomicznie, i mamy pełną kontrolę nad etykietami stolarki i

zestawieniem do niej. Zestawienie jest osobne do okien i osobne do drzwi.

 

Czy można to jeszcze ulepszyć? Jeśli @kojacek masz ciekawy pomysł to debatujmy w tym wątku.

Jaką branżę reprezentujesz?

 

 

 

[kojacek]

Póki co (nie odwołując się do dyskusji na temat programu zestawień), przedstawiam prosty, logiczny i konsekwentny (w mojej ocenie) sposób przechowywania danych niegraficznych w rysunku DWG.

 

Konstrukcja opisu stolarki polega z grubsza na stworzeniu symbolicznego oznaczenia typu (D1, D1L, ... OT1... itd), oraz dowiązaniu doń unikalnych danych opisowych (8-10 linii tekstu). Konstrukcja dla każdego symbolu nie jest niczym innym niźli najprostszym rekordem jakiejś bazy danych (tutaj stolarki). Mamy identyfikator, oraz jakąś ilość związanych z nim (podobnych) danych.
Schemat taki idealnie wpasowuje się konstrukcję rysunkowej bazy danych rysunku DWG/DXF. Twórcy AutoCAD-a przeznaczyli specjalne miejsca do przechowywania danych niegraficznych. Nazywają się słownikami (dictionaries) i wszystkie znajdują się w słowniku obiektów nazwanych (named object dictionary). Słowniki jako takie posiadają jedynie nazwę, oraz (zwykle) inne podrzędne obiekty, w których to można przechowywać dowolne dane niegraficzne.
W ten sposób zbudowane są grupy obiektów (ACAD_GROUP), tablice kolorów (ACAD_COLOR), skale (ACAD_SCALELIST) i wiele innych.

Kontenerem dostępnym dla końcowego użytkownika (programisty) służącym do przechowywania danych niegraficznych jest obiekt o nazwie XRECORD. Musi się on znajdować zawsze w jakimś słowniku. Może to być NamedObjDict, dowony słowni się w nim znajdujący, lub bezpośrednio słownik rozszerzeń obiektu - ExtensionDictionary. O tym wszystkim jednak później (jeśli kto ciekaw)
XRECORD jest obiektem którego struktura podobna jest do danych rozszerzonych (XDATA), jednak (w przeciwieństwie do nich) nie jest ograniczony nazwą aplikacji, ani wielkością czy kolejnością danych.
Dostęp do słowników i XRecord'ów możliwa z każdego dostępnego API - ja korzystam z AutoLISP.

Jak wcześniej wspomniałem - taki model - jest doskonałym miejscem do przechowywania danych naszych "szpilek". Ogólnie wystarczy mieć "swój" słownik, a w nim poszczególne XRecord-y (rozpoznawane przez symboliczne nazwy). W samych zaś XRecord-ach dane, które są liniami opisu stolarki.
Wygląda to tak (słownik + XRecord-y):

Natomiast dane w XRecord tak:

[Martin_S]

Czy zwykły użytkownik (bez wiedzy programistycznej) mógłby mieć możliwość rozbudowy własnej biblioteki okien i drzwi gdzie są magazynowane dane + symbol graficzny DWG okna/drzwi w widoku bocznym coś jak w tym 1 obrazku? Przy takim innym sposobie zaprogramowania?

 

Tam można rozbudowywać dane za wyjątkiem graficznego symbolu okna lub drzwi (stała biblioteka typowych 9 symboli okien lub drzwi w widoku bocznym)

 

Oczywiście po wstawieniu zestawienia , bloki graficzne stolarki można sobie podmienić jeśli jest mocno "nietypowa".

 

drzwiowa biblioteka domyslna wygąda tak

Edytowane 23 Czerwca 2014 przez Martin_S

[kojacek]

Uściślę bo się chyba nie rozumiemy. Ja mówię o przechowywaniu danych które są wykorzystywane w rysunku. Innymi słowy: masz w rysunku na przykład 2 typy okiem i 1 typ drzwi. I tylko tyle danych jest zapisane w rysunku. Czyli tylko 3 różne XRECORD. Dostawiasz nowy typ okna, jest dodany nowy XRECORD. W dwg nie przechowuję bazy stu tysięcy potencjalnych okien i miliona potencjalnych drzwi! Przecież to mijałoby się z celem.

 

Inną zaś sprawą jest program do wstawiania szpilek. Tu byłbym zwolennikiem aby on pobierał dane z dowolnego pliku np. ini, xml czy innego. Ten plik powinien być konfigurowalny przez użytkownika w dowolny sposób. Podobnie jak plik z rodzajami linii, czy stylami multilinii. Ale - to całkowicie osobna sprawa.

 

Ps. Mógłby mnie ktoś oświecić jak dodawać obrazki na forum, aby były cały czas widoczne. Ja dodaję jako załączniki (bo nie widzę innego sposobu) i są one widoczne jako ikony (niezalogowany). Jak widzę kolega Martin_S posiadł tę wiedzę i wstawia na dwa sposoby...

Edytowane 23 Czerwca 2014 przez kojacek

[Martin_S]

No jest w sumie niezależna baza w takich plikach tekstowych *.dat, ale chyba się też do końca nie rozumiemy, bo o programowaniu nie mam pojęcia, a wiem co chiałbym uzyskać.

Pod żadnym pozorem dany plik roboczy nie jest obciążony danymi na starcie, dane są zewnętrzne, nurtuje mnie jak zgrabnie powiązać te dane z widokiem bocznym stolarki DWG. Jest stała typowa biblioteka po 8-9 elementów, także mająca powiazanie z biblioteką DWG w specjalnym katalogu gdzie

 

przykład pliku DAT

 

baza danych graficznych

 

W ten sposób można rozbudowywać bibliotekę poprzez rozbudowę bazy DAT a symbol graficzny wskazać od 1 do 9,

 

Fajnie jakby było to mozliwe, tak przeprogramowac okno by bylo mozliwa rozbudowa o nowe symbole graficzne >9szt., bo baze DAT daje sie

robudowywać bez problemów, ogranicza Nas wbudowane, narzucone przeze mnie typowe 9 symboli graficznych do okien lub drzwi jak na w/w/ grafikach.

 

Widzę jedynie możliwość taką, zebranie innych symboli/bloków i autor nakładki sam to rozbuduje a grafiki bedą sie poziomo np. przewijały az  podpasują nam do tabeli zestawień. W przypadku nietypowym , kasuje sie grafike w tabeli i wkleja np. z elewacji lub przekroju. Nie ma problemu.

[kojacek]

No to jeszcze raz. Ja mówię o czymś kompletnie innym. Nie wiem, jak działa ta nakładka. Nie wiem czy można ją rozbudować, czy nie. To pytania nie do mnie.
Ja mówię na pewnym wyższym stopniu ogólności - o przechowywaniu danych niegraficznych w rysunku. Stolarka, jako taka, przywołana jest tutaj przypadkowo i to nie przezemnie. Natomiast jest - uważam - doskonałym przykładem, do ilustrowania problemu. Stąd pokazuję na jej przykładzie działania o których mówię. Miast wymyslać problem teoretyczny, działam na owej stolarce. Równie dobrze mogłyby to być inne elementy.

[Martin_S]

Spoko rozumiem, myślę, że na tym zakończymy ....   na  XRECORD

[kojacek]

Teraz dalej. Jak wcześniej mówiłem z bloków szpilek usunąłem wielokrotnie powielane dane (atrybuty UWAGI*). Dane zapisane są w XRECORD-ach, zaś kierunek dostępu do nich determinuje wartość atrybutu SYMBOL w bloku szpilki. Zauważmy że taki model pozbawiony jest wszystkich wcześniej wymienionych wad:

1. Dane nie są powielane. Występują w rysunku w jednym, ściśle określonym miejscu
2. Z powodu [1] dane są spójne.
3. Ewentualna edycja ogranicza się do jednego miejsca - zmiany danych w XRECORD
4. Dane w XRECORD nie są ograniczone. O ile ilość atrybutów determinowała ilość danych, tak w XRECORD, nie ma takich ograniczeń. Ponadto dane nie muszą być danymi tylko tekstowymi.

W łatwy sposób można "dobrać" się do informacji przez wybór szpilki:

 

[kruszynski]

Witam

Wiem jak korzystać z XRecord przez LISP. Natomiast większość Użytkowników (jeśli nie wszyscy ) którzy nie są programistami może mieć problem z pozyskaniem informacji z XRecord. O ile wiem, a mogę się mylić bo nie sprawdzałem, ZWCAD nie ma okienka, które pozwala na przeglądanie XRecord. Oczywiście można to oprogramować, ale co pozostaje Użytkownikowi nie programiście? Jak korzystać tak krok po kroku z opisanej przez Pana metody wykorzystującej XRecord?

Zastanawiam się czy alternatywnym rozwiązaniem nie byłoby korzystanie z niewidocznych lub ustalonych atrybutów bloku. Wiem że dane będą powtórzone, ale nie będą wyświetlane a będzie możliwy dostęp do nich. Dawno nie korzystałem z tego ale chyba właśnie atrybuty ustalone zapisywane są tylko w definicji bloku a nie we wstawionym bloku, wówczas informacje nie byłyby powielane.

Pozdrawiam

[Martin_S]

@kruszynski , dziekuję za komentarz, w pewien sposób próbujesz zrozumieć kreślącego (nieprogramiste), ja jako nieprogramista (jak znaczna wiekszość) tak  mi sie wydawało, że każdy jest wstanie to opanować jak na w/w obrazkach, jak na razie to działa i po 7 miesiacach nie było sygnałów od użytkowników-nieprogramistów, że tego "nie kumają".

 

A skoro są lepsze metody na ogarniecie podobnej tematyki to tylko lepiej, bo można utworzyć jeszcze lepsze narzędzia wspomagające kreślenie CAD.

[kojacek]

Oczywiście że, musi to być oprogramowane w jakiś sposób. Ale mówimy o automatyzacji wszak. Te "zatrybutyzowane" szpilki przecież też są. Przykładowe tutaj rysunki w innych częściach także są w jakiś sposób oprogramowane. Spójrzmy na rysunek w przykładzie. Ściany są oprogramowane, okna, drzwi tak samo. Użytkownik nie mający dostępu do źródłowej aplikacji (tak jak ja) "widzi" je jako ACAD_PROXY_ENTITY. Oczywiście nie może też ich edytować. Skoro nie może tych elementów, w takim razie po co miałby mieć taką możliwość w odniesieniu do opisów stolarki? Mało tego, do oprogramowania tegoż, wystarczy zwyczajny prosty nieskomplikowany LISP. Wczytanie paru linijek kodu, kogoś zaboli?

 

Co do atrybutów stałych, podchodzę do tego sceptycznie ze względu na utrudnioną edycję (każdorazowa redefinicja bloku). Ponadto wymagać to będzie osobnego bloku dla każdego typu zdaje się.

[Martin_S]

No właśnie sugerowałem ZWSOFT by była mozliwość rozbudowy okna stolarki w ZWCAD ARCHITECTURE, bo to jak piszesz tzw.  źródlowa aplikacja

 

cos w tym stylu  (ale myślałem po swojemu , nadal wtedy)

 

 

p.s. pomijam specyficzny sposób opisywania etykiety stolarki w Polsce , obowiązujacy wg norm krajowych , zupełnie inaczej niż na całym świecie

tak jak robi to GRAPHISOFT, AUTODESK, BENTLEY. Zawsze musimy być oryginalni ;)

Edytowane 23 Czerwca 2014 przez Martin_S

[kojacek]

No i tutaj jest pełna zgodność w całości ogółu. Różnica jedna - ale to w szczególe (choć istotnym) - jest taka że to co zaznaczone na Twoim obrazku na niebiesko trafia do atrybutów, zaś ja uważam (ponadto) że to (co zaznaczyłem na pomarańczowo) powinno (z wielu już wczesniej prezentowanych powodów) lądować w "moim" XRECORD-zie...:

[Martin_S]

Po wydaniu świeżej wersji ZWCAD ARCHITECTURE SP2 twierdzę (dzieki komendzie S41_XJJX tzw. Power Rectangle/Super Prostokąt) że Chińscy programiści z ZWSOFT są już praktycznie gotowi do tworzenia sparametryzowanych skomplikowanych obiektów 2D/3D z dużą liczbą niezbędnych zmiennych.

[kojacek]

By gołosłownym nie być, ćwiczenia do treningu działania. Plik STOLARKA2.DWG (w załączeniu) oraz (poniższy) kod lispowy.

; =========================================================================================== ;
; Stolarka.lsp by kojacek
; ver. 17-06-2014
; Wymaga biblioteki: CADPL-Pack-v1.lsp  <http://forum.cad.pl/cadpl-pack-v1-lsp-t78161.html>
; =========================================================================================== ;
(if (not cd:ACX_ADoc)(load (findfile "CADPL-Pack-v1.lsp")))
; ------------------------------------------------------------------------------------------- ;

(defun C:STOLINFO (/ x r e d a n l i j)
  (if
    (setq x
      (cd:DCT_GetDictList (setq r (cd:DCT_GetDict (namedobjdict) "Arch-Std-Stolarka")) nil)
    )
    (while
      (and
        (setq e (car (entsel "\nWybierz opis stolarki: ")))
        (setq d (entget e))
        (= (cdr (assoc 0 d)) "INSERT")
        (wcmatch (cdr (assoc 2 d)) "e-cad*_1_?")
      )
      (if
        (and
          (setq a (cd:BLK_GetAtts e))
          (setq n (cdr (assoc "SYMBOL" a)))
        )
        (if
          (member n x)
          (progn
            (setq i (_GetAttValueInsert n)
                  l (cd:DXF_Massoc 1 (cd:DCT_GetXrecord (cdr (assoc n (cd:DCT_GetDictList r T)))))
                  j (if i (itoa (length i)) "0")
                  l (mapcar '(lambda (%)(strcat "\n" %)) l)
            )
            (alert
              (strcat (cdr (assoc "NAZWA" a)) " [" n "] (sztuk: " j ")\n"
                (apply 'strcat l)
              )
            )
          )
          (princ "\nNie znaleziono informacji. ")
        )
        (princ "\nNie znaleziono informacji. ")
      )
    )
    (progn "\nW rysunku nie ma danych stolarki. ")
  )
  (princ)
)
; ------------------------------------------------------------------------------------------- ;
(defun _GetAttValueInsert (Val)
  (vl-remove-if
    '(lambda (%)(/= % Val))
    (mapcar
      '(lambda (%)(cdr (assoc "SYMBOL" %)))
      (mapcar
        '(lambda (%)(cd:BLK_GetAtts %))
          (cd:SSX_Convert (ssget "x" (list '(0 . "INSERT")'(2 . "e-cad*_1_?"))) 0)
      )
    )
  )
)
; ------------------------------------------------------------------------------------------- ;
(princ "\nPolecenie: STOLINFO")
(princ)

1. Potrzebna jest bliblioteka CADPL-Pack, którą można pobrać stąd: http://forum.cad.pl/cadpl-pack-v1-lsp-t78161.html
2. Powinna ona znajdować się w ścieżce poszukiwań.
3. Kod należy skopiować do pliku (stolarka.lsp) i załadować.
4. Dostępne jest polecenie STOLINFO, po wywołaniu należy klikać w "szpile" okien & drzwi

Pokazuje to jedynie w prosty sposób mechanizm działania. Prawdziwe makro mogłoby oprócz przeglądania np. pozwolić edytować dane. Zauważcie że można w łatwy sposób "wyłączyć" jakieś elementy. Wystarczy zmienić w atrybucie SYMBOL szpilki, wartość (np. dodać dowolną literę) i już nie jest ona brana pod uwagę. Potestujcie. Ciekaw jestem waszych uwag.  

STOLARKA 2.dwg

Edytowane 24 Czerwca 2014 przez kojacek

[Martin_S]

OK działa

 

Dziękuję za poświęcenie czasu na to zagadnienie, ale moje uwagi zaraz opiszę, z punktu widzenia ARCHITEKTA, który nie ma pojęcia o lispach/programowaniu ale kreślić juz umie i wie co to panel własciwości (CTRL+1) ....

 

 

Osobiście wolę metodę z atrybutami , bo ją "czuję" i rozumiem jako nieprogramista, i te bloki atrybutowe mogę modyfikować, zmieniać bez wpływu na mechanizm zestawiania stolarki, raczej bym rozbudował bibliotekę symboli graficznych do zestawienia, bo 8-9 typowych  to za mało jednak.

 

Polecenie STOLARKAINFO działa wyraźnie ale podobny szybki efekt daje CTRL+1 z mozliwościa edycji "online" oraz edytor atrybutów.

 

 

Jeśli kreślący nie widzi w inny sposób tych danych , po pewnym czasie "zagubi sie" i zapomni o stolarka.lsp a dzieki CTRL+1 w panelu bocznym od razu wiadomo o wszystkich zmennych dla danej etykiety(szpilki).

 

Ten lisp traktuję jako dokształcenie siebie, że pewne rzeczy mozna robić alternatywnie, kwestia przyzwyczajenia do takiej technologii.

Ja metodologię atrybutową używam od wielu lat bo jest jasna dla nawet początkujących.

Edytowane 24 Czerwca 2014 przez Martin_S

[perlon]

Chciałbym zauważyć, że owszem atrybuty można "ręcznie" pozmieniać, ale jaki sens praktyczny mają takie atrybuty bez odpowiedniej aplikacji? Po to wprowadza się dane dodatkowe, żeby w końcowym rozrachunku uzyskać jakieś zestawienie za pomocą jakiegoś programu. Jest nakładka e-cad oparta o odczytywanie danych z atrybutów, jest lisp "stolarka.lsp" do odczytywania danych XDATA. Wprawdzie do edycji atrybutów można użyć standardowych narzędzi a do edycji XDATA trzeba czegoś więcej, ale żeby wyciągnąć sensowne zestawienie bez jakiejś aplikacji się nie obejdzie. ARCHITEKT będzie potrzebował jakiejś aplikacji bo po grzyba mu setki okien dokładnie opisanych "co do zawiasu i grubości uszczelki" w atrybutach jak nie będzie miał maszynki która to porówna, posortuje i wypluje w postaci ładnego zestawionka?

Podejście kolegi kojacek jest o tyle słuszne, że jest zgodne z ideą normalizacji i unikaniem redundancji ( nadmiarowości ) w bazach danych. Wszak plik dwg jest jakąś bazą danych i zastosowanie w niej mechanizmów i ogólnych zasad rządzących bazami danych z zastosowaniem relacji jest jak najbardziej uzasadnione. Lepiej jest do poszczególnych obiektów graficznych przypisywać referencję ( wskazanie ) na komplet danych dokładnie opisujący danych obiekt niż przypisywać mu taki komplet w całości powielając te dane po wielokroć. W ostatecznym rozrachunku i tak będzie potrzebna jakaś aplikacja która dane z tej bazy jakoś obrobi. Dlatego argument że architekt nie umiejący programować nie da rady sobie z XDATA a poradzi sobie z atrybutami uważam za chybiony. Z atrybutami też sobie nie poradzi bo standardowymi narzędziami zestawienia nie zrobi.

[Martin_S]

Ooops, to ja szczerze wycofuje się z debaty, bo nie znam się na programowaniu, wymiękam już :hi: ,  zależy mi jedynie by były dopracowane użyteczne i ergonomiczne narzędzia, a jak będą opracowane to nie będę wnikał. jak narazie moja opinia o ZWCAD ARCHITECTURE SP2 jest dużo bardziej pozytywna od SP1. Pozostanie zaprogramować skomplikowane zagadnienie związane z 3D tzn AcDbSubDMesh Class oraz podrasowanie komendy S41_LJQM, bo obecna S41_XJJX mi sie b. podoba choć też wymagała by ulepszenia.

 

p.s. z takim laikiem jak ja nie dogadacie się chyba :)