BKW

VERNUM = "25.00_2024.11.29(#16216-debc1d5bfa4)_x64" Zainstalowałem aktualizację ZWCADa 2025 (z opcji update). Mam wrażenie, że przy włączonej opcji INPUTSEARCHOPTIONFLAGS występuje pewnego rodzaju opóźnienie przy rozpoznawaniu poleceń wpisywanych z klawiatury. Szybkie wpisanie polecenia (skrótu) np. "aa" jest mylnie rozpoznane przez program jako polecenie (skrót) "a". Czy ktoś jeszcze to zauważył ? ZWCAD 2025 SP 1.3 - skróty.mp4

Jak najbardziej Tak, sprawdzałem. Na kilku plikach mam podobne zachowanie. Potestowałem skrypt na czystym pliku i wyniki na filmie poniżej. Skrypt poprawnie działa gdy używamy do nawigacji i zoomowania scrolla myszki. Gdy używamy polecenia "_zoom" to zawartość drugiego okna przesuwa się w pionie względem pierwszego okna (widać to po poziomej linii). Gdy przełączymy na drugi plik jest podobnie plus dodatkowo w linii komend pojawiają się błędy. 2024-11-13 09 04 27.mp4

Potestowałem troszkę skrypt na nowym ZWCadzie 2025 i niestety na moim przypadku nie działa on poprawnie. Poniżej zamieszczam film z zachowania wraz z zrzutem, na którym widać wyświetlany błąd. 2024-11-12 13 27 46.mp4 EDIT: dodam jeszcze, że lokalne układy nie mają znaczenia gdyż przy globalnych skrypt zachowuje się tak samo.

Super !!! Skrypt działa. Niestety nie dane mi (nam) będzie go dogłębnie przetestować, gdyż posiadamy ZWCADa w wersji 2024. Ale szacunek za ekspresową pomoc i bardzo fajne podejście do rozwiązania problemu.

Brawo, brawo i jeszcze raz brawo. My pomysłów mamy co niemiara, więc pracy nie stracą ;)

Dziękuję za zainteresowanie. Byłem pewny na 99%, że takiej funkcjonalności nie da się uzyskać za pomocą LISPa. Chociaż tak na prawdę patrząc na procedury jakie piszą użytkownicy programów CAD (chociażby Kojacek lub Lee Mac) zawsze zostaje ten 1% ... Mi wystarczą w zupełności. Nie śmiałbym prosić o więcej. Ogólnie, z użytkowego pkt widzenia pewnie maksymalnie 4 by wystarczyły (chociażby z uwagi na wielkość monitorów - im więcej rzutni, tym mniejsze okno i mniej szczegółowy ogląd na to co się rysuje i na co się patrzy). Oczywiście to moje zdanie. Nie do końca wiem o co Pan pyta. Jeżeli dobrze rozumiem to chyba najlepszym rozwiązaniem byłoby, gdyby w momencie przejścia na drugą rzutnię ta pierwsza zaczęłaby reagować tak samo jak ta druga przed jej aktywacją. Oczywiście wszelkie inne pomysły, sposoby działania itp. itd. będą jak najbardziej mile widziane

Poniżej wklejam na szybko napisany fragment kodu lisp, który pozwala na wykonanie tego o czym piszę powyżej, ale nie w czasie rzeczywistym. Ja przypisałem sobie to polecenia skrót klawiaturowy, dzięki czemu całkiem sprawnie ustawiam na dwóch rzutniach to co chcę uzyskać. Kod oczywiście trzeba "owarunkować" itp.

Powinienem tutaj dodać - "przesuniętych względem siebie na rysunku o jakąś wartość w poziomie lub pionie" - wtedy wszystko byłoby jasne. Zgadza się - mój błąd w opisaniu funkcji. Powyżej jest informacja czego zabrakło w moim opisie. Dokładnie tak Bardzo dobrze Pan to interpretuje. Ogólnie chodzi o to co opisał Pan powyżej. Nie ma znaczenia co jest na jednej i drugiej rzutni. Chodzi o to, żeby po włączeniu funkcji synchronizacji widok na jednej i drugiej rzutni przesuwał się synchronicznie oraz powiększał się również synchronicznie.

Ja też nie, chociaż już od paru lat zastanawiam się dlaczego nie ma takiej funkcjonalności. Do jednoczesnego podglądania np. rzutów kondygnacji "0" i "+1". Działając w jednym oknie (rzutni) na kondygnacji niższej chciałbym mieć podgląd co jest na kondygnacji wyższej. Uprzedzając od razu pomysły i rady - wykorzystuje wiele sposobów na pracę na wielu kondygnacjach, począwszy od xrefów po nakładanie rzutów itp. Mam tego pełną świadomość i wkleiłem to tylko po to, aby moje pytanie było lepiej zrozumiane. Zgodzę się z Panem gdy np. rzuty branżowe są rysowane każde na osobnym rysunku. Czasami jednak lepiej pracuje się, gdy ja swoje rysunki robię na jednym pliku - stąd pytanie o rzutnie. Przerobiliśmy w biurze prace z rzutami na różny sposób - teraz padł pomysł na taki sposób pracy.

