2P

Dziękuję. Mniej więcej (na początek - bo docelowo myślę o czymś bardziej rozbudowanym)) chodzi mi o taki właśnie efekt. Tylko tu jest to atrybut i powyższy efekt osiągnąłem już przy zwykłych blokach, atrybutach i trochę LISPa. A mój problem dotyczy tekstu - może to nie działać. Przy czym do rozwiązania mojego zadania mogę zastosować w blokach dynamicznych atrybuty, a nie tekst. Niestety taki blok jaki Pan pokazał wstawiony w drugi blok (bloki zagnieżdżone) przestaje tak ładnie działać i myślę, że tu już nic się nie wymyśli 😞

Wraz z nadejściem nowych wersji Zwcada otwierają się przed nami nowe możliwości związane z definiowaniem i wykorzystywaniem bloków dynamicznych. Temat jest mi, jeśli chodzi o praktykę, zupełnie obcy, ale czuję w nim ogromny potencjał. Dlatego mam takie pytanie globalne: Czy mechanizm bloków dynamicznych umożliwia dynamicze wpływanie na tekst znajdujący się w bloku (NIE ATRYBUTY, ale tekst). Tzn. np. czy w zależności od kąta wstawienia bloku mogę wpływać na pozycję i obrót tekstu wewnątrz bloku??? Myślę że wielu już domyśla się do czego taka funkcjonalność byłaby absolutnie niezmiernie przydatna.... Kto potrafi odpowiedzieć na moje pytanie? A może ktoś może takie coś zademonstrować, jeśli to jest oczywiście technicznie możliwe....

Tak informacyjnie. W wydanej ostatecznej wersji Zw2019 (VERNUM = "2018.07.26(35476)_x64") nie zdążyli jeszcze tego błędu poprawić. 😞

Zakładam, że okręgi są narysowane. 1. Wybierz polecenie kreślenia linii 2. Naciśnij przycisk "Styczny" (to kółko z linią styczną) na toolbarze "Lokalizacja względem obiektu". 3. kliknij mniej więcej w okolicę przewidywanej styczności. 4. Ponownie kliknij przycisk "Styczny" na toolbarze "Lokalizacja względem obiektu". 3. kliknij mniej więcej w okolicę przewidywanej styczności na drugim okręgu. KONIEC - masz odcinek styczny do obu.

Dzięki!

Jakimś nieznanym mi sposobem, przypadkowo, wyłączyłem (chyba) wyświetlanie kart rysunków (te zakładki nad obszarem roboczym do przełączania między otwartymi rysunkami). Jak je włączyć??? ZWCAD 2019 Beta VERNUM = "2018.06.16(33846)_x64" (tylko do odczytu)

Proszę wczytać plik Wczytaj.dwg W nim XREFem jest test.dwg. Jeśli XREF umieścimy na warstwie Warstwa1, a następnie zamkniemy tę warstwę to wszystkie prostokąty powinny przygasnąć tak samo, a tu okazuje się, że jeden nie zmienia koloru. W jego definicji kolor jest ustawiony właśnie jako ByBlock. VERNUM = "2018.06.16(33846)_x64" (tylko do odczytu) test.dwg Wczytaj.dwg

Programiści ZWcada już poprawili w zasadzie ten problem, takie miałem wrażenie, ale został jednak jeszcze mały błąd związany z wyszarzeniem/rozjaśnieniem elementów na warstwach zamkniętych. Mamy XREF w nim bloki. Wszystko teraz działa poprawnie oprócz sytuacji gdy wewnętrzny blok ma elementy z kolorem ByBlock. Te elementy nie rozjaśniają się jak reszta. Wystarczy że zmienimy parametr elementów na ByLayer i już widać je rozjaśnione. Teraz to drobiazg, ale jednak. Widoczny np przy poczytanych mapach, gdzie cała mapa jest wyszarzona, ale kilka bloków na niej (np. drzewa) wyróżnia się swoim podstawowym kolorem, bo są zdefiniowane jako ByBlock. Pozdr

