kojacek

Użytkownik forum
  • Postów

    252
  • Dołączył

  • Ostatnia wizyta

  • Wygrane w rankingu

    35

Treść opublikowana przez kojacek

  1. 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.
  2. 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...
  3. 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.
  4. 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.
  5. Jak rozumiem - dość gładko przeszliśmy od danych niegraficznych do brył?
  6. 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.
  7. 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?
  8. 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
  9. 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...:
  10. 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ę.
  11. 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:
  12. 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.
  13. 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...
  14. 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:
  15. 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:
  16. 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.
  17. Nie ma technicznych przeszkód, uniemożliwiających dołączenie kolejnej opcji typu Edytuj (pozwalającej zmienić dane istniejącego wymiaru XDIM), wydaje się jednak że powinno to odpowiadać rzeczywistemu zapotrzebowaniu użytkowników. Myślę że, jeśli zachodzi (nawet rzadko) taka konieczność, łatwiej jest [1] uzgodnić wymiar, lub [2] usunąć stary i narysować nowy. Chyba że istnieje takie zapotrzebowanie - wtedy można rozważyć rozszerzenie narzędzia. Początkowo przecież myślałem że te zabawy z wymiarem są jakąś marginalną i niszową sprawą, a okazało się że rozwiązanie może być przydatne. Co cieszy :)
  18. Wymiary XDIM po przeskalowaniu nie zmieniają wartości. Opcja Aktualizuj polecenia -XDIM, nadaje wymiarowi poprawną wartość (współczynnik / stała). Aby nadać nową wartość (współczynnik / stała) wymiarowi XDIM, można użyć opcji Uzgodnij, pobierając dane z innego wymiaru.
  19. Zatem papróbujta teraz. Zmiany: Zmienione zgłoszenie przy podaniu współczynnika Pobieranie ilości miejsc po przecinku ze stylu rysowanego wymiaru Poprawione działanie skalowania - bez względu na współczynnik skali w stylu wymiarowania, XDIM uwzględnia tylko rzeczywistą długość wymiaru Nadal bez obsługi błędów... ; =========================================================================================== ; ; XDim.lsp by kojacek ; ver. 16-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:-XDIM (/ m k) (setq m (_MsgData t) k (cd:USR_GetKeyWord (strcat "\nWymiar skażony " m) '("Rysuj" "Uzgodnij" "Aktualizuj" "Przywróć" "uStawienia" "Wyjdź") (if (not *XDIMDATA*) "Rysuj" (caddr *XDIMDATA*)) ) ) (cond ( (= k "Wyjdź")(princ "\nAnulowano. ")) ( (= k "Rysuj")(C:XDIM)) ( (= k "Uzgodnij")(C:XDIMMAT)) ( (= k "Aktualizuj")(C:XDIMREG)) ( (= k "uStawienia") (_SetupDim)) ( (= k "Przywróć")(C:XDIMRES)) (t (princ "\nAnulowano. ")) ) (if (/= k "Wyjdź") (setq *XDIMDATA* (if *XDIMDATA* (list (car *XDIMDATA*)(cadr *XDIMDATA*) k) ) ) ) (princ) ) ; ------------------------------------------------------------------------------------------- ; (defun C:XDIMRES ()(_RestoreTextDim 0)(princ)) (defun C:XDIMREG ()(_RestoreTextDim 1)(princ)) (defun C:XDIMMAT ()(_MatchDim)(princ)) (defun C:XDIM ()(_DrawDynDim)(princ)) ; ------------------------------------------------------------------------------------------- ; (defun _MsgData (Val / s) (setq s (cdr (assoc 271 (entget (tblobjname "DIMSTYLE" (getvar "DIMSTYLE")))))) (if (listp Val) (strcat "(Stała = " (cd:CON_Real2Str (cdr (assoc 1040 Val)) 2 s) " / Współczynnik = " (cd:CON_Real2Str (cdr (assoc 1041 Val)) 2 s) ")" ) (if *XDIMDATA* (strcat "(Stała = " (cd:CON_Real2Str (car *XDIMDATA*) 2 s) " / Współczynnik = " (cd:CON_Real2Str (cadr *XDIMDATA*) 2 s) ")" ) "(Brak ustawień)" ) ) ) ; ------------------------------------------------------------------------------------------- ; (defun _SetupDim (/ s m l k) (setq s (null (ssget "_x" '((0 . "DIM*") (-3 ("xDimTextReplacment"))))) m (_MsgData T) l (if (= m "(Brak ustawień)")'("Zmień") '("Zmień" "Resetuj")) k (cd:USR_GetKeyWord (strcat "\nUstawienia wymiaru skażonego " m ": ") (if s (append l '("Wyjdź"))(append l '("Pobierz z wymiaru" "Wyjdź"))) "Wyjdź" ) ) (cond ( (= k "Wyjdź")(princ "\nAnulowano. ")) ( (= k "Zmień")(setq *XDIMDATA* nil)(_SetGlobalData "uStawienia")) ( (= k "Resetuj")(setq *XDIMDATA* nil)) ( (= k "Pobierz")(_FromDimData)) (t (princ "Anulowano. ")) ) ) ; ------------------------------------------------------------------------------------------- ; (defun _FromDimData (/ i) (if (null (setq i (_GetSourceDim))) nil (progn (setq i (car i)) (setq *XDIMDATA* (list (cdr (assoc 1040 i))(cdr (assoc 1041 i))(caddr *XDIMDATA*) ) ) (princ (strcat "\nUstawienia: " (_MsgData t))) ) ) ) ; ------------------------------------------------------------------------------------------- ; (defun _MatchDim (/ i e d m sel en x) (if (null (setq i (_GetSourceDim))) nil (progn (setq e (last i) d (car i) m (_MsgData d) ) (redraw e 3) (while (and (setq sel (entsel (strcat "\n" m " Wybierz wymiar docelowy: "))) (not (null (setq en (car sel)))) (= (cdr (assoc 0 (entget en))) "DIMENSION") ) (_PutXDimData en (cdr (assoc 1040 d))(cdr (assoc 1041 d))) (setq x (cdr (cd:XDT_GetXData en "xDimTextReplacment"))) (_UpdateDimText nil en (cdr (assoc 1040 x))(cdr (assoc 1041 x))) (princ "Uzgodniono wymiar. ") ) (redraw e 4) ) ) ) ; ------------------------------------------------------------------------------------------- ; (defun _GetSourceDim (/ sel e d) (while (and (setq sel (entsel "\nWybierz wymiar źródłowy: ")) (not (null (setq e (car sel)))) (not (setq d (cdr (cd:XDT_GetXData e "xDimTextReplacment")))) ) ) (cond ( (not e) (princ "Nic nie wskazano. ") nil) ( (not d) (princ "Niewłaściwy obiekt. ") nil) (t (list d e)) ) ) ; ------------------------------------------------------------------------------------------- ; (defun _RestoreTextDim (Mode / sel e d) (while (and (setq sel (entsel "\nWybierz wymiar: ")) (not (null (setq e (car sel)))) ) (if (setq d (cdr (cd:XDT_GetXData e "xDimTextReplacment"))) (progn (cond ( (= Mode 0)(_UpdateDimText t e nil nil)) ( (= Mode 1)(_UpdateDimText nil e (cdr (assoc 1040 d))(cdr (assoc 1041 d)))) (t nil) ) (princ (cond ( (= Mode 0) "Przywrócono pierwotny wymiar. ") ( (= Mode 1) "Zaktualizowano wymiar. ") (t nil) ) ) ) (if (= (cdr (assoc 0 (entget e))) "DIMENSION") (princ "Wymiar nie jest skażony. ") (princ "To nie jest wymiar. ") ) ) ) ) ; ------------------------------------------------------------------------------------------- ; (defun _UpdateDimText (Mode Ent Con Fac / d x s l n nd) (setq d (entget Ent) x (entget (tblobjname "DIMSTYLE" (cdr (assoc 3 d)))) s (cdr (assoc 271 x)) l (_GetDimLin x (cdr (assoc 42 d))) ) (if Mode (progn (cd:XDT_RemoveXData Ent "xDimTextReplacment") (setq nd (subst (cons 1 "")(assoc 1 d) d)) ) (setq n (+ Con (* Fac l)) nd (subst (cons 1 (cd:CON_Real2Str n 2 s))(assoc 1 d) d) ) ) (entmod nd) ) ; ------------------------------------------------------------------------------------------- ; (defun _GetDimLin (Data Len / f) (setq f (cdr (assoc 144 Data)) f (if (not f) 1.0 f) ) (* (/ 1.0 f) Len) ) ; ------------------------------------------------------------------------------------------- ; (defun _PutXDimData (Ent VCon VFac) (cd:XDT_PutXData Ent "xDimTextReplacment" (list (cons 1040 VCon) (cons 1041 VFac) ) ) ) ; ------------------------------------------------------------------------------------------- ; (defun _SetGlobalData (Key / v1 v2) (if (not *XDIMDATA*) (progn (initget (+ 1 2 4)) (if (setq v1 (getreal "\nPodaj stałą wymiaru: ")) (progn (initget (+ 1 2 4)) (setq v2 (getreal "\nPodaj współczynnik: ")) (setq *XDIMDATA* (list v1 (if (not v2) 1.0 v2)(if Key Key "Rysuj")) ) ) ) ) ) ) ; ------------------------------------------------------------------------------------------- ; (defun _DrawDynDim (/ pt Cmd e el d n) (_SetGlobalData nil) (if (setq pt (getpoint "\nOkreśl początek pierwszej pomocniczej linii wymiarowej: ") ) (progn (setq Cmd (getvar "CmdEcho") e (entlast) ) (setvar "CmdEcho" 0) (command "_.DimLinear" pt) (setvar "CmdEcho" Cmd) (while (= 1 (logand (getvar "CmdActive") 1)) (command "\\") ) (if (eq (setq el (entlast)) e) (princ "Anulowano. ") (progn (_PutXDimData el (car *XDIMDATA*)(if (not (cadr *XDIMDATA*)) 1.0 (cadr *XDIMDATA*))) (setq d (cdr (cd:XDT_GetXData el "xDimTextReplacment"))) (_UpdateDimText nil el (cdr (assoc 1040 d))(cdr (assoc 1041 d))) ) ) ) (princ "Anulowano. ") ) ) ; ------------------------------------------------------------------------------------------- ; (princ "\nPolecenie -XDIM") (princ) Nowym kodem, należy zastąpić stary w całości.
  20. Masz rację - jest tak jak mówisz, to ja czegoś chyba nie dopatrzyłem, gdy sprawdzałem. Powtórnie przeanalizowałem i jest tak jak na malunku. Rozumiem tedy że powinno być zawsze tak: długość rzeczywista * współczynnik XDIM + stała XDIM Zatem to trzeba będzie poprawić. Druga rzecz to ilość miejsc po przecinku, tu wezmę ze stylu wymiarowania rzeczonego wymiaru, i trzecia - jeśli nie zdecydujecie inaczej, pozostanę przy niepomijaniu zer kończących. Tak?
  21. To można zrobić - ustawić tak jak ma styl wymiarowania. Inny problem w tej sytuacji to pomijanie zer kończących. Zwykle się je pomija, z tego co wiem przy tego typu "wymiarach skażonych", często się je zostawia. Więc powiedzcie jak to zrobić. Tylko ilość miejsc z wymiaru i niepomijanie zer (tak jak teraz) czy coś kombinujemy ponadto? Nie uważam tego za błąd - a wręcz przeciwnie. Wydaje mi się że użytkownik powinien zadbać o to aby wymiarować XDIM-em, wykorzystując styl bez skalowania długości. Albowiem sytuacja gdzie, rzeczywista długość jest już mnożona jednym współczynnikiem (ze stylu), a następnie kolejny raz mnożona przez nastawy użytkownika (w XDIM) może rodzić niejednoznaczności. Dlatego, jako zasadę przyjmuję że styl dla XDIM powinien mieć z natury współczynnik 1. Ale - jeśli uważacie że powinno się to zmienić - popatrzę ewentualnie jak to zmienić.
  22. 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.
  23. 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...
  24. No fakt, czasem można nie zauważyć, bowiem bajer jest o tyle chytry że, pojawia się jedynie gdy można go zastosować... Gdy w rysunku nie ma żadnych wymiarów skażonych, bajer nie jest widoczny... :)
  25. Aktualna stała i współczynnik, wykorzystywane są do bieżącego rysowania wymiarów i są w rysunku rzeczą ulotną. Po utworzeniu wymiaru dane są przypięte do obiektu. Po zamknięciu dokumentu, i ponownym otwarciu, konieczne jest ponowne ustawienie parametrów do rysowania, natomiast istniejące wymiary "pamiętają" swoje nastawy. W celu ustawienia parametrów do rysowania w oparciu o istniejące obiekty służy opcja Pobierz z wymiaru, w Ustawieniach. Pozwala to rysować skażone wymiary, z takimi samymi danymi co wymiar wskazany, po godzinie, miesiąciu, czy roku... ;)