2P

Z tematem edycji bloków związane są jeszcze inne błędy - niedopracowania: 1. W przypadku bloków zagnieżdżonych w okienku do wyboru bloku do edycji (czy to edycji w rysunku, czy edycji osobno) powinien być domyślnie ustawiony blok bezpośrednio kliknięty (zagnieżdżony), a nie zawsze blok główny. Pracujemy na strukturze drzewiastej zagnieżdżonych bloków, bez tej opcji wejście w edycję głęboko zagnieżdżonego konkretnego bloku w konkretnym miejscu rysunku i to jeszcze gdy występuje on kilkadziesiąt razy w bloku nadrzędnym jest koszmarem! Plisssssss poprawcie to! Albo jakieś rozwiązanie alternatywne. 2. Okienko wyboru bloku do edycji nie zapamiętuje rozmiaru po przeskalowaniu i kolejnym jego otwarciu. Uciążliwe gdy operuje się na drzewie bloków.

Testuję ZW2018 SP1 VERNUM = "2017.12.05(24685)_Win32" Z przykrością stwierdzam, że od lat widać, że nikt z producentów nie testuje programu z ustawieniem białego tła roboczego. Już zaczynam się obawiać, że w którejś kolejnej wersji zlikwidują możliwość zmiany tła - oby nie. Bo trzeba będzie się pożegnać z ZW. Ale do rzeczy: Nadal jest błąd ustawiania warstwy na Lock. Obiekty na takiej warstwie robią się ciemniejsze, a w przypadku białego tła powinny robić się jaśniejsze. Te sam błąd był kiedyś w ZW plus, ale poprawili - teraz poprawka idzie opornie. Poprawiono natomiast analogiczną sytuację przy edycji bloku (w rysunku). W trakcie edycji bloku reszta rysunku na białym tle się rozjaśnia, a nie jak jeszcze niedawno zmieniała kolor na dopełniający. Czy jest możliwość ustawienia koloru tłą interfejsu użytkownika. Ten ciemny pasuje do Lightroomu, a nie do cada (jak dla mnie) Szczegołnie jak ktoś pracuje na jasnym tle (białym) kontrast między tłem pracy a interfejsu jest męczący. Zresztą nawet jak ktoś pracuje na standardowym kolorze, to wg mnie wyskakujące okienka, które są jasne męczą oczy. Czy jest więc jakaś możliwość zmiany koloru ekranu? Pamiętam, że były kiedyś wersje ZW z predefiniowanymi różnymi kolorami tła - to było fajne!

Wskazany przez przedmówcę sposób działania wersji 2015 dotyczy wszystkich wcześniejszych wersji zwcada z jakimi miałem doczynienia (od 2006). Zmieniło się to dopiero w wersji 2017 i jest bardzo uciążliwe....

WOW! Tak to jest to! Wreszcie przestanie mnie to irytować. Ale uważam, że domyślnie powinno być ustawione "Dokładnie", a nie "Przynajmniej"! Dziękuję

Jak przenieść Layouty z jednego rysunku do drugiego? Chodzi o ustawienia arkusza, drukarki, a przede wszystkim rzutni i innych elementów narysowanych w przestrzeni papieru. Jest jakaś komenda eksportu i importu? VERNUM = "2017.01.23(13656)_x64" (tylko do odczytu)

Tak, ale jak wyłączy się ramkę, to ramka nie przykrywa wtedy linii pod spodem. Można nadać dowolny kolor ramce WIPEOUTA, ale nie jest to kolor o parametrach tła.

Wystarczyłoby, żeby obwód WIPEOUTa mógł być w tym samym kolorze co wnętrze WIPEOUTa, które właśnie automatycznie przybiera kolor tła. A mnie udało się opanować WIPEOUTy i to jest genialne narzędzie do minimalizowania pracy i łatwej edycji projektu.

Rozbicie bloków wchodzi w grę (ale niechętnie), tyle że jeszcze atrybuty trzeba na teksty zamienić. Ogólnie wszystko to co napisaliście robi eksport do DWF. I byłbym z tego bardzo zadowolony gdyby nie dwie cechy eksportu do DWF psujące wszystko: 1. Dokładność. A raczej zaokrąglanie współrzędnych, czyli traci się dokładność narysowanych elementów (szczególnie łuków) 2. WIPEOUT zamienia na kreskowanie solid i to w złym kolorze.