Czy istnieje jakaś funkcja, skrypt, program pozwalający na synchroniczne przesuwanie (zoomowanie) na dwóch rzutniach jednocześnie ? W samym AutoCadzie nie udało mi się odnaleźć czegoś takiego. Istnieją natomiast aplikacje, których zainstalowanie w Autocadzie pozwala na taką funkcjonalność - poniżej podaje przykład. https://apps.autodesk.com/ACD/en/Detail/Index?id=2788892389049910944&appLang=en&os=Win32_64 Chodzi mi o działanie takiej funkcji w "czasie rzeczywistym". Napisałem sobie procedurę w lispie, której wywołanie pozwala na takie działanie czyli wyświetlenie w każdym oknie tego samego widoku lub w jednym z okien widoku przesuniętego po współrzędnych X (lub Y) o jakąś wartość. Wszystko to jednak nie dzieje się w czasie rzeczywistym - aby użyć skryptu należy skończyć (przerwać) wykonywane polecenie.

Czy coś wiadomo o dacie wydania łatki ?

U mnie działa tylko ZAPISZ, ZAMKNIJ, OTWÓRZ jeszcze RAZ (dany plik). Nie zmienia to faktu, że po jakimś czasie (dłuższym czy krótszym) problem powraca.

Trochę sam zgłupiałem gdyż : 1. W zwcadzie miałem otwarty plik, w którym tego typu zachowanie występuje (sprawdziłem to przed wykonywaniem dalszych poleceń) 2. Zapisałem go z nową nazwą i wyczyściłem ze wszystkiego oprócz kilku elementów. Zachowanie rzutni dalej takie samo. Zapisałem i sprawdziłem czy dalej występuje to samo - występowało 3. Zamknąłem plik bez zapisywania. 4. Otworzyłem go i zaczął działać normalnie 5. Plik bazowy, z którego "robiłem" wyczyszczony plik również zaczął działać normalnie (sic!) Być może jest to spowodowane jakimś wgranym lispem, ale do tej pory takie zachowanie nie występowało (we wcześniejszych wersjach 2024). Plik zaraz wyślę na priv

EDIT: Dzisiaj wszystko wróciło do poprawnego działania. Nie jestem w stanie odtworzyć takiego zachowania z powyższego postu. To co wydarzyło się wyżej było sprawdzane i potwierdzone na 2 komputerach. Dzisiaj, przynajmniej na jednym wszystko działa "po staremu". Może ktoś jeszcze natrafił na podobne działanie ? EDIT2: Cofam co napisałem wyżej - zachowanie z pierwszej wiadomości powróciło.

VERNUM = "24.10_2024.06.13(#9215-c3147e0f7e4)_x64" Czy została wprowadzona nowa zmienna (bądź już istniała), która zmienia sposób działania poleceń _COPY i _MOVE w przestrzeni papieru? Na chwilę obecną zwcad po wywołaniu powyższych poleceń kopiuje bądź przesuwa zakres widoku rzutni tak jakby cały rysunek zawierał się w przestrzeni papieru (poniżej wideo) ZWCAD2024SP14 - move copy w paper.mp4

Tak, na to wygląda, ma Pan rację. Po usunięciu skryptu z katalogu i uruchomieniu pliku, program zaczął się domagać skryptu W każdym razie wyjaśniło się i sprawa rozwiązana Dziękuję i pozdrawiam

W załączeniu plik po uruchomieniu którego włączają się przyciski. Testowane na ZW2023 i 2024 (VERNUM = "24.00_2023.05.11(#6651-58ff551dfde)_x64"), natomiast w wersji "24.10_2024.03.14(#8993-e756b745a59)_x64", przyciski nie włączają się (więc może tu może być wyjaśnienie) przyciski.dwg

W załączeniu zmienne z przyciskamiprzyciski.svf

Nie mam załadowanego skryptu, więc pewnie mam stan "fabryczny" do jakiego wraca program po jego rozładowaniu. I jest tak jak w opisach powyżej - przyciski losowo się włączają. Najczęściej wygląda to tak, że program uruchamia się bez przycisków i bywa, że w ogóle się nie pojawiają, ale czasem pojawiają się od razu z otworzonym plikiem, albo pojawiają się w trakcie pracy. Raz zaobserwowałem na dużym pliku ze skanami, gdzie wszystko działa trochę wolniej, jak po wywołaniu polecenia "linia" pojawiły się napisy i zamieniły się w przyciski. Nie jest to jakiś błąd, bardziej utrudnienie, szczególnie na mniejszych monitorach (laptop). Problem polega na tym, że przyciski zajmują więcej miejsca i nie zawijają się jak tekst. A gdy się nie mieszczą, pojawia się hybryda

No to ja odwrócę pytanie- czy jest zmienna/przełącznik która ustawi tak, żeby zawsze wyświetlało się klasycznie - bez przycisków w pasku poleceń? VERNUM = "24.00_2023.05.11(#6651-58ff551dfde)_x64"

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