BKW

Skoro wyświetlała się wartość tzn że odcinek ma powierzchnię - co prawda o WARTOŚCI 0, ale ma. Tak mnie w szkole uczono ;) Mi bardziej chodzi o to, że sama struktura działania procedury związanej z poleceniem AREA jest inna (wyświetlanie błędu zamiast wartości 0) co powoduje przerwanie działania innych procedur.

Oczywiście, że nie ma powierzchni. Natomiast jeszcze kilka miesięcy temu miał (i przez kilkanaście lat), więc nie rozumiem Pana wytłumaczenia. EDIT: Idąc Pana tokiem rozumowania proszę mi wytłumaczyć dlaczego w takim razie polilinia złożona z 2 i więcej odcinków posiada powierzchnię ?

Chyba zlokalizowałem źródło problemu

Zwsoft w nowych aktualizacjach programu zmienił sposób działania polecenia "_AREA". Pierwotnie polecenie to pozwalało na odczyt pola powierzchni oraz obwodu dla polilinii złożonych z jednego odcinka : Po aktualizacji wersji 2023 do SP2.2 oraz wersji 2024 (po wersji 24.00_2023.06.26 czyli od wersji 24.00.2023.08.08) program już na to nie pozwala: Niestety zmiana ta powoduje, że niektóre posiadane przez nas nakładki przestają działać. I tu rodzi się pytanie - czy zmiana ta jest zmianą celową czy przypadkową ?

VERNUM = "24.00_2023.05.11(#6651-58ff551dfde)_x64" Zauważyłem rozbieżność w działaniu między poleceniami wblock i -wblock. Wersja bezokienkowa (-wblock) eksportuje również zablokowane warstwy, podczas gdy wersja z okienkiem ostrzega o zablokowanych warstwach i finalnie tworzy rysunek bez nich

Czaaaaaaad !! Dziękuję bardzo za skrypt - na pewno będzie bardzo przydatny.

Dziękuję za sugestię. Niestety polecenie "Matchprop" kopiuje jedynie skalę jaka jest ustawiona na bazowej rzutni. Nie powoduje zaś ustawienia rzutni na obszarze, o który nam chodzi.

Dokładnie tak Dokładnie tak - tak jak pokazałem to na filmie. Dziękuję za pomoc i sugestię. Jest to jakieś rozwiązanie zastępcze. Mam nadzieję, że jakoś uda mi się to wpleść w nasz program. Czy będzie Państwo zgłaszać to do ZWSoftu ? Bo wydaje mi się, że jest to błąd. Dobrze by było, gdyby w opcjach DWG to PDF pojawiła się możliwość zastąpienia pliku, jeżeli taki plik już w danym folderze występuje.

