2P Opublikowano 16 Lipca 2018 Zgłoś Opublikowano 16 Lipca 2018 Mam problem z vlax-ldata-.... oraz wersjami ZWcad i właściwie nie wiem co mam teraz zrobić. Z 5 lat temu napisałem sobie pewną nakładeczkę, która między innymi przechowywała dane za pomocą vlax-ldata-.... Te dane to była lista. A teraz okazuje się, że każdy ZW widzi to inaczej. Zamiast opisu - przykład, uruchomienia tego samego kodu, na tym samym DWG i tym samym elemencie w rysunku. Efekt działania (vlax-ldata-get ... ...): ZWcad v2015+ (efekt zgodny z zamysłem działania nakładki): (("RoomID" "8011D") ("RoomName" "m.studio") ("RoomBuilding" "B.") ("RoomLevel" "0") ("RoomLocal" ".2") ("RoomNr" ".1") ("RoomNrProject" "B.0.2.1") ("RoomFunction" "U") ("RoomStrefy" ((("StrefaHeight" 3.97) ("StrefaName" "Strefa_1") ("StrefaPosadzka" "") ("StrefaType" "Z") ("StrefaStatus" "Pp") ("StrefaKorekta" "100%") ("StrefaTynki" "1") ("StrefaID" "48B7F5") ("StrefaAreaPline" 94.5289) ("StrefaPerimeter" 52.43) ("StrefaArea" 93.7424) ("StrefaKubatura" 372.158)))) ("RoomAreaPP" 93.7424) ("RoomAreaPD" 0) ("RoomArea" 93.7424) ("RoomKubatura" 372.158) ("RoomFloor" "")) ZWcad v2017: (("RoomID" "8011D") ("RoomName" "m.studio") ("RoomBuilding" "B.") ("RoomLevel" "0") ("RoomLocal" ".2") ("RoomNr" ".1") ("RoomNrProject" "B.0.2.1") ("RoomFunction" "U") ("RoomStrefy" ((("StrefaHeight" (&VLO-R . 0)) ("StrefaName" "Strefa_1") ("StrefaPosadzka" "") ("StrefaType" "Z") ("StrefaStatus" "Pp") ("StrefaKorekta" "100%") ("StrefaTynki" "1") ("StrefaID" "48B7F5") ("StrefaAreaPline" (&VLO-R . 1)) ("StrefaPerimeter" (&VLO-R . 2)) ("StrefaArea" (&VLO-R . 3)) ("StrefaKubatura" (&VLO-R . 4))))) ("RoomAreaPP" (&VLO-R . 3)) ("RoomAreaPD" 0) ("RoomArea" (&VLO-R . 3)) ("RoomKubatura" (&VLO-R . 4)) ("RoomFloor" "")) ZWcad v2018: (("RoomID") ("RoomName") ("RoomBuilding") ("RoomLevel") ("RoomLocal") ("RoomNr") ("RoomNrProject") ("RoomFunction") ("RoomStrefy") ("RoomAreaPP") ("RoomAreaPD") ("RoomArea") ("RoomKubatura") ("RoomFloor")) Jak widać mamy tu odczynienia z listą list wielokrotnie zagnieżdżonych (pewna struktura danych) zapisana przez vlax-ldata-put. W wersji 2015 wszystko działało OK. W wersji 2017 wartości liczbowe real przedstawione są już jako jakieś &VLO-R. Moja nakładka tego nie obsługiwała, więc przestała działać. W wersji 2018 vlax-ldata-get nie zwraca już nawet list zagnieżdżonych obcinając wszystkie dane nakładki. Mogę jakoś przepisać kod swoje nakładki od nowa, mogę jakoś przekonwertować dane do których mam dostęp przez v2015, a które znajdują się w starych DWG i są mi potrzebne dziś...ALE do jakiego standardu? O co tu chodzi? Bo co wersja to aplikacja działa inaczej, a dostęp do bazy danych to kluczowa zasada zachowania kompatybilności. Proszę o pomoc: Czy mogę za pomocą ldata zapisywać listy zagnieżdzone z liczbami real, czy może to jest niezgodne ze standardem (a było dopuszczone w v2015, a już nie jest - nie wiem jak to ma AutoCAD). Jak to wygląda w kontekście docelowej wersji ZWcada? Czy jest jakiś inny sposób dostępu do danych w v2018, żeby otrzymać listę danych jak w v2015 i w miarę szybko dostosować przez to moją nakładkę do poprawnej pracy (to jest mój najgorszy dziś problem)? Cytuj
dmatusz3 Opublikowano 16 Lipca 2018 Zgłoś Opublikowano 16 Lipca 2018 Preparujemy właśnie kawałek kodu w celu sprawdzenia działania funkcji. Cytuj
2P Opublikowano 16 Lipca 2018 Autor Zgłoś Opublikowano 16 Lipca 2018 OK . Dodam jeszcze tylko informację, że przeprowadziłem test jeszcze na dwóch innych wersjach demonstracyjnych tzw. zamienników i efekt pracy jest taki jak ZWcad v2015. Czyli prawdopodobnie należny problem uznać jako błąd najnowszego oprogramowania ZWcad. Cytuj
kojacek Opublikowano 16 Lipca 2018 Zgłoś Opublikowano 16 Lipca 2018 Osobiście odradzam używania LDATA, czy to w samym AutoCAD-zie, czy w programach mu podobnych. Niezależnie, czy jest błąd w ZwCAD, sugerowałbym migrację danych do obiektów niegraficznych typu Dictionary (również Extension Dictionary), oraz do przechowywania dużej ilości danych różnego typu w obiekcie XRECORD. Parokrotnie poruszałem już ten temat tutaj: https://kojacek.wordpress.com/tag/obiekty-niegraficzne/ Dostęp do tego rodzaju struktur rysunkowej bazy danych, zapewnia VisualLISP. W razie czego mogę pomóc, jak to "ugryźć". Cytuj
2P Opublikowano 16 Lipca 2018 Autor Zgłoś Opublikowano 16 Lipca 2018 1 godzinę temu, kojacek napisał: [...] mogę pomóc, jak to "ugryźć". Zanim spróbuję "ugryźć", to mam pytania: 1. Tak jednym zdaniem, czemu nie LDATA ? - bo wydaje mi się to bardzo wygodne narzędzie i działało idealnie do czasu błędu w ZW 2017/18/19. 2. Czy migracja danych do obiektów niegraficznych ma sens, jeśli te dane są ściśle powiązane i przypisane do konkretnych obiektów graficznych (jak wartości atrybutów w bloku). Pozdr Cytuj
kojacek Opublikowano 16 Lipca 2018 Zgłoś Opublikowano 16 Lipca 2018 1. LDATA są nieefektywne, nieelastyczne i (czasem) mogą być "gubione", jeśli rysunek wędruje i jest zapisywany w różnych wersjach. Może działać tech mechanizm odwrotny - mogą być "wleczone" do innych rysunków, wtedy i tak tracą powiązania, i są właściwie bezużyteczne. 2. Nie wiem czy ma sens - mówię o tym żeby zastąpić teraźniejsze dane w LDATA, innymi przechowywanymi w np. XRECORD. Czyli wymyślenie nowego sposobu zarządzania tymi danymi do wykorzystania obecnie i w przyszłości, jednocześnie zmigrować stare dane, tak aby ich nie stracić i mieć do nich dostęp w dowolnej chwili. Nie znam twojego modelu tych danych, ale myślę że można to spokojnie zrobić. Przy okazji (być może) rozszerzyć ich funkcjonalność. Cytuj
kruszynski Opublikowano 17 Lipca 2018 Zgłoś Opublikowano 17 Lipca 2018 Znalazłem sposób na odczytanie LData z rysunku w 2018. Niestety nie jest to jeszcze gotowe rozwiązanie, ale wrzucam to co znalazłem bo trochę mi pilno do innych zajęć. Jak znajdę chwilę to przygotuję kompleksowe rozwiązanie. (setq DictName "testDict") (setq Key "testKey") (setq dicts ( vla-get-Dictionaries (vla-get-activedocument (vlax-get-acad-object) ) ) ) (setq dict(vla-Item dicts DictName ) ) (setq val ( vla-Item dict Key) ) (entget(vlax-vla-object->ename val)) Zwraca mi taką przykładową postać: ( (-1 . <ENTITY NAME: 26c17198>) (0 . "VLO-VL") (5 . "1FE") (102 . "{ACAD_REACTORS") (330 . <ENTITY NAME: 26c17180>) (102 . "}") (330 . <ENTITY NAME: 26c17180>) (100 . "vlo_VL") (90 . -64512) (91 . 620) (92 . 5) (40 . 3.97) (40 . 94.5289) (40 . 52.43) (40 . 93.7424) (40 . 372.158) (300 . "( (\"RoomID\" \"8011D\") (\"RoomName\" \"m.studio\") (\"RoomBuilding\" \"B.\") (\"RoomLevel\" \"0\") (\"RoomLocal\" \".2\") (\"RoomNr\" \".1\") (\"RoomNrProject\" \"B.0.2.1\") (\"RoomFunction\" \"U\") (\"RoomStrefy\" ( ( (\"StrefaHeight\" (&VLO-R . 0)) (\"StrefaName\" \"Strefa_1\") (\"StrefaPosadzka\" \"\") (\"StrefaType\" \"Z\") (\"StrefaStatus\" \"Pp\") (\"StrefaKorekta\" \"100%\") (\"StrefaTynki\" \"1\") (\"StrefaID\" \"48B7F5\") (\"StrefaAreaPline\" (&VLO-R . 1)) (\"StrefaPerimeter\" (&VLO-R . 2)) (\"StrefaArea\" (&VLO-R . 3)) (\"StrefaKubatura\" (&VLO-R . 4)) ) ) ) (\"RoomAreaPP\" (&VLO-R . 3)) (\"RoomAreaPD\" 0) (\"RoomArea\" (&VLO-R . 3)) (\"RoomKubatura\" (&VLO-R . 4)) (\"RoomFloor\" \"\") )" ) ) poszczególne (&VLO-R . 0) (&VLO-R . 1) (&VLO-R . 2) ... trzeba zamienić na kolejne wartości z listy powyżej (300 ... ) (40 . 3.97) (40 . 94.5289) (40 . 52.43) (40 . 93.7424) (40 . 372.158) czyli (&VLO-R . 0) podmienić na 3.97 (&VLO-R . 1) podmienić na 94.5289 (&VLO-R . 2) podmienić na 52.43 Troche z tym roboty. Jeśli zdecyduej się Pan na przejście na inną reprezentację danych to szkoda czasu, jeśli chciałby Pan pozostać przy LData, to proszę dać znać - przygotuję gotowe rozwiązanie. Choć to może trochę potrwać. Cytuj
2P Opublikowano 17 Lipca 2018 Autor Zgłoś Opublikowano 17 Lipca 2018 12 godzin temu, kojacek napisał: ..... Dzięki za info. Przemyślę sprawę. Dla mnie najcenniejsze w LDATA było łatwe powiązanie z obiektem graficzny. Zastanowię się nad dalszymi losami nakładki Cytuj
2P Opublikowano 17 Lipca 2018 Autor Zgłoś Opublikowano 17 Lipca 2018 1 godzinę temu, kruszynski napisał: Znalazłem sposób na odczytanie LData z rysunku w 2018. Niestety nie jest to jeszcze gotowe rozwiązanie, ale wrzucam to co znalazłem bo trochę mi pilno do innych zajęć. Jak znajdę chwilę to przygotuję kompleksowe rozwiązanie. (setq DictName "testDict") (setq Key "testKey") (setq dicts ( vla-get-Dictionaries (vla-get-activedocument (vlax-get-acad-object) ) ) ) (setq dict(vla-Item dicts DictName ) ) (setq val ( vla-Item dict Key) ) (entget(vlax-vla-object->ename val)) Zwraca mi taką przykładową postać: ( (-1 . <ENTITY NAME: 26c17198>) (0 . "VLO-VL") (5 . "1FE") (102 . "{ACAD_REACTORS") (330 . <ENTITY NAME: 26c17180>) (102 . "}") (330 . <ENTITY NAME: 26c17180>) (100 . "vlo_VL") (90 . -64512) (91 . 620) (92 . 5) (40 . 3.97) (40 . 94.5289) (40 . 52.43) (40 . 93.7424) (40 . 372.158) (300 . "( (\"RoomID\" \"8011D\") (\"RoomName\" \"m.studio\") (\"RoomBuilding\" \"B.\") (\"RoomLevel\" \"0\") (\"RoomLocal\" \".2\") (\"RoomNr\" \".1\") (\"RoomNrProject\" \"B.0.2.1\") (\"RoomFunction\" \"U\") (\"RoomStrefy\" ( ( (\"StrefaHeight\" (&VLO-R . 0)) (\"StrefaName\" \"Strefa_1\") (\"StrefaPosadzka\" \"\") (\"StrefaType\" \"Z\") (\"StrefaStatus\" \"Pp\") (\"StrefaKorekta\" \"100%\") (\"StrefaTynki\" \"1\") (\"StrefaID\" \"48B7F5\") (\"StrefaAreaPline\" (&VLO-R . 1)) (\"StrefaPerimeter\" (&VLO-R . 2)) (\"StrefaArea\" (&VLO-R . 3)) (\"StrefaKubatura\" (&VLO-R . 4)) ) ) ) (\"RoomAreaPP\" (&VLO-R . 3)) (\"RoomAreaPD\" 0) (\"RoomArea\" (&VLO-R . 3)) (\"RoomKubatura\" (&VLO-R . 4)) (\"RoomFloor\" \"\") )" ) ) poszczególne (&VLO-R . 0) (&VLO-R . 1) (&VLO-R . 2) ... trzeba zamienić na kolejne wartości z listy powyżej (300 ... ) (40 . 3.97) (40 . 94.5289) (40 . 52.43) (40 . 93.7424) (40 . 372.158) czyli (&VLO-R . 0) podmienić na 3.97 (&VLO-R . 1) podmienić na 94.5289 (&VLO-R . 2) podmienić na 52.43 Troche z tym roboty. Jeśli zdecyduej się Pan na przejście na inną reprezentację danych to szkoda czasu, jeśli chciałby Pan pozostać przy LData, to proszę dać znać - przygotuję gotowe rozwiązanie. Choć to może trochę potrwać. Dzięki za próbę rozwiązania problemu!!! W ten sposób jestem w stanie dostać się do danych. Ale myślę, że ten mój problem powinien być zgłoszony jako błąd w ZWcad i może w pełnej wersji 19 to już poprawią. Uważam, to za błąd bo jednak wszystkie inne CADy działają jak wersja 15. Prawdopodobnie do tego czasu obrabiać te dane i stosować nakładkę będziemy korzystając tylko z v15. Z mojego punktu widzenia najlepiej byłoby, gdyby poprawka ukazała się jeszcze w wersji 18, bo inaczej wszystkie licencje będzie trzeba sukcesywnie aktualizaować.... Pozdr Cytuj
kruszynski Opublikowano 17 Lipca 2018 Zgłoś Opublikowano 17 Lipca 2018 Tak, oczywiście. Takie zgłoszenie już wysłałem. Cytuj
2P Opublikowano 25 Sierpnia 2018 Autor Zgłoś Opublikowano 25 Sierpnia 2018 Tak informacyjnie. W wydanej ostatecznej wersji Zw2019 (vernum = "2018.07.26(35476)_x64") nie zdążyli jeszcze tego błędu poprawić. 😞 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ą.