Tyle że mnie chodzi o eksport fragmentu rysunku. A np. blok jest wielki na cały rysunek, a w eksporcie powinien się znaleźć tylko fragment bloku.... WBLOCK może wyeksportować cały blok, a nie jego część.

Podobnie jak w poprzednich wersjach ZWcada, tak również w 2017 występuje błąd, który zgłaszałem już dawno. Polskie literki typu ŻŹĆ, czy nawet niektóre znak specjalne wyższe niż znaki standardowe rozpychają linijki tekstu. Wszystko widać na rysunku .

Tylko pomysł z PDFem spełnia moje wymogi. Ale częściowo. Bo PDF ma swoją dokładność i elementy tracą swoje dokładne współrzędne. Jest to co z opisanym przez mnie wyżej wykorzystaniem DWF, tylko gorzej. Reszta pomysłów (WBLOCK, XREF, przysłanianie) nie spełnia podstawowego zadania jakim jest obcięcie i fizyczne NIE zamieszczenie w tym (albo innym) rysunku. Mi chodzi o to, aby taki wyeksportowany fragment DWG mógłby być wysłany innym bez możliwości podejrzenia reszty rysunku. WBLOK, XREF, przysłanianie, rzutnie - wszystko pozwala innym na dostęp do całego rysunku.....

Pomysł z wykorzystaniem koloru tła już od dłuższego czasu wykorzystuję. Chodzi o przysłanianie jednych elementów drugimi elementami (w kolorze tła). Wykorzystuję to do specyficznego rysowania otworów w ścianach. W załączeniu rysunek. Narysowane jest to tak, że ściany (w tym kreskowanie) narysowane jest tak jakby nie było otworów drzwiowych czy okiennych. Następnie wstawione są bloki okien i drzwi, które przysłaniają element ściany. W bloku jest WIPEOUT przysłaniający kreskowanie. I wszystko byłoby ok, gdyby nie to, że obwód wipeouta nie ma grubości linii, a więc przy nałożeniu samego prostokątnego wipeouta na ścianę połowa grubych linii od ścian wystaje poza wipeout i jest widoczna. Mam więc to rozwiązane takie, że linie grupę ścian przykrywane są nie tyle przez wipeout, ale przez inne grube linie w kolorze tła. Te linie znajdują się na odpowiedniej warstwie, której kolor mam ustawimy na 255,255,255. Wszystko działa. Dzięki temu okna i otwory łatwo przesuwać, zmieniać, kreskowanie jest na stałe i bez jakiś dodatkowych nakładek i LISPów jest dobra obsługa otworów w ścianach. itp I teraz w czym jest problem. Otóż w czasie moje i mojego biura pracy w niczym. Ale jeśli rysunek przekazuję komuś poza biuro, to jeśli ktoś pracuje na innym kolorze tła niż biały to otwory nie wyglądają dobrze do czasu, aż inny projektant nie zmieni sobie warstwy dla linii przykrywających na kolor swojego tła. Jeśli jest on inny niż biały, to przed wydrukiem kolor tej warstwy należny znów zmięć na biały... Mało wygodne i mało kto obcy rozumie moją ideę rysowania z przesłanianiem. W biurze mam LISPa zmieniająca kolor tła i warstwy dla linii przykrywających automatycznie, ale zewnętrzni projektanci tego nie mają. Gdyby było coś takiego jak kolor_tła sprawa była by prosta, a rysunek stworzony z elementami przysłaniającymi otwierany na dowolnym komputerze z różnym kolorem tła wyglądałby tak samo.

Czy jest coś takiego jak kolor tła, który można nadać elementowi? Element rysunkowy może być w jakimś kolorze, możne być jak_warstwa, jak_blok, a czy może być jak_tło??? Coś jak wipeout... Wpadli na to w autodesku, że to może być przydatne? A może w ZWsoft sam wprowadzi taką funkcjonalność.... =2P=