Jest jakiś problem z drukowaniem do PDFa przez wbudowaną drukarkę. Pojawia się on w dość specyficznej sytuacji. Postaram się to jakoś przystępnie wytłumaczyć. Załóżmy, że podczas drukowania korzystamy ustawionych wcześniej i zapisanych ustawień wydruku ("Menedżer ustawień wydruku") Podczas drukowania do pdfa możemy spotkać się z 3 rodzajami zachowania ZWCADa 1. Zachowanie przy drukowaniu poleceniem CTRL + P Gdy wywołamy okno drukowania powyższym poleceniem i klikniemy "OK" program wyświetla okno w lokalizacji, w której ostatnio były zapisywane pliki pdf. 2. Drukowanie poprzez polecenie "-plot" Ten sposób drukowania to takie sprawdzenie przeze mnie poprawności działania funkcji "-plot". Jak widać na poniższym filmie polecenia tego użyłem 2 razy, żeby pokazać czy dany wydruk zostanie "nadpisany". Przy drugim drukowaniu widać, że jest możliwość zastąpienia wcześniej wydrukowanego pdf. Wydruk takim sposobem powoduje, że plik PDF domyślnie zapisywany jest w tym samym folderze co drukowany plik DWG 3. To teraz przechodzimy do właściwego problemu z wydrukiem. Ponieważ proces drukowania mamy w biurze zautomatyzowany, korzystamy z autorskiego programu, który bazuje na ustawieniach w "Menedżerze ustawień wydruku". W programie znajduje się sekwencja poleceń z pkt.2. Na potrzeby przedstawienia problemu wyciąłem ją i pokazałem w postaci prostej komendy. Jak widać jest to to samo polecenie co w pkt.2 tylko wywołane poleceniem "LISPowym" Tak samo jak w pkt.2 plik PDF zapisywany jest w tym samym folderze co drukowany plik DWG Problem pojawia się wówczas, gdy plik PDF o takiej nazwie już istnieje - program nie jest w stanie do podmienić. Co więcej - widać na poniższym filmie, że program w ogóle nie wywołuje procedury związanej z samym procesem druku (brak okna "Plot Job Progress"). Takie zachowanie było sprawdzane na kilkunastu komputerach i za każdym razem program nie podmienia pliku PDF. Nie znalazłem w ustawieniach DWG to PDF opcji związanej z nadpisaniem istniejących plików. Być może istnieje jakieś rozwiązanie, o którym istnieniu nie mam pojęcia, a być może jest to błąd programu.

Tak, próbowałem. Polecenie to jest pomocne, ale o wiele "wolniejsze". Gdybym chciał uzyskać to co pokazuje na filmie poniżej to musiałbym się sporo "naklikać".

Czy ZWSoft planuje wprowadzić polecenie synchronizacji rzutni w przestrzeni papieru ? Może któryś z użytkowników posiada coś, co może powyższe polecenie zastąpić i dodatkowo działa w ZWCADzie ?

Nie, teraz został wychwycony a faktycznie ciągnie się od nowych wersji po 15+. W ZWCAD+ 2015 działało dobrze

Niestety - Pana metoda nie pozwala na zmianę wartości atrybutu, ponieważ jest on "stały"

Przy pomocy kolegi bobik_123 rozwiązałem problem. Poniżej wideo Moim błędem było: - nie zaznaczenie LOCK przy atrybutach - zła strona związana z obiektem DISTANCE - aby to poprawnie działało to koniec z żółtym wykrzyknikiem powinien być zaznaczony jako element do WYCIĄGANIA.

VERNUM = "24.10_2023.10.31(#8721-d0d14f8c9a7)_x64 Poniżej przedstawiam film, na którym widać, że w edytowanym bloku za pomocą polecenia "_refedit", podczas kopiowania linii poprzez złapania GRIDa i przytrzymanie klawisza CTRL, nowo powstałe linie nie wchodzą w skład bloku.

Blok wysłany w wiadomości prywatnej. Poniżej wrzuciłem film, na którym pokazałem całą ścieżkę tworzenia bloku od samego początku na czystym pliku bazowym (zwcadiso.dwt) Jak widać na nim zachowanie bloku jest dość nieoczywiste. Dodam również, że identycznie stworzony blok (krok po kroku jak na filmie poniżej), w którym atrybuty zastąpiłem zwykłym tekstem, działa poprawnie tzn. wraz z przesunięciem "grotu" przesuwa się również tekst wraz z liniami po prawej stronie.

VERNUM = "24.00_2023.06.26(#6688-0275d6507a2)_x64 Mam problem z definicją bloku dynamicznego - wideo poniżej. Nie wiem czy to jest moja niewiedza i nieumiejętność definicji takiego bloku, czy też jest to błąd programu. Chciałem zdefiniować prosty blok oznaczenia przekroju, w którym mógłbym swobodnie przesuwać jedną z jego części - części w skład której wchodzi atrybut. No i jednak coś się nie udało. Na filmie pokazano polecenie "stretch" ale przy poleceniu "move" jest tak samo.