Dziękuję Działa

Czy można jakoś wyłączyć (zmienna systemowa?) nowość w postaci nowego okienka dokowalnego obsługi warstw i przywrócić stare z przyciskiem OK? Wg mnie działało lepiej i było wygodniejsze.

Akurat w tym przypadku to nie jest takie trudne do zrobienia. Wystarczy, że zapisując w pliku DWG dla niższej wersji atrybut z field zostanie zapisany jako zwykły atrybut z tekstem na stałe. Dzięki temu treść rysunku pozostanie taka sama, a nie będzie działać tylko automatyzacja.

Wydaje mi się, że sprawa starszych wersji powinna być rozwiązana tak, że w nich powinny pojawić się wartości ostatnio zapisane bez możliwości edycji, update itd. Jako pola tekstowe. Może powinno się to uzależnić od wersji DWG? Taka jest chyba filozofia kompatybilności DWG w dół. Bo bez tego strach wysyłać komuś pliki DWG z tą funkcjonalnością - łatwo o pomyłkę. A może powód tych problemów to sprawa wersji DWG w jakiej zapisuje się plik... Robiąc testy nie zwracałem na to uwagi, a dziś nie mam jak tego sprawdzić.... Ogólnie FIELDy mogą być bardzo przydatne - kierunek w dobrą stronę!

Sprawdziłem, metoda z fieldami działa. ALE! 1. Taki plik zawierający wstawione bloki wczytany do wcześniejszych wersji ZW lub pierwowzoru CAD wyświetla rysunek z samymi zerami zamiast ostatnich wartości - to dyskwalifikuje narzędzie. 2. Współrzędne odświeża REGEN, a REGENALL już nie. Tak powinno być? 3. REGEN odświeża wszystko, a czasem przydałaby się grupa takich bloków pokazująca współrzędne względem bieżącego układu współrzędnych. Czyli regeneracja wskazanych bloków. Dlatego jak dla mnie LISP w tym spisuje się znacznie lepiej i stosuję go do generowania tabeli współrzędnych geodezyjnych z mapy wraz z uaktualnieniem po przesunięciu punktów, a inny kod do wstawiania kot wysokościowych względem tymczasowych układów współrzędnych.

Dzięki za próbę rozwiązania problemu!!! W ten sposób jestem w stanie dostać się do danych. Ale myślę, że ten mój problem powinien być zgłoszony jako błąd w ZWcad i może w pełnej wersji 19 to już poprawią. Uważam, to za błąd bo jednak wszystkie inne CADy działają jak wersja 15. Prawdopodobnie do tego czasu obrabiać te dane i stosować nakładkę będziemy korzystając tylko z v15. Z mojego punktu widzenia najlepiej byłoby, gdyby poprawka ukazała się jeszcze w wersji 18, bo inaczej wszystkie licencje będzie trzeba sukcesywnie aktualizaować.... Pozdr

Dzięki za info. Przemyślę sprawę. Dla mnie najcenniejsze w LDATA było łatwe powiązanie z obiektem graficzny. Zastanowię się nad dalszymi losami nakładki

Zanim spróbuję "ugryźć", to mam pytania: 1. Tak jednym zdaniem, czemu nie LDATA ? - bo wydaje mi się to bardzo wygodne narzędzie i działało idealnie do czasu błędu w ZW 2017/18/19. 2. Czy migracja danych do obiektów niegraficznych ma sens, jeśli te dane są ściśle powiązane i przypisane do konkretnych obiektów graficznych (jak wartości atrybutów w bloku). Pozdr

OK . Dodam jeszcze tylko informację, że przeprowadziłem test jeszcze na dwóch innych wersjach demonstracyjnych tzw. zamienników i efekt pracy jest taki jak ZWcad v2015. Czyli prawdopodobnie należny problem uznać jako błąd najnowszego oprogramowania ZWcad.

