vlax-ldata-.... a wersje ZWcad

2P
 Share

Recommended Posts

2P Nowicjusz

2P

Posted
Posted

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

2P Nowicjusz

2P

Posted
  • Author
Posted

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.

kojacek Nowicjusz

kojacek

Posted
Posted

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źć". 

 

2P Nowicjusz

2P

Posted
  • Author
Posted
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

kojacek Nowicjusz

kojacek

Posted
Posted

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ść. 

kruszynski Ekspert

kruszynski

Posted
Posted

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ć.

2P Nowicjusz

2P

Posted
  • Author
Posted
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 :)
 

2P Nowicjusz

2P

Posted
  • Author
Posted
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

  • 1 month later...
2P Nowicjusz

2P

Posted
  • Author
Posted

Tak informacyjnie.
W wydanej ostatecznej wersji Zw2019 (vernum = "2018.07.26(35476)_x64") nie zdążyli jeszcze tego błędu poprawić. 😞

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing