Rekomendowane odpowiedzi

Opublikowano

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

Opublikowano

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.

Opublikowano

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

 

Opublikowano
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

Opublikowano

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

Opublikowano

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

Opublikowano
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 :)
 

Opublikowano
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 miesiąc temu...

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

Gość
Dodaj odpowiedź do tematu...

×   Wklejono zawartość z formatowaniem.   Usuń formatowanie

  Dozwolonych jest tylko 75 emoji.

×   Odnośnik został automatycznie osadzony.   Przywróć wyświetlanie jako odnośnik

×   Przywrócono poprzednią zawartość.   Wyczyść edytor

×   Nie możesz bezpośrednio wkleić grafiki. Dodaj lub załącz grafiki z adresu URL.

Ładowanie