TheSwamp
Code Red => AutoLISP (Vanilla / Visual) => Topic started by: Kerry on February 22, 2011, 09:22:55 PM
-
This is a precautionary tale ...
I've had an application that add XData to entitys for identification and references to databases containg catalog information
... fairly simple app.
Over time the requirements for a string element in the XData has grown.
Recently it reached critical mass :-o
The string is saved as normal in the XData and all processes work as expected.
BUT, the AUDIT command actually checks the length of XData strings and truncates the string to 255 characters.
ie
Auditing AutoCAD Data...
Pass 1 400 objects auditedAcDbBlockReference(232ED)
XData String Length 301 > 255 Truncate to 255
AcDbBlockReference(232FC)
XData String Length 301 > 255 Truncate to 255
.... so the data was hosed ... and it would only happen after an AUDIT.
My solution was to save the data as an XRecord and Dictionary attached to the entity.
Required a breaking change to the app but it's a lot more managable that not being able to read the data.
-
Thanks for the Heads Up. 8-)
I assume you ruled out compressing the data string?
-
Hello Alan
I considered it but wanted the data to be human readable without parsing.
( if I understand what you mean ) :)
-
You understand quite well. 8-)
-
Haven't run into that one yet directly; I've seen it indirectly with a professional application that uses XDATA. Good thing I've already moved from XDATA to Dictionaries and XRecords.
-
A long shot here and could be a stupid question from an halfwit but I half to ask.
Would this cause Autocad to lock up with an JIT debug alert after running an Audit and purging Xdata? (Note Windows Task Manager does not register that it is locked up but AutoCAD is.)
It will randomly crashed when I use either of these routines. TotalPurge (http://www.theswamp.org/index.php?topic=36826.0) or QuickClean (http://www.theswamp.org/index.php?topic=32375.0)
-
Nearly six years after first posting I want to refresh the topic:
In 2017 it seem to work fine with a string-length of 332; it can read and write the data. But "_audit" changes it:
"AcDbPolyline(29D) XData String Length 332 > 255 Truncate to 255"
Is there a current reason for the limitation (in 2017) or is it because of legacy?
-
Nearly six years after first posting I want to refresh the topic:
In 2017 it seem to work fine with a string-length of 332; it can read and write the data. But "_audit" changes it:
"AcDbPolyline(29D) XData String Length 332 > 255 Truncate to 255"
Is there a current reason for the limitation (in 2017) or is it because of legacy?
I imagine you'd need to ask someone who is responsible for the design.
-
It's more likely that it was a bug that allowed > 255 bytes (which is the spec) to be placed. Relying on an aberration that seemingly violates a spec or is not backward compatible is seldom a strategy that will end well. Hope the lesson is inconvenient rather than painful.
-
...Hope the lesson is inconvenient rather than painful.
Yes, I detected it before anything bad happened.
Thanks for the answers.