Poszukuję rozwiązania na pytanie jak wyeksportować fragment rysunku DWG. Zadanie jest takie: Mam duży skomplikowany rysunek, pełen zagnieżdżonych bloków, atrybutów i skomplikowanej struktury warstw. Chciałbym wygenerować/wyexportować/zapisać (??) fragment (określony prostokątem) tego rysunku do pliku DWG. Spróbowałem drukować do formatu DWF i ponownie wczytać do ZW. Niby ok, ale przy powiększeniu łuki się rozsypują, litery koślawią. Rozumiem, że wynika to z rozdzielczości. Później wyeksportowałem do DWF. Efekt lepszy - pewnie wyższa rozdzielczość. Ale np. grubość ściany nie jest już 25cm, a 25,02... Tworzą się dziwne końcówki. Dodatkowy problem, że wczytywany DWF to blok, którego nie można rozbić, a tu chodzi, żeby na takim wycinku pliku dalej normalnie pracować (bez dych końcówek po przecinku). Nie interesuje mnie rozwiązanie z przycinaniem (maskowaniem) bloku zawierającego cały rysunek. Macie jakiś pomysł jak wytworzyć taki DWG z fragmentem rysunku???

Witam! VERNUM = "2017.01.23(13656)_x64" (tylko do odczytu) Wersja 2017 zachowuje się inaczej niż 2015. Chcąc wejść w edycję bloku klikam dwa razy na blok. Jeśli kliknąłem na blok znajdujący się w innym bloku, to w okienku na liście do wskazania bloku do edycji, powinien domyślnie być zaznaczony blok który klikałem, a nie ten na szczycie "drzewka" zagnieżdżonych bloków. Tak było w 2015, ale nie jest już w 2017. Jest to wbrew pozorom, bardzo istotny błąd bardzo utrudniający pracę tym, którzy pracują na dużych ilościach wielokrotnie zagnieżdżonych bloków. Ciężko odszukiwać na liście bloku o którego edycję nam chodzi. Przy okazji jest jeszcze widoczny drugi drobny błąd. Wielkość okienka prezentującego zagnieżdżoną strukturę bloków nie jest zapamiętywana i za każdym otwarciem pojawia się w za małym standardowym rozmiarze.