VERNUM = "24.10_2023.10.31(#8721-d0d14f8c9a7)_x64" Podczas używania polecenia "_break" program dubluje edytowany element (prostokąt) - film poniżej.

Zauważyliśmy w biurze, że ZWSoft w dość zabawny sposób próbuje pokazać użytkownikom wprowadzenie nowej funkcji (zmiennej) - poprzez włączenie jej jako domyślny wybór. Tak jest z tą zmienną TRIMEXTENDMODE, tak samo było ze zmienną MTEXTCOLUMN - zdezorientowani użytkownicy szukają rozwiązania problemu dowiadując się w ten sposób o "nowościach". Ot takie spostrzeżenie :)

VERNUM = "24.10_2023.09.27(#8637-cd5a968f7c3)_x64" Dzisiaj po zainstalowaniu nowej wersji przestała działać nakładka do rysowania zbrojenia. Program przy próbie narysowania pręta pokazuje coś takiego W poprzedniej wersji ZWCAD 2024 (VERNUM = "24.00_2023.05.11(#6651-58ff551dfde)_x64) Coś w programie musiało zostać zmienione, co ma istotny wpływ na nakładkę i powoduje takie zachowanie. Wiem, że to mało informacji, ale może uda się w taki sposób nakierować na to co zostało zmienione i co należy w nakładce poprawić, żeby działała ona prawidłowa. Ja ze swojej strony spróbuję skontaktować się z autorem nakładki - chociaż od dawna nie jest ona rozwijana - mimo wszystko nakładka branżowa WENTYLE ( https://tomicad.pl/ ) działa na podobnej zasadzie i być może przy jej działaniu będzie występował podobny problem.

Dziękuję za pomoc - pomogło. Z tego co widzę to nowa zmienna, której jeszcze w wersji 2023 nie było. A tak przy okazji zapytam (nie w temacie) - parę dni temu pojawiła się aktualizacja wersji 2024. Ponieważ nie mogłem w danej chwili jej pobrać i zainstalować odłożyłem tą czynność na później. Po 2 godzinach aktualizacja nie była dostępna i nie jest do dzisiaj. A w ogóle będzie ?

Czy istnieje zmienna odpowiedzialna za wyświetlanie tekstu wielowierszowego ? Tekst wielowierszowy (mtext) szerszy niż zdefiniowana szerokość do tej pory wyświetlał się w jednej linii pomimo spacji itp. (widać to na wideo z wersji 2023) W wersji 2024 spacja powoduje przerzucenie tekstu za nią do drugiego (trzeciego, itd.) wiersza. VERNUM = "24.00_2023.06.26(#6688-0275d6507a2)_x64" VERNUM = "24.00_2023.05.11(#6651-58ff551dfde)_x64" VERNUM = "23 .20_2023.03.30(#5277-8f024ebc37e)_x64_S"

Proszę bardzo. Styl "MOJ_STYL" został utworzony w ZW2024 STYLETXT.dwg

Podrążyłem trochę temat i doszedłem do jeszcze ciekawszych spostrzeżeń Najciekawszy jest przypadek ostatni, gdzie styl "PROFILE" oparty o czcionkę simplex.shx został przeniesiony do stylu "STYL_MOJ", który również oparty jest o czcionkę simplex.shx

Dzień dobry VERNUM = "24.00_2023.05.11(#6651-58ff551dfde)_x64" Podczas pracy z rysunkami utworzonymi w starszych wersjach ZWCADA, (lub w innych programach CAD), po rozbiciu tekstu wielowierszowego program tworzy nowy styl. Nazwa stylu nawiązuje do definicji czcionki podanej w stylu (w tym przypadku romans.shx Na nowym rysunku, utworzonym na czystym pliku już w ZW2024 (albo na rysunku z występującym problemem, ale z nowym stylem stworzonym w ZW2024) tekst rozbija do tego samego stylu.