BKW

Użytkownik forum
  • Postów

    219
  • Dołączył

  • Ostatnia wizyta

  • Wygrane w rankingu

    1

Odpowiedzi opublikowane przez BKW

  1. vernum = "23.20_2022.12.03(#4996-a5f007e30b8)_x64" wersja angielskojęzyczna

    Najlepiej to zjawisko widoczne będzie na pustym rysunku.
    Po wstawieniu punktu zdefiniowanego jako relatywny do ekranu np. wewnątrz kwadratu (jako punkt odniesienia)

    pstyle.PNG.895ee300d95a2ca3f59098ba2d2e65a6.PNG

    i zmniejszeniu widoku przez scrolowanie aż zadziała automatyczna regeneracja, wywołanie polecenia Zoom Extents powoduje powiększenie ale nie do kwadratu jako jedynego stałego elementu, ale do zregenerowanego punktu. W skrajnym przypadku (kilkukrotne przeładowanie autoregeneracji przez scrolowanie myszą) zoom_E nie pokazuje nawet tego kwadratu. Co więcej, program zapamiętuje którąś wielkość powiększenia i po ponownym zbliżeniu na kwadrat z punktem, zoomE powoduje przywołanie któregoś poprzedniego widoku z wielkim punktem i niewidocznym kwadratem tak, jakby wielkość punktu była nowym zakresem powiększania. Jeśli ponownie powiększę widok na kwadrat z puntem i ręcznie wywołam regen, czy regenall, punkt zrobi się mały jak powinien, ale zoomE znowu źle się zachowa i przywoła któryś widok z wielkim punktem i niewidocznym kwadratem.

    zoom_extents.gif.04a64f3844c64b92e24db80c77c428e6.gif

    Jedyną możliwością żeby ZoomE zadziałał poprawnie jest usunięcie punktu i regeneracja. 

    Błąd nie pojawia się przy punktach z wielkością przypisaną na stałe, ale tam też zaraz po ZoomE należy wywołać regen

    Przy okazji pytanie - czemu wyłączona została zmienna regenmode (regenauto)?

  2. AKTUALIZUJĄC:

    Okazuje się, że:

    Przy wywoływaniu polecenia _move, _stretch, _copy z menu bądź ikony, kliknięcie strzałki w górę powoduje powtórzenie ostatnich współrzędnych klikniętego pkt.

    Przy przypisaniu powyższych poleceń do lispa ( (DEFUN C:SSSS () (COMMAND "_stretch")) ) kliknięcie strzałki w górę powoduje powtórzenie ostatnio wpisanej wartości.

    To nawiązuje troszkę do tematu związanego z chmurką rewizyjną, bo inaczej działają polecenia z LISPa a inaczej z ikon.

  3. W dniu 30.01.2023 o 09:53, kruszynski napisał:

    Sprawdziliśmy działanie skryptu w AutoCAD i okazało się, że tam działa to tak samo. Inna wersja polecenia uruchamia się z ikonki a inna z lispa.

    A teraz wbiję Panu lekko szpileczkę, bo rozumiem, że dążycie do zgodności z AutoCADem, ale...

    Komenda "_zoom" i "osnapy"

    AUTOCAD 2022

    image.gif.2c220ef99947429fceb597b7bcbf2b75.gif

    ZWCAD 2023 SP2 (ale tak naprawdę wersje po ZWCAD 2015+)

    image.gif.55b1011b6657482bcb1ffff7956c836d.gif

    Proszę o wyjaśnienie BRAKu zgodności ZWCADa z AutoCADem. 
    Tą (wg nas) uciążliwość z włączaniem OSNAPów zgłaszaliśmy wielokrotnie - bez rezultatów.
    Być może jest jakaś zmienna, której nie znamy i która odpowiada za wyłączenie OSNAPów podczas zoomowania.
    My sobie poradziliśmy z tym przerabiając makra i lispy dotyczące i odnoszące się do komendy "zoom".

  4. vernum = "23.20_2022.12.03(#4996-a5f007e30b8)_x64"

    Proszę o pomoc w wyjaśnieniu dziwnego zachowania programu przy poleceniu chmurki rewizyjnej.

    Przy wpisaniu polecenia _REVCLOUD lub wybraniu go z menu bądź ikonki toolbara program zachowuje się "po nowemu" tzn. jak poniżej.

    image.png.b6bdfb9300d394948bfd56d6b9c0be31.png

    Przy wywołaniu polecenia _REVCLOUD z lispa program zachowuje się jak z wersji ZWCAD 15+ 

    (DEFUN C:Revc () (COMMAND "_revcloud"))

    image.png.6d214e0e11227ac5913ea19db71bb7a7.png

    Skąd ta rozbieżność ?

  5. Vernum: wszystkie ang 2023

    Przy wywołaniu polecenia SAVEALL program zapisuje wszystkie otwarte pliki wraz z plikiem "na wierzchu", ale od razu na zakładkach pojawia się "*" informująca, że plik ten jest niezapisany (co jest nie prawdą).
    Na innych komputerach w biurze polecenie działa poprawnie.
    Co może powodować takie zachowanie programu ?

    image.thumb.gif.7520d7f4832401424e63db7239b3770c.gif

  6. W dniu 30.07.2021 o 11:46, BKW napisał:

    4. Zachowanie hatcha przy strechowaniu

    ZWCAD_2022 - vernum = "22.00_2021.07.07(251ad3fce2f)_x64"

    Zwcad_2020_strhatch.thumb.gif.1e527692682266ede8c8490b269e97aa.gif

    ZWCAD 2015+ VERNUM = "2015.08.15(27483)

    Zwcad_2015_strhatch.thumb.gif.0cc8e6d9c118ade5cdc3a216dd0493fe.gif

    Czy istnieje jakaś zmienna, która powoduje takie zachowanie ? Czy to jest błąd ?

     

     

     

    W dniu 27.08.2022 o 11:37, Chris napisał:

    W ZWCAD 2023 inaczej działa komenda STRETCH z HATCH niż w wersji 2021. W ZWCAD 2021 w trakcie wykonywania komendy STRETCH po złapaniu jakiegoś fragmentu kreskowania (np. wewnątrz dużego pola kreskowanego, ale obszar oznaczony rozciąganiem nie obejmował środka) pozostawało to kreskowanie bez zmian (kreskowanie nie reagowało na komendę stretch). Stretchowanie działało w przypadku złapania obiektu stanowiącego granicę kreskowania (np. linia/polilinia w całości lub punktach przełamania, w takiej sytuacji kreskowanie dostosowywało się do rozciągniętych granic pola) lub w przypadku złapania stretchem środka kreskowania (w takiej sytuacji kreskowania było przesuwane).

    W obecnej wersji (2023) wystarczy złapać fragment kreskowania w trakcie wybierania elementów do rozciągania i całe kreskowania zostaje przesunięte pomimo, że złapany został jakiś punkt wewnętrzny, który wcześniej był bez wpływu na kreskowanie (kreskowanie nie reagowało na komendę).

    Czy jest jakaś zmienna, która pozwala na ustawienie zachowania kreskowania jak wcześniej (jak w wersji ZWCAD 2021)? Ewentualnie czy ZWSoft mógłby wrócić do poprzedniego zachowania kreskowania?
    Obecnie wprowadza to zamieszanie/problemy i trzeba uważać na to czy kreskowania jest w określonych wcześniej granicach, czy zostało już przypadkowo przesunięte gdzieś obok lub poza granice.

     

    Zgłaszałem to już przy wersji 2022 i widzę, że to chyba nie jest znaczący problem skoro nie zostało to naprawione...

  7. 22 godziny temu, Adam Klaczek napisał:

    Wydaje się to właściwym zachowaniem.

    BURST faktycznie tworzy nowe obiekty, jeżeli zrobić to podczas edycji bloków, nowo-stworzone będą częścią bloku.

    W innych programach działa to tak samo.

    Jeżeli to jest poprawne działanie polecenia to przyjmuje to z pokorą. Choć wydaje się to nie logiczne.

  8. vernum = "23.00_2022.05.19(#4672-2a69c627485)_x64"

    Podczas edycji bloku poleceniem REFEDIT program przy komendzie BURST włącza w struktury bloku zaznaczone elementy poddające się komendzie BURST (bloki) będące poza strukturą bloku. Elementy te zostają rozbite, włączone w struktury edytowanego bloku. Gdy natomiast zamiast zapisać zmiany poleceniem REFSAVE użyjemy polecenia REFCLOSE bez uwzględnienia zmian to rozbity blok znika.
    Poniżej wideo:

    zwcad2023_refeditburst.gif.9cd9f645036754c4bb622bff437e7336.gif

  9. vernum = "23.00_2022.05.19(#4672-2a69c627485)_x64"
    Coś bardzo niedobrego dzieje się z opcją AUTOSAVE.
    Autosave włączony (co 5 min), odznaczona opcja "Only save current doc", otwartych kilka plików.
    Po 5 minutach gdy w folderze z plikami tymczasowymi pojawiają się autosavy, zamieniam rozszerzenie z .zw$ na dwg i otwieram pliki.
    Okazuje się, że każdy plik ma tą samą zawartość (najczęściej pliku, który podczas zapisywania jest plikiem "na wierzchu").
    Niestety tak utraciłem pół dnia pracy, gdy podczas włączania innego pliku program się zawiesił. Liczyłem, że zapisane autosavy mi pomogą - niestety nie pomogły.

  10. W dniu 30.07.2021 o 11:46, BKW napisał:

    4. Zachowanie hatcha przy strechowaniu

    ZWCAD_2022 - vernum = "22.00_2021.07.07(251ad3fce2f)_x64"

    Zwcad_2020_strhatch.thumb.gif.1e527692682266ede8c8490b269e97aa.gif

    ZWCAD 2015+ VERNUM = "2015.08.15(27483)

    Zwcad_2015_strhatch.thumb.gif.0cc8e6d9c118ade5cdc3a216dd0493fe.gif

    Czy istnieje jakaś zmienna, która powoduje takie zachowanie ? Czy to jest błąd ?

    5. Łapanie OSNAPów przy ZOOM / WINDOW

    Błąd czy też zachowanie zgłaszane przeze mnie chyba od początku ZWCada na nowym silniku. Da się coś z tym zrobić ??

     

    W dalszym ciągu te błędy występują

    W dniu 29.04.2022 o 13:47, BKW napisał:

    1. KURSOR Z POLECEŃ WYWOŁANYCH "LISPOWO"

    Przy wywoływaniu poleceń przez skróty zdefiniowane w składni LISP ( np. (DEFUN C:MN () (COMMAND "_MATCHPROP"))) program nie zmienia wyglądu kursora na "moduł selekcji". Przy poleceniu wywołanym z menu bądź wpisanym w całości w pasek komend kursor zachowuje się poprawnie.

    ZWCAD_2023_1_lisp.gif.db34d54947b7913c2e8b08754acd0334.gif

    To zostało poprawione

  11. Sposób znamy i używamy, ale też nie idealny, bo nie można obsługiwać filtrów z poziomu paska komend, czy lispa, tylko znowu trzeba wchodzić w okno warstw, wywijać, klikać - ładnie to widać na filmiku od AK . Temat był wielokrotnie poruszany na forum, zgłaszany też przeze mnie (bez odpowiedzi od 13 Stycznia 2021), a ostatnio 11 marca i chyba nic się nie zmieniło (?).
    Z tego co wiem, Autocad ma opcję filter w poleceniu -layer, ale nie ma wszystkich opcji - można tam tylko usunąć, edytować, czy ustawić jako aktualną, ale nie można włączać, wyłączać, zamrażać i odmrażać, a na tej opcji by nam najbardziej zależało.

    Tak teraz myślę - czy można odczytać zawartość grupy i wpisać potem jako zmienną do lispa i wtedy zamrażać lispowo te zapisane warstwy? To byłoby jakieś obejście.
    Czyli w rysunkach mam zawsze grupę warstw np. KKK w której są różne warstwy w zależności od rysunku, i po wywołaniu komendy np. "Freeze KKK" lisp najpierw odczytuje jakie warstwy są w grupie KKK i potem je zamraża po nazwie

  12. 11 minut temu, dmatusz3 napisał:

    Widzę, że post Pana nieco zdenerwował co nie było moim zamierzeniem.

    Zdenerwował - nie, zirytował - tak
    TAK MA BYĆ to zazwyczaj mówi się mało kumatemu uczniowi na lekcji fizyki czy matematyki (a proszę wierzyć, że przez coś takiego nie raz przechodziłem), gdy podczas setnej próby wytłumaczenia problemu on dalej go nie widzi.
    Nie mniej proszę o wybaczenie :)

    14 minut temu, dmatusz3 napisał:

    Proszę spojrzeć na spokojnie, bo jest spora różnica pomiędzy zapisem stanu warstw do pliku dwg, a zapisu ustawień okien dialogowych w takim pliku.

    Rozumiem, ale w takim razie to samo mogę powiedzieć z ustawieniami typu np. MIRRTEXT - możne je ustawić różne dla różnych plików DWG. I wiem, że to nie jest ustawienie okien dialogowych, ale jakby zasada działania podobna. Wystarczyłoby wprowadzenie takiej zmiennej. Ale... i tu zgadzam się poniekąd z Pana dalszą odpowiedzią...

    18 minut temu, dmatusz3 napisał:

    Jedną z podstawowych cech plików projektowych jest jest ich wymienność. Jeśli zaczernimy "grzebać" w pliku dwg i zapisywać tam dodatkowe rzeczy, które będzie obsługiwał tylko ZWCAD i to nie we wszystkich wersjach to może zrobić większe zamieszanie.

    Z drugiej strony ktoś może zarzucić nam niekompatybilność tego ustawienia, bo reszta świata nie zapamiętuje tej opcji w pliku dwg i użytkownicy są przyzwyczajeni, że ta opcja jest odznaczona po restarcie.

    Zgadzając się z Panem powiem tylko, że istnieje wiele ustawień i zmiennych w AUTOCADZIE, których brak w ZWCADZIE nie zmniejsza mu kompatybilności i stabilności działania.

  13. 46 minut temu, dmatusz3 napisał:

    To nie jest błąd, tylko tak ma być.

    Zapis stanu przełączników okien dialogowych w pliku rysunku dwg to raczej średni pomysł. 

    Dla pewności sprawdziliśmy - w AutoCAD jest tak samo.

    Sprawdziłem jeszcze jedną rzecz - skoro zapis stanu przełączników to średni pomysł to dlaczego program po ponownym uruchomieniu i włączeniu menedżera warstw swój "kursor" ustawia w drzewku warstw na pozycji XREF (oczywiście w moim przypadku) ? Moim zdaniem brakuje tu konsekwencji - albo w ogóle "kursor" powinien lądować na pozycji ALL (przy ponownym uruchomieniu programu) albo tak jak został ustawiony przed wyłączeniem (czyli w tym przypadku na XREF).
    Teraz program zachowuje się jakby "stał w rozkroku" - "może pójdę do ALL, a może do XREF z ustawionym INVERT FILTER"
    Proszę się zastanowić nad tym czy uwzględnienie mojego postulatu (tak, przepraszam, błędnie nazwanego BŁĘDEM) przypadkiem nie będzie najbardziej sensownym rozwiązaniem.

  14. 7 minut temu, dmatusz3 napisał:

    To nie jest błąd, tylko tak ma być.

    Widzę, że nigdy nie pracował Pan z większą ilością xrefów w pliku... ale skoro TAK MA BYĆ, to TAK MA BYĆ. Proszę mi wierzyć, że przy pracy na co najmniej 10 plikach i w powiązaniu ich ze sobą xrefami wchodzenie w menedżera warstw i przestawianie tego przełącznika, tak aby te xrefowe warstwy ukryć, wcale nie jest wygodnym rozwiązaniem. ALE TAK MA BYĆ

    8 minut temu, dmatusz3 napisał:

    Zapis stanu przełączników okien dialogowych w pliku rysunku dwg to raczej średni pomysł.

    Wcale tak nie uważam, skoro można zapisać status warstw dla danego rysunku (część widocznych, część zamrożonych, itp. itd.) to dlaczego tego nie zrobić dla okien

    9 minut temu, dmatusz3 napisał:

    Dla pewności sprawdziliśmy - w AutoCAD jest tak samo.

    Aha, czyli jesteście tylko bierną kopią Autocada, nie tworzycie własnych rozwiązań a dążycie tylko do bycia tańszym odpowiednikiem droższego programu. No bardzo dobre podejście. A szkoda, bo patrząc na szybkość działania nowej wersji programu idziecie w dobrą stronę.

    I proszę pamiętać, że nie zawsze to co jest w "przodku" waszego programu (czyt. Autocadzie) jest rozwiązaniem dobrym.