kojacek

Kombinator. Z tej samej bajki co kombinerki i kombinezon... :)

Dziś dziecinnie prosty... :)

Aparat do robienia chmury punktów. Bezsprężynowy... ;)

Dobre! Gratulacje! Też coś kombinowałem na początku z tym T, ale coś takie mało teowate mi się zdałowało, więc zarzuciłem... :)

Dzięki :) To samo, nieco inaczej:

Piernik?

Służyło się... w lotnictwie... ;) to się wie... :)

ORP Władysławowo w Kołobrzegu?

Jedynym problemem jaki widzę, to prawidłowy wybór obiektów. Myślę jednak że 8-10 linijek rozlazłego kodu LISP-owego, załatwiło by sprawę.

To jest dokładnie taka sama zabawa jak już wcześniej wspominane nieszczęsne zestawienie stolarki (atrybutyzacja vs. xrecordowanie). Właściwie nie ma różnicy czy obiekt jest dwu czy trójwymiarowy. Problemy z zarządzaniem tymi danymi będą podobne. W mojej opinii, najbardziej optymalnym rozwiązaniem jest przypisywanie do obiektu tylko tych danych które są dla niego unikalne (idntyfikatory), lub są konieczne (vide: wymiary stolarki w szpilce). Wszelkie inne, powinny być przechowywane, albo na zewnątrz (w osobnych plikach (tekstowych xls-ach, db-ach, mbd-ach itp.)), albo jako dane niegraficzne czyli słowniki + xrecordy + itp. w rysunku. Oczywiście - w zależności od potrzeb - możliwe rozwiązania mogą być również mieszane.

Nie, nie ma za co przepraszać, po prostu zabrzmiało to mocno konkretnie, zatem zapytałem :) Na marginesie moją wiedzę "programistyczną" trzeba traktować raczej amatorsko i hobby-stycznie. Wynika ona jedynie z długowiecznego obcowania ( ;) ) z CAD-em...

Nie rozumiem formy "stosujecie" - bowiem sugeruje ona jakieś konkretne rozwiązania. Funkcjonalność o której mowa, może być realizowana na co najmniej kilka różnych sposobów. Identyfikacja obiektu - tak samo, może polegać na typowych identyfikatorach rysunkowych, jak też własnych (np. przez dowiązanie XDATA czy ExtensionDictionary). To też może determinować sposób przechowywania innych danych, np. w samym obiekcie, lub w osobnym słowniku (-ach), a jedynie "adresowanie" do niego identyfikatora obiektu. Możliwych rozwiązań jest naprawdę wiele.

Zwyczajnym LISP-em: (vl-load-com) ; ------------ (defun _Get3DSolid (Hand / e) (if (and (setq e (handent Hand)) (= (cdr (assoc 0 (entget e))) "3DSOLID") ) (vla-get-volume (vlax-ename->vla-object e)) ) ) Potem wywołanie: (_Get3DSolid "404f7") i masz.

Jak rozumiem - dość gładko przeszliśmy od danych niegraficznych do brył?

No ale cała ta dyskusja wynika z tego że można coś ułatwić. W mojej opinii (i tu widzę też podobne głosy), całe to zestawienie, opisy stolarki (i co tam tego tyczy dookoła) można zrobić nieco inaczej, ale za to w konsekwencji, w sposób bardziej uporządkowany i logiczny. Przecież nie upieram się żem alfa i omega, niemniej kilka rzeczy można ulepszyć, zdejmując z użytkownika potrzeby weryfikowania, sprawdzania i korygowania błędów, jeśli wystąpią. Przy czym, z mojej strony, nie jest to jakieś wielkie programowanie, jeno hobbystyczne zastosowanie LISP-a.

Ja tam sobie myślę, że nie ma co się unosić - póki gadamy to się dogadujemy :) @perlon - gwoli sprostowania: Nie stosuję tutaj XDATA. XDATA to dane dodatkowe, tutaj mówimy o danych niegraficznych. XDATA rzeczywiście są wykorzystywane, ale w wątku obok (http://forum.cad.info.pl/topic/1114-wymiar-z-dodan%C4%85-sta%C5%82%C4%85-warto%C5%9Bci%C4%85/page-3#entry6547) dotyczącym wymiarów "skażonych". Na marginesie, tutejszy wątek "wyrósł" z tamtego. Ponadto pozwolę sobie zauważyć - dogadywanie się tam laików, zaowocowało całkiem zgrabnym narzędziem, mam nadzieję przydatnym. Kto wie, może tutaj też się coś zrobi?

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) Potrzebna jest bliblioteka CADPL-Pack, którą można pobrać stąd: http://forum.cad.pl/cadpl-pack-v1-lsp-t78161.html Powinna ona znajdować się w ścieżce poszukiwań. Kod należy skopiować do pliku (stolarka.lsp) i załadować. 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

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...:

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ę.

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: Dane nie są powielane. Występują w rysunku w jednym, ściśle określonym miejscu Z powodu [1] dane są spójne. Ewentualna edycja ogranicza się do jednego miejsca - zmiany danych w XRECORD 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:

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.

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...

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:

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: 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. 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. 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ń. "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:

Pozostawiając wątek wymiarów XDIM do dalszej ewentualnej dyskusji, powrócę do pobocznego tematu jaki się tutaj przy okazji pojawił. Na przykładzie rzutów architektonicznych, zaprezentowanych przez Martin_S'a, rozpoczęliśmy dyskusję na temat przechowywania danych (nierysunkowych) w rysunku. Aby nie zaśmiecać dyskusji wymiarowej, Administratora czy Moderatora proszę o założenie nowego wątku na ten temat. Następnie o przeniesienie doń tego, oraz postów #37-#41 z tego wątku. Gdy taki wątek powstanie, rychło przedstawię alternatywny (do przezentowanego) sposób zapisywania danych, wykorzystując do tego dane niegraficzne rysunkowej bazy danych. Według mnie sposób lepszy niż wielokrotne powielanie tych samych danych w atrybutach bloków. Manipulować danymi będziemy za pomocą (oczywiście) LISP-a.