JasW Opublikowano 17 Lutego 2017 Zgłoś Opublikowano 17 Lutego 2017 (edytowane) Znalazłem taki fajny skrypt w Lispie : http://www.lee-mac.com/associativecenterlines.html (c) Lee-Marc Robi to mechanizmem asocjacji bez użycia blokow co dla mnie ma pewne zalety. Oryginalny kod Lisp w AC po przesunięciu lub zmianie promienia okręgu przesuwa i skaluje linie zgodnie ze zmianą obiektu bazowego. Niestety w Zwcad 2017 (vernum 13656) krzyż jest tworzony ale mechanizm assocji już nie działa Czy da się go dostosować do ZWCAD 2017 ? Pozdrawiam, J. AssociativeCenterlineV1-0.lsp Edytowane 17 Lutego 2017 przez JasW Cytuj
Mayster Opublikowano 20 Lutego 2017 Zgłoś Opublikowano 20 Lutego 2017 W sumie rzeczywiście mogłoby się to okazać całkiem przydatne. Cytuj
dmatusz3 Opublikowano 20 Lutego 2017 Zgłoś Opublikowano 20 Lutego 2017 A oto dopasowany do 2017 pliki z lispem AssociativeCenterlineV1-0_ZWCAD.lsp JasW 1 Cytuj
JasW Opublikowano 20 Lutego 2017 Autor Zgłoś Opublikowano 20 Lutego 2017 Dziękuję za błyskawiczną reakcję powiązaną z działającym skryptem. Jest to dla mnie okazja do przyjrzeniiu sie Lispowi, który ma kilka patentów niedostępnych do obsługi przez COM i VBA. Ze względu na potrzebę jaką mam zachowania kompatybilności z AC rzuciła mi sie w oczy zmiana używanych kodów XData : z 1005 ( DataBase Handle 1005 Entity handle in extended data. Text string of up to 16 hexadecimal digits ) na 1000 (String 1000 A string of up to 255 characters.) Czy ZWCAD'y nie mogą używać kodów 1005 ? Pozdrawiam, J Cytuj
kruszynski Opublikowano 20 Lutego 2017 Zgłoś Opublikowano 20 Lutego 2017 Zasadniczo mogą. ale odczytując taki uchwyt w ZWCAD 2017 SP2 otrzymujemy jakieś cuda. Na szczęście uchwyt jest też tekstem, a tekst można odczytywać bez problemu. JasW 1 Cytuj
kojacek Opublikowano 20 Lutego 2017 Zgłoś Opublikowano 20 Lutego 2017 Przechowywanie uchwytu w kodzie DXF 1005 ma tę właściwość, że zostaną zachowane (przekształcone odpowiednio by zachować połączenia) symboliczne wskaźniki do obiektów, podczas takich operacji jak zapisywanie bloku, kopiowanie elementów do innego rysunku, dołączania jako xref itd. Proteza w postaci zapisu uchwytu w kodzie 1000 nigdy tego nie zagwarantuje. Cytuj
JasW Opublikowano 20 Lutego 2017 Autor Zgłoś Opublikowano 20 Lutego 2017 19 minut temu, kojacek napisał: Przechowywanie uchwytu w kodzie DXF 1005 ma tę właściwość, że zostaną zachowane (przekształcone odpowiednio by zachować połączenia) symboliczne wskaźniki do obiektów, podczas takich operacji jak zapisywanie bloku, kopiowanie elementów do innego rysunku, dołączania jako xref itd. Proteza w postaci zapisu uchwytu w kodzie 1000 nigdy tego nie zagwarantuje. Zaczynam powoli przyglądać się patentom jakie opisałeś m.inn tu http://forum.cad.pl/field-pole-dwustronna-komunikacja-line-field-t73580.html Godzinę temu, kruszynski napisał: Zasadniczo mogą. ale odczytując taki uchwyt w ZWCAD 2017 SP2 otrzymujemy jakieś cuda. Na szczęście uchwyt jest też tekstem, a tekst można odczytywać bez problemu. Zakładałem że te "cuda" to w formie tekstowej (HEX) uchwyt obiektu t.j. Handler np: "A5D" ? : wg moich źródeł : DataBase Handle 1005 Entity handle in extended data. Text string of up to 16 hexadecimal digits W przerobionym skrypcie pod zwcad'a znalazlem ; fix 1525 czy to skutki bugów ZWCAD'a ? ;-) Cytuj
kruszynski Opublikowano 21 Lutego 2017 Zgłoś Opublikowano 21 Lutego 2017 15 godzin temu, JasW napisał: Zakładałem że te "cuda" to w formie tekstowej (HEX) uchwyt obiektu t.j. Handler np: "A5D" ? : wg moich źródeł : DataBase Handle 1005 Entity handle in extended data. Text string of up to 16 hexadecimal digits Nie. gdyby był to uchwyt obiektu wszystko byłoby OK. W tym przypadku uchwyt powinien być np 27D a odczytane cuda to np "@Ţ\002\" Cytuj W przerobionym skrypcie pod zwcad'a znalazlem ; fix 1525 czy to skutki bugów ZWCAD'a ? ;-) To byłoby zbyt daleko idące uproszczenie. W tym przypadku rzeczywiście w ten sposób oznaczyłem obejście błędu który w naszym systemie zgłoszeń ma taki numer. Nasza baza zgłoszeń powstaje od kilku lat i zawiera zgłoszenia błędów, ale też propozycje funkcjonalności ZWCADa i naszych programów, takimi zgłoszeniami są też prośby od Klientów czy z forum typu jak uruchomić w ZWCAdzie skrypt itp . Więc numer jest identyfikatorem zgłoszenia a nie każde zgłoszenie to bug. Cytuj
JasW Opublikowano 21 Lutego 2017 Autor Zgłoś Opublikowano 21 Lutego 2017 (edytowane) 54 minuty temu, kruszynski napisał: Nie. gdyby był to uchwyt obiektu wszystko byłoby OK. W tym przypadku uchwyt powinien być np 27D a odczytane cuda to np "@Ţ\002\" To byłoby zbyt daleko idące uproszczenie. W tym przypadku rzeczywiście w ten sposób oznaczyłem obejście błędu który w naszym systemie zgłoszeń ma taki numer. Nasza baza zgłoszeń powstaje od kilku lat i zawiera zgłoszenia błędów, ale też propozycje funkcjonalności ZWCADa i naszych programów, takimi zgłoszeniami są też prośby od Klientów czy z forum typu jak uruchomić w ZWCAdzie skrypt itp . Więc numer jest identyfikatorem zgłoszenia a nie każde zgłoszenie to bug. Jeśli AC w XData 1005 wstawia właśnie handler np. 27D , to jeśli ZwCad wstawia tam coś na kształt "@T\002\" (co dla mnie jest raczej wskazówką że to jakiś śmieć z bufora niezainicjowanej zmiennej ) wniosek nasuwa się jeden: bug? . Proszę o potwierdzenie czy zachowanie ZwCAD'a zakwalifikowano jako bug. Chyba że jest inna ścisła interpretacja tych znaków bo nie wiem czy mogę planować wykorzystanie asocjacji w ZwCAD we własnym kodzie z powodów, które opisał @kojacek : 17 godzin temu, kojacek napisał: Przechowywanie uchwytu w kodzie DXF 1005 ma tę właściwość, że zostaną zachowane (przekształcone odpowiednio by zachować połączenia) symboliczne wskaźniki do obiektów, podczas takich operacji jak zapisywanie bloku, kopiowanie elementów do innego rysunku, dołączania jako xref itd. Proteza w postaci zapisu uchwytu w kodzie 1000 nigdy tego nie zagwarantuje. J. Edytowane 21 Lutego 2017 przez JasW Cytuj
kruszynski Opublikowano 21 Lutego 2017 Zgłoś Opublikowano 21 Lutego 2017 Tak, w tym przypadku jest to błąd ZWCADA. Przy czym błąd dotyczy odczytu. Można zapisać, i przez funkcję XDList odczytać wartość, która jest poprawna, ale (vla-getXData ... ) odczytuje "cuda". To co chciałem przekazać w poprzednim poście, to że na podstawie numeru nie możemy wnioskować o tym ile błędów jest w samym ZWCADzie 2017. A w ogóle to numer 1525 dotyczy formatu elementów przekazanych przez reaktor, a błąd z odczytem xDaty to 1524 Cytuj
dmatusz3 Opublikowano 21 Lutego 2017 Zgłoś Opublikowano 21 Lutego 2017 Zauważam tutaj pewne rozbieżności w interpretacji postów Podsumuję: błąd z odczytem XDaty 1005 to problem wersji 2017, wczoraj wysłaliśmy opis tego przypadku do ZWSOFT, dzisiaj otrzymaliśmy potwierdzenie od ZWSOFT, że zostało to przekazane do naprawy. Cytuj
JasW Opublikowano 21 Lutego 2017 Autor Zgłoś Opublikowano 21 Lutego 2017 Ostatni post wskazał dla mnie najwłaściwsza interpretację ;-) Za używanie asocjacji w Zwcad ja osobiscie zabiorę się gdy będą działać oryginalne skrypty (c) Lee-Marc'a Przeglądałem parę dni temu jego stronę i byłem podbudowany tym że kilka innych skryptów wydawało mi sie bardzo złożonych zadziałało w ZwCad 2017 . Zakładajac, że ZWCADowi zależy na porządnym wyczyszczeniu fundamentów kompatybilności na poziomie Lispa pozostaje czekać na jakieś pozytywne wieści. BTW kiedy można się spodziewac jakiegos nastepcy SP2 ? J. Cytuj
dmatusz3 Opublikowano 21 Lutego 2017 Zgłoś Opublikowano 21 Lutego 2017 W dalszej kolejności będzie wydana wersja SP 3.0 w drugiej połowie marca. Cytuj
Martin_S Opublikowano 21 Lutego 2017 Zgłoś Opublikowano 21 Lutego 2017 Prosze wpłynąć na ZWSOFT by ARCHITECTURE 2017 ENU 64 bit tez był wydany na SP 3.0 jesli to możliwe...poczekam Cytuj
dmatusz3 Opublikowano 21 Lutego 2017 Zgłoś Opublikowano 21 Lutego 2017 Zakańczając lekkie odejście od tematu - mam potwierdzenie, że następny Architecture będzie oparty na SP 3.0. Cytuj
Rekomendowane odpowiedzi
Dołącz do dyskusji
Możesz dodać zawartość już teraz a zarejestrować się później. Jeśli posiadasz już konto, zaloguj się aby dodać zawartość za jego pomocą.