Mam problem z vlax-ldata-.... oraz wersjami ZWcad i właściwie nie wiem co mam teraz zrobić. Z 5 lat temu napisałem sobie pewną nakładeczkę, która między innymi przechowywała dane za pomocą vlax-ldata-.... Te dane to była lista. A teraz okazuje się, że każdy ZW widzi to inaczej. Zamiast opisu - przykład, uruchomienia tego samego kodu, na tym samym DWG i tym samym elemencie w rysunku. Efekt działania (vlax-ldata-get ... ...): ZWcad v2015+ (efekt zgodny z zamysłem działania nakładki): (("RoomID" "8011D") ("RoomName" "m.studio") ("RoomBuilding" "B.") ("RoomLevel" "0") ("RoomLocal" ".2") ("RoomNr" ".1") ("RoomNrProject" "B.0.2.1") ("RoomFunction" "U") ("RoomStrefy" ((("StrefaHeight" 3.97) ("StrefaName" "Strefa_1") ("StrefaPosadzka" "") ("StrefaType" "Z") ("StrefaStatus" "Pp") ("StrefaKorekta" "100%") ("StrefaTynki" "1") ("StrefaID" "48B7F5") ("StrefaAreaPline" 94.5289) ("StrefaPerimeter" 52.43) ("StrefaArea" 93.7424) ("StrefaKubatura" 372.158)))) ("RoomAreaPP" 93.7424) ("RoomAreaPD" 0) ("RoomArea" 93.7424) ("RoomKubatura" 372.158) ("RoomFloor" "")) ZWcad v2017: (("RoomID" "8011D") ("RoomName" "m.studio") ("RoomBuilding" "B.") ("RoomLevel" "0") ("RoomLocal" ".2") ("RoomNr" ".1") ("RoomNrProject" "B.0.2.1") ("RoomFunction" "U") ("RoomStrefy" ((("StrefaHeight" (&VLO-R . 0)) ("StrefaName" "Strefa_1") ("StrefaPosadzka" "") ("StrefaType" "Z") ("StrefaStatus" "Pp") ("StrefaKorekta" "100%") ("StrefaTynki" "1") ("StrefaID" "48B7F5") ("StrefaAreaPline" (&VLO-R . 1)) ("StrefaPerimeter" (&VLO-R . 2)) ("StrefaArea" (&VLO-R . 3)) ("StrefaKubatura" (&VLO-R . 4))))) ("RoomAreaPP" (&VLO-R . 3)) ("RoomAreaPD" 0) ("RoomArea" (&VLO-R . 3)) ("RoomKubatura" (&VLO-R . 4)) ("RoomFloor" "")) ZWcad v2018: (("RoomID") ("RoomName") ("RoomBuilding") ("RoomLevel") ("RoomLocal") ("RoomNr") ("RoomNrProject") ("RoomFunction") ("RoomStrefy") ("RoomAreaPP") ("RoomAreaPD") ("RoomArea") ("RoomKubatura") ("RoomFloor")) Jak widać mamy tu odczynienia z listą list wielokrotnie zagnieżdżonych (pewna struktura danych) zapisana przez vlax-ldata-put. W wersji 2015 wszystko działało OK. W wersji 2017 wartości liczbowe real przedstawione są już jako jakieś &VLO-R. Moja nakładka tego nie obsługiwała, więc przestała działać. W wersji 2018 vlax-ldata-get nie zwraca już nawet list zagnieżdżonych obcinając wszystkie dane nakładki. Mogę jakoś przepisać kod swoje nakładki od nowa, mogę jakoś przekonwertować dane do których mam dostęp przez v2015, a które znajdują się w starych DWG i są mi potrzebne dziś...ALE do jakiego standardu? O co tu chodzi? Bo co wersja to aplikacja działa inaczej, a dostęp do bazy danych to kluczowa zasada zachowania kompatybilności. Proszę o pomoc: Czy mogę za pomocą ldata zapisywać listy zagnieżdzone z liczbami real, czy może to jest niezgodne ze standardem (a było dopuszczone w v2015, a już nie jest - nie wiem jak to ma AutoCAD). Jak to wygląda w kontekście docelowej wersji ZWcada? Czy jest jakiś inny sposób dostępu do danych w v2018, żeby otrzymać listę danych jak w v2015 i w miarę szybko dostosować przez to moją nakładkę do poprawnej pracy (to jest mój najgorszy dziś problem)?