To bardzo irytujący błąd. Szczególnie jak chce się ustawić oś X równolegle do jakiejś linii istniejącej w rysunku a nie przechodzącej przez punkt 0,0 :( Pozdr

U mnie to wygląda ta: 1. screen normalnie, 2 screen w trybie edycji. Jak widać kreskowanie, wymiary w zupełnie innych kolorach. Przy okazji widać tu drugi błąd: meble są na czarno, a powinny być również wyszarzone.

Już sobie jakoś poradziłem. Przy okazji oczyściłem trochę kodu ze zbędnych rzeczy. Przechodzę do analizy dalszych funkcji, które nie chcą działać z v2017

Ponieważ nie do końca jestem pewien, czy mnie Państwo zrozumieliście, to wrzucam screen z 2017 i 2015. Na rysunku te 5 kresek to blok. W definicji bloku mamy tak, że 3 kreski umieszczone są na warstwie 0, a dwie na warstwie Layer1 Wszystkie narysowane są jako czarne!. Blok umieszczony jest na warstwie 0. Warstwa 0 zostaje zablokowana - kłódką. Ponieważ blok znajduje sie na 0, to powinien on CAŁY! się wyszarzeć (jak w v2015), a nie tylko te elementy które leżą na warstwie 0. W v2017 te dwie czarne kreski leżą w bloku na warstwie Layer1..... i nie zostały wyszarzone.

VERNUM = "2017.01.23(13656)_x64" W v2017 jest błąd wyświetlania elementów rysunku znajdujących się na zablokowanej warstwie (kłódka). Elementy znajdujące się na warstwie zamkniętej powinny wyświetlać się jako ciemniejsze (lub jaśniejsze jeśli pracujemy na białym tle). I tak się dzieje z jednym wyjątkiem. Jeśli mamy blok, a w nim elementy zdefiniowane na innych warstwach niż 0, to na te elementy nie działa LAYLOCKFADECTL i mimo, że blok mamy wstawiony na warstwę zamkniętą (właściwości dla bloku ByLayer) to elementy tego bloku nie są "wygaszone". To błąd. Proszę o zgłoszenie poprawki, żeby działało to tak jak w poprzednich wersjach ZW Zdaję sobie sprawę, że dla większości nie ma to znaczenia i pewnie ktoś napisze, że w bloku wszystkie elementy powinny być definiowane na warstwie "0", ale ja mam odmienne zdanie na ten temat i w olbrzymim stopniu wykorzystuję korzyści jakie daje możliwość definiowania elementów w jednym bloku na różnych warstwach.

Chylę przed Tobą czoła kojacek! WIELKIE DZIĘKI! " do czasu gdy żółte rączki go nie naprawią" jest to rozwiązanie problemu i to bez konieczności grzebania w całym kodzie nakładki. Dołączyłem CADPL-Pack'a i dopisałem taką definicję funkcji, co załatwiło ten problem. (defun vlax-ldata-put (dict key data) (cd:ENT_SetDXF (cd:DCT_GetDict (cd:DCT_GetDict (namedobjdict) dict) key) 300 (vl-prin1-to-string data)) ) Załatwiło ten problem, ale oczywiście już znalazłem kolejne niekompatybilności v2017 (nie tylko w LISPie)... o czym w innych wątkach... Pozdrawiam Edit: Niestety rozwiązanie powyższe nie działa z listami typ pary "kropkowe" :(

Plik_1 - dane LDATA zapisane w v2017 Plik_2 - dane LDATA zapisane w v2015 Efekt działania (vlax-ldata-list "TEST") w obu wersjach ZW: v2017, Plik_1: v2017, Plik_2: v2015, Plik_1: v2015, Plik_2: Jak widać błąd tkwi w procedurze zapisu LDATA w v2017.

LAYLOCKFADECTL= 50

Zrobiłem test zapis - odczyt, ale bez CADPL-Pack'a. 1. Na początek w v2015 zapisałem dane LDATA. Potem ten plik otworzyłem w v2017 i odczytałem LDATA - wynik prawidłowy, dane nie zmienione. 2. W v2017 zapisałem dane LDATA, a potem ten plik otworzyłem w v2015 i odczytałem dane LDATA - wynik błędny, dane zmienione.... Jednym słowem niestety błąd jest przy zapisie :( nie odczycie danych. A nakładka działająca pod v2017 wręcz może uszkodzić bezpowrotnie dane!!

Trafiłem na poważny błąd w działaniu vlax-ldata-put / get. Poważny dla mnie bo totalnie rozwalił mi działanie mojej nakładeczki i nie mam pomysłu jak to obejść. Proponuję wykonać taki kod na v2015 i potem v2017 (vlax-ldata-put "TEST" "T" (list "String1 String2")) (setq s (vlax-ldata-get "TEST" "T")) (print s) (print (car s)) (print (type (car s))) Efekt działania v2017 poniżej: Efekt działania v2015 poniżej: Problem w tym, że w starej wersji gdy zapisywaliśmy listę złożoną ze stringów do rysunku za pomocą vlax-ldata-put i potem odczytywaliśmy dane za pomocą vlax-ldata-get to otrzymywaliśmy taką samą listę stringów. W v2017 po odczytaniu, ZWcad zmienia typ danych w liście i stringi przerabia na symbole. Mało tego jeśli w stringu jest spacja, to otrzymamy dwa elementy listy (dwa symbole). I do tego zmienia wielkość liter na duże! Dane odczytane z rysunku nie mają za dużo wspólnego z tym co zapisaliśmy :( Problem dotyczy tylko sytuacji gdy zapisujemy listę ze stringami, bo gdy zapisujemy same stringi to jest wszystko OK. Czy jest jakaś szansa że to zostanie naprawione szybko, bo bez tego nakładka nie działa i nie ma jak tego za bardzo obejść. Tym bardziej, że wersją 2017 nie mogę odczytać poprawnie danych zapisanych wcześniej w rysunku za pomocą wersji 2015.... :( :(