Storing data using lisp

Storing data using lisp

Anonymous
Not applicable
2,884 Views
14 Replies
Message 1 of 15

Storing data using lisp

Anonymous
Not applicable

Im just after some advice on saving data.

 

Ive currently got a couple of dynamic blocks that create a visualisation of one of our products from an opendcl dialog. Once the drawing has been approved by a customer i pull the data from the block and use this to create parts for production. This works very well but is quite restrictive. Im currently writing lisp routines that will draw this and store the data in the block as xdata so in future the opendcl dialog can be opened and populated with this info for modifications.

 

My question is where is best to store this data (currently as xdata in the block). There could be 60 different pieces to save. I cant attach anything from work as it is sensitive.

 

Thanks in advance

Dan

0 Likes
Accepted solutions (1)
2,885 Views
14 Replies
Replies (14)
Message 2 of 15

SeeMSixty7
Advisor
Advisor

Write this data to a database. Then sorting and recalling the data is simplified for you.

 

A Text file is another option, but does not offer the benefit of queries.

 

Good luck,

 

 

0 Likes
Message 3 of 15

Anonymous
Not applicable
I thought of that but want to keep the data self contained in the drawing, and also doesn't require a database to maintain. But thanks for the reply
0 Likes
Message 4 of 15

dbroad
Mentor
Mentor

@Anonymous,

 

I'm sorry but statements like "I cant attach anything from work as it is sensitive." completely turn me off.  Make something up if you have to that has parallels or is similar but otherwise all we can do is vaguely guess what your requirements are.  This is an open forum of volunteers.  People contribute for the benefit of all. If you need confidential assistance, you should consider hiring a programmer with a non-disclosure agreement.

Architect, Registered NC, VA, SC, & GA.
Message 5 of 15

SeeMSixty7
Advisor
Advisor
Accepted solution

Try using a DataDictionary then. You can store data in a dictionary stored in the drawing with basically variables or defintions.

 

(vlax-ldata-put "MyDictionary" "MyDataValue" "the Value")

 

then access that data by requesting the data

 

(vlax-ldata-get "MyDictionary" "MyDataValue")

 

you can store pretty much any kind of data numeric, string values, lists...

 

good luck.

 

 

Message 6 of 15

Anonymous
Not applicable

I wasn't asking for anything to be written, i asked for an opinion on the best place to store information in a drawing.

 

I wrote that im currently saving the data as xdata in the block. I wondered if the data would be better stored elsewhere is all.

 

For clarification:

I currently save information like (50 150 25 5 "Front" "Upper" 12 4000) converted to a string and saved as xdata. Is this the best place to keep it for retrieval later?

0 Likes
Message 7 of 15

SeeMSixty7
Advisor
Advisor

Looks like something like this would work for you then

 

(vlax-ldata-put "MyBlockData" "MyBlockName" (list "BlockState" 50 150 25 5 "Front" "Upper" 12 4000))

 

then access that data by requesting the data

 

(vlax-ldata-get "MyBlockData" "MyBlockName")

 

That would return

 

("BlockState" 50 150 25 5 "Front" "Upper" 12 4000)

 

Good luck.

Message 8 of 15

Anonymous
Not applicable
SeeMSixty7
I've used ldata in some smaller projects iv done but recently read that there is the possibility of corruption issues whilst using ldata.

Have you had any issues with this?
0 Likes
Message 9 of 15

SeeMSixty7
Advisor
Advisor

I have not had any issue with dictionary data. I've only used it for setting very basic data sets though, similar to what you have. For what you want to do I can't see any reason to worry about data corruption.

 

 

 

 

0 Likes
Message 10 of 15

dbroad
Mentor
Mentor

I don't know why you need to save data anywhere else unless you are adding additional information beyond the dynamic block properties.  Dynamic block properties are accessible directly from dynamic blocks and via the properties palette.  Access them via the dynamic block properties of the block via activeX.  You can store additional data as xdata but that requires specialized formatting of the lists.  There are several traditional ways to store data:  hidden attributes, xdata attached to objects, and dictionaries.  Attributes are available for editing in the attribute editor.  Xdata will need to be managed by special program. Dictionaries are similar to xdata but allow the data to be stored in a centralized location rather than at the object itself.  Extension dictionaries are attached to each object.

 

When deciding which way to go, think about how easy it is to access data.  If you want to make it easy, stay with dynamic block properties and attributes.  If you want to hide it, use xdata, extension dictionaries, dictionaries or persistent reactors.

Architect, Registered NC, VA, SC, & GA.
Message 11 of 15

dgorsman
Consultant
Consultant

Extension dictionaries are attached to objects, just as XDATA is.  You can create a name-referenced, tree-like nested data structure that is insensitive to order of data; it requires extra work to find objects which have that data since selection sets won't filter on Extension Dictionaries/XRecords.  XDATA can be useful when dealing with selection sets, as you can filter based on the REGAPP name; but then again, you have to deal with REGAPPs, as well as being bound to specific order of data if you don't have enough DXF key values to work with.  I haven't had many problems using LDATA but it can be very restrictive; as there is only one LDATA on a give object, you can't easily extend it.

 

One thing I wouldn't do is convert back-and-forth between numbers and strings for non-attribute data storage.  If the number is a real, store it as a real; if its a string, store it as a string.  Keep the values discrete so they can be referenced by either a DXF index code (XDATA) or name (XRecord).

----------------------------------
If you are going to fly by the seat of your pants, expect friction burns.
"I don't know" is the beginning of knowledge, not the end.


Message 12 of 15

john.uhden
Mentor
Mentor
I have not had any problems with ldata, but dictionaries are a great place to hide things. You can add your own dictionary to ModelSpace; it is an object.

John F. Uhden

0 Likes
Message 13 of 15

Anonymous
Not applicable

I'm not sure why you need to store the data twice in the drawing if all the information is in the block.

When you reopen the drawing, you can read the block and populate the dialog box with the info.

If you need to store additional information with each block, you could create invisible attributes and store the information there.

0 Likes
Message 14 of 15

scot-65
Advisor
Advisor
My general thoughts on this...
If it has something to do with the drawing environment, use the drawing's Dictionary.
If it has something to do with user settings, store in the Registry (SETCFG is now obsolete).
If it has something to do with an object (such as a block), embed the data into the object.
If it is none, some or all of the above, write to an external file.

As far as corruption issues, it is possible the data that was stored used the same name
for two different situations and the second had overwritten the first, and the first tried
accessing the data, but failed.

???

Scot-65
A gift of extraordinary Common Sense does not require an Acronym Suffix to be added to my given name.

Message 15 of 15

Anonymous
Not applicable
I'm moving away from dynamic blocks so a user can create modifications if/when the need arises.

Ive gone down the ldata route for now but will probably upgrade to xrecords in future. I'm not trying to hide the data as such I just don't want it accessible by everyone.

I also wanted to keep the data out of the block as some people like to meddle.

As for corruption on ldata I'm saving the data with a key the same as the block name, and deleting it as soon as it is read and put into a list. Then putting it back in when all modifications have been made. So I'm not overwriting the values now I'm replacing. Thanks for that scot.

Thanks for all the replies
Dan
0 Likes