【转帖】considerations for handling revisions

yang686526

considerations for handling revisions
dear api gurus:
i am in the process of creating a macro that inserts and updates a solidworks revision table in a drawing. the current design intent is to read the 8 latest revisions of the model and display that in the drawing. each revision has various information (description, rev level, date, by, etc), so each piece of rev info is a string of text as a custom property. probably many people handle revisions in this manner. unfortunately, when you get to 10 plus revisions, you start to have 40-50 custom properties, which gets hard to lookup. my question then: is there a better way to store revision history in the model; and, does the increase in custom properties slowdown speed or increase filesize? i have been kicking around alternatives, and thought that the best way would be to embed an excel spreadsheet in the design binder as a revision table. i could read the cells and send them to the sw rev table, and everything would be consistent. your thoughts??
to defeat the wheat, go against the grain.
tom,
with "hard to look up" - do you mean in regards to performance? did you consider using document manager to retrieve the properties? it will propbably be faster than using the sw api.
jorn bjarning
cswp
cad & plm consultant
sw2008 sp5 / sw2009 sp2
take a look at modeldoc2::iget3rdpartystorage
bjorn, what i meant was that it becomes a bit of a pain to scroll down through the list of custom properties when the list gets too long...my eyes need to adjust their "vertical hold" after a while.  i will look at the document manager; i have never used it before, so it will be fun to learn something new!
luke, thanks for your input as well. as i haven't used docmgr before, i certainly haven't delved into its api. however, i can research that and see where it takes me. as far as my experience with api overall is concerned, i'm kind of a "begintermediate." (i thought that up myself.)
tchuss!
to defeat the wheat, go against the grain.
you could write a macro that presents a form that organizes key properties for review and editing. i have done this for clients in the past.
tru dat, rol&.
i have done so as well, and i will probably use the form i have created. what i am questioning is whether custom properties is the place to contain revision history in the model, or would it be better kept in another place, such as an excel spreadsheet attached in the design binder (embedded or linked). with the use of excel, it is easier (imo) to tie the main revision level to the current revision via an excel formula, rather than use api to discern it. besides, excel would present the revision table in a better format than listing each piece of revision information in the custom properties, and i'm thinking that it would be less byte size embedded in a spreadsheet than as part of an ever-growing list (though i have no evidence to support that theory). in either case, api can be used to retrieve the data and send it to the drawing's revision table. i can go either way, i'm just speculating as what way would be better in the long run. what's your opinion?
to defeat the wheat, go against the grain.
edited: 07/30/2008 at 10:19 am by tom fosler
originally posted by: tom fosler
tru dat, rol&.
i have done so as well, and i will probably use the form i have created. what i am questioning is whether custom properties is the place to contain revision history in the model, or would it be better kept in another place, such as an excel spreadsheet attached in the design binder (embedded or linked). with the use of excel, it is easier (imo) to tie the main revision level to the current revision via an excel formula, rather than use api to discern it. besides, excel would present the revision table in a better format than listing each piece of revision information in the custom properties, and i'm thinking that it would be less byte size embedded in a spreadsheet than as part of an ever-growing list (though i have no evidence to support that theory). in either case, api can be used to retrieve the data and send it to the drawing's revision table. i can go either way, i'm just speculating as what way would be better in the long run. what's your opinion?
tom,
some time has passed on this and i'm curious how your implementation has fared. i ask as i'm in the process of implementing a similar type feature to xmlpropworks, mt fully user configuration custom property management tool.
the problem i face is that there is no standard format to any of the data. the data is completely user configurable. what i will probably do is allow the user to define a term which xmlpropworks will use to parse through the customproperty data in all the configurations and then massage the revision table in the drawing.
the main hurdle to jump at this point is how to incorporate drawing only changes into the process. i've run into this problem before and never really developed an elegant solution. now is as good a time as any, i suppose.....
any feedback on the discussion would be greatly appreciated. even words of solace would help at this point ;>
by the way, i'm hopeful to have a fully functional beta test version of xmlpropworks ready in a couple of weeks. if anyone is interested in becoming a tester, please let me know. i'll be setting up a tracproject wiki/webpage for collaboration amongst the testers to help me manage the final testing program.
quick