BKW

Nie jest to naturalne. Ja chcę rozciągnąć linie i nie chcę, żeby hatch był przesuwany razem z liniami. Tak jak pisałem, to zjawisko pojawiło się w wersji 2022. W wersjach niższych "lekko trącony" myszką hatch zostawał w miejscu.

7. Zawieszanie się programu przy używaniu LISPów LeeMaca Kiedyś o tym pisałem, ale coś jest takiego w kodzie programów udostępnianych przez Lee Maca, że wywołanie komendy uruchamiającej dany skrypt (chociażby ten - http://www.lee-mac.com/doubleextend.html ) powoduje zawieszanie się programu. Nie dzieje się to zawsze i najczęściej po jakimś czasie pracy w danej sesji, ale się dzieje. Jeżeli ma ktoś ochotę to sprawdzić i potwierdzić będę wdzięczny. Dodam również, że to dzieje się już prawdopodobnie od pierwszej wersji ZWCada przepisanej na nowo. W 2015+ wszystkie działają bez żadnych problemów.

VERNUM = "22.10_2021.09.23(8f1be26e226)_x64" W dalszym ciągu nic się z powyższymi uwagami nie zmieniło

VERNUM = "22.10_2021.09.23(8f1be26e226)_x64" W edycji bloku podczas kopiowania elementów poprzez złapanie GRIPA + CTRL program "wyrzuca" nowo stworzone elementy poza blok.

Z dodatkowych informacji to obrócona rzutnia zamienia się z VIEWPORT na POLYLINE

Wygląda na to, że problem został naprawiony.

VERNUM = "22.10_2021.09.23(8f1be26e226)_x64" Przy obrocie rzutni w przestrzeni papieru następuje zmiana koloru rzutni oraz niewyświetlanie się warstwy na której się znajduje.

Logiczniej byłoby, gdyby zapamiętywał się do danego pliku. Tym bardziej skoro nie jest to zmienna programu tylko przełącznik w ustawieniach odnoszących się do danego pliku

vernum = "22.10_2021.09.23(8f1be26e226)_x64" Błąd w dalszym ciągu występuje.

vernum = "22.10_2021.09.23(8f1be26e226)_x64" Błąd w dalszym ciągu występuje.

VERNUM = "22.10_2021.09.23(8f1be26e226)_x64" Błąd w dalszym ciągu występuje.

Funkcja bardzo fajna, tylko trzeba uważać z układami współrzędnych - poprawnie działa tylko w układzie globalnym. Poniżej filmik z ustawieniem obrotu na 0 w układzie lokalnym Im dalej 0,0 układu lokalnego oddalone jest od 0,0 globalnego, tym bardziej tekst się rozjeżdża. Co ciekawe tekst jednowierszowy ustawił się z kątem 0 względem układu lokalnego, a tekst wielowierszowy do układu lokalnego. Ja wiem, że to można szybko poprawić, przełączyć się na chwilę z ucsem, obrócić i wywołać, ale to chyba nie powinno tak wyglądać

oraz A ja bym nie łączył zwykłego tekstu z właściwościami tekstu wymiarowego. Tekst to tekst, a wymiar rządzi się innymi prawami. Poza tym, nawet do tekstu wymiarowego dołączono opcję odwracania (często z niej korzystam kiedy rzutnia w przestrzeni papieru ma inną orientację niż w modelu, albo kiedy bloki pamiętają UCS z momentu tworzenia, a potem są obracane)

Sprawdziłem jeszcze taką sytuację - 3 teksty obrócone (90st, 80st i 100st) Program zachowuje się tak jak na załączonym GIFie i tak samo jak w przypadku mojego pierwszego posta. Troszkę brakuje mi w tym przypadku konsekwencji bo tekst "aaaaaa" powinien jednak mieć taką orientację jak tekst "cccccc".

Nie uważam żeby takie zachowanie tekstu było uzasadnione. Przy poprawnie działającym programie MIRROR powinien ustawić nowy tekst tak jak oryginalny.

Chodzi tylko i wyłącznie o zapamiętanie włącznika INVERT FILTER. Może żeby doprecyzować to używam tej opcji do pracy z XREFami (jak widać na GIFie).

Od kilku wersji programu funkcja INVERT FILTER z menedżera warstw nie działa poprawnie po ponownym uruchomieniu pliku. Program nie zapamiętuje ustawień tego przełącznika i gdy włączymy plik jeszcze raz jest on dezaktywowany, a po prawej stronie w oknie wyświetlają się warstwy, które chciałem "ukryć".

W kilku swoich plikach natrafiłem na obiekty zachowujące się jak na poniższym GIFie. Przy robieniu lustra tekst się "obraca". Gdy poprawimy jego kąt obrotu na 90st przez okno PROPERTIES wtedy tekst zachowuje się poprawnie. Natomiast gdy zmienimy kąt na 89 lub 91 stopni tekst ponownie zachowuje się tak jak na załączonym GIFie. Załączam również plik z tekstem. mirror.dwg

VERNUM = "22.00_2021.07.07(251ad3fce2f)_x64" W edycji bloku przez komendę refedit i zmianę koloru elementów przez wywołanie polecenia "_change" powoduje, że kolor zmieniają również elementy nienależące do bloku. Poniżej GIF Poniżej z kolei GIF ze zmianą koloru przez klikanie w toolbar - działa to poprawnie

Potwierdzam

Rzeczywiście, sprawdziłem w Autocad2019, i filletowanie wygląda inaczej niż pierwotnie w ZWCAD2015+, ale ZWCAD 2022 też nie robi tego identycznie jak Autocad co widać w przypadku polilinii składającej się z kilku odcinków. Wg mnie logiczne jest to, że linia powinna przyjąć grubość polilinii jaką ta ma w miejscu dołączenia, ale to Autocad nadaje ton w tych sprawach

Nie wiem jaka obecnie jest moda, ale we wszystkich cadach na których do tej pory pracowałem (Auto, Intelli, ZW bez plusa i z plusem (2015+)) dołączana linia przejmuje wszystkie właściwości polilinii, tutaj problem jest z grubością. Przykład pokazuje różne zachowanie się polilinii w zależności od komendy, promienia i przede wszystkim od tego, czy polilinia składa się z jednego odcinka, czy kilku Proszę narysować polilinię składającą się z kilku segmentów (tak jak w przykładzie)

VERNUM = "22.00_2021.07.07(251ad3fce2f)_x64" (read only) Poniżej przedstawiam zrzut pokazujący różne dziwne zachowania podczas filletowania i chamferowowania polilinii i linii. Polilinia ma zadaną grubość, a polecenia fillet i chamfer powinny stworzyć polilinię, w której linia przejmuje właściwości polilinii - warstwę, kolor, grubość, a tak nie zawsze jest - polilinia się tworzy, przejmuje kolor i warstwę, ale z grubością sobie nie zawsze radzi

VERNUM = "22.00_2021.07.07(251ad3fce2f)_x64" (read only) Podczas kopiowania elementu z xrefa (ncopy) element kopiuje się do rysunku, ale pozostaje na warstwie xrefowej. Dopóki xref jest załączony, to można skopiowany element zaznaczyć, zmienić mu warstwę, czy właściwości itp. Jeśli się jednak nie zmieni warstwy tego elementu, to po odłączeniu xrefa element staje się "niezatapialny" - wyświetla się, ale nie da się go zaznaczyć. Po zapisaniu rysunku, zamknięciu i ponownym otworzeniu, pojawia się znowu, i można go zaznaczyć, ale nie jest przypisany do żadnej warstwy

VERNUM = "22.00_2021.07.07(251ad3fce2f)_x64" (read only) Polecenie Mid Between 2 Points nie działa poprawnie z polilinią. Poniżej filmik pokazujący różnicę między m2p+LINIA i m2p+POLILINIA