Czy coś może wiadomo już w sprawie rozwiązania tego problemu???

layerbrowser nie pomógł. (Przy okazji wyszedł błąd wynikający jak zwykle z innego koloru ekranu na jakim pracuję. Miniaturki w oknie layerbrowser powinny być generowane na białym a nie na czarnym tle dla pracujących na białym, bo obecnie w miniaturkach nie widać linii rysowanych kolorem 7 - ale to drobiazg) laydel skasował warstwę, ale porównanie rysunków nic nie wskazało.... Może na tej warstwie była np. linia o zerowej długości? laymrg - powiedzmy że rozwiązał mój problem dziś. Dzięki.

ZW2018 niestety inaczej podchodzi do wyświetlania elementów na warstwach zamkniętych (kłódka) . Wg mnie błędnie, ale nie wiem jak to robi AutoCAD. W każdym bądź razie zw2015 robił to logicznie. Mam nadzieję, że AutoCAD też to robi logicznie, to byłaby szansa na poprawę.... O co chodzi. Mamy elementy na różnych warstwach. Jeśli zamkniemy jakąś warstwę, to elementy znajdujące się na tej warstwie wyszarzają się (przyciemniają lub rozjaśniają zależnie od koloru ekranu). Są mniej widoczne. I tak powinno być i jest w zw2018 sp2. A jeśli na warstwie zamkniętej wstawiony jest blok? To ZW działa poprawnie (wyszarza elementy bloku), ale tylko te które znajdują się w bloku na warstwie 0. Jeśli w bloku mamy elementy, które mają zdefiniowaną inną warstwę no niestety nic się nie dzieje. ZW2015 pod tym kątem działał poprawnie. Czy mogę liczyć na zgłoszenie tego jako błędu? Wbrew pozorom ma to ogromne znaczenie (przynajmniej dla nas w biurze i naszej techniki rysowania)

W SP2 teoretycznie poprawiono problem rozjaśniania (a nie przyciemniania) elementów zewnętrznych podczas edycji bloku. (Odpowiedni wątek na forum został zamknięty). Niestety błąd pozostał częściowo. Tzn. Część kolorów zachowuje się poprawnie, ale część kolorów już nie! Np u mnie elementy o kolorze 194 (fioletowy) zmieniają się na jakiś zgniło zielony w trakcie gdy edytuję jakiś blok. Podobnie kolor 144.

Zastosowałem tego typu różne metody. W tym sprawdziłem, czy coś nie ma na arkuszach. Jedyny powód pozostania warstwy jaki mi pozostał to zagnieżdżenie bloków...

Mam rysunek, w którym są różne bloki, w tym bloki zagnieżdżone bloki w blokach. Robię PURGE, ale zostaje niechciana warstwa. podejrzewam, że jakiś blok w boku został umieszczony na tej warstwie, albo jakiś element definiujący blok jest na tej niechcianej warstwie. Jak go sensownie odnaleźć? Jak wyszukać zagnieżdżony blok na jakiejś warstwie? Może ma ktoś odpowiedniego LISPa?

Świetnie działa. Nawet lepiej niż jest w wersji 2015, bo nie wyświetla zbędnego okienka. A czy można jeszcze prosić o drugą wariację skryptu? Tak żeby efektem była edycja bloku w rysunku, a nie osobnym oknie. Zresztą, chyba jak przejrzę sobie ten lisp to sam sobie zrobię. DZIĘKUJĘ ZA TEN LISP.