Associative Circle and Centerline

[JasW]

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

[kruszynski]

Sprawdzę to.

[Mayster]

W sumie rzeczywiście mogłoby się to okazać całkiem przydatne.

[dmatusz3]

A oto dopasowany do 2017 pliki z lispem AssociativeCenterlineV1-0_ZWCAD.lsp

[JasW]

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

 

[kruszynski]

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.

[kojacek]

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.

[JasW]

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  ? ;-)

[kruszynski]

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.

[JasW]

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

[kruszynski]

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

[dmatusz3]

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.

 

 

[JasW]

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.

[dmatusz3]

W dalszej kolejności będzie wydana wersja SP 3.0 w drugiej połowie marca.

[Martin_S]

Prosze wpłynąć na ZWSOFT by ARCHITECTURE 2017 ENU 64 bit tez był wydany na SP 3.0 jesli to możliwe...poczekam

[dmatusz3]

Zakańczając lekkie odejście od tematu - mam potwierdzenie, że następny Architecture będzie oparty na SP 3.0.