Originally Posted by: NickB 
This would be an unbelievably useful feature.
Add my vote.
Also useful would be a way to name parts when creating them without having to make a special trip to the Inspector. Clients hate parts with seemingly random numbers for names.
----
To expand on that, imagine a small, fast, useful (user-modifiable) database such as SQLite in the background. It could be tied to the BOM, and the BOM could be (with a capable user or IT handle on things) tied to a costing system. But, as for the drawings' parts, i think that this has to be reengineered so that the comments don't change on export/copy/import/reimport. There should also be a human-readable mapping in the unlikely or undesired event that the database gets disconneted from the file.
With a database, each drawing would only need links or pointers to the information, and those pointers in the drawing would link into the SQLite-type of database (please, do not make it ms access or jet-dependent -- we need freedom and flexibility to move OUR data to and from what WE chose, and not become locked into any one app.... thanks!)... This could help keep the parts content from overtaking the drawing data itself. There would need to be user-toggleable pop-ups, or a user-enabled keystroke to either a keyboard or a mouse such as (if it exists) this:
http://www.everythingusb.com/openoffice-mouse-17977.htmlhttp://www.mobilewhack.com/open...s-now-the-warmouse-meta/http://www.maximumpc.com/articl..._mouse_now_warmouse_metaI suggest a database because in my case, i will have hundreds of parts or tags/labels in the structure of my ship models. If i delete hundreds of them at once, a "pointer kill" could flag them to be killed in the database. But, if they (the flags or the labels) are in the drawing and the drawing is badly corrupted, then all sorts of useful information that is not a drawing would also become lost. Many people 15 or 20 years ago suffered this excruciating pain with ms access when ms decided that keeping the data locked in the database was good (for them? the user?). But, invariably, people lost or corrupted the database INTERFACE, and got screwed out of their data. USER Data should NEVER be held hostage (technically or philosphically) by the application. There should be a minimal exportation/importation even if the user has to give up the proprietary bells and whistles. At least the DATA will be there, though, unless that separate layer is trashed. But, if a VC or Shark file gets corrupted, or if the user gets carried away deleting stuff and undoes it only to redo and undo it again, all that overhead could chew up RAM when the database can be compacted later, allowing the drawing app itself to worry more about retained items than those being un-deleted.
But, for all i know, Punch! might have some technical trickery to do this and make it all transparent. But, then again, suppose we have a library of parts in a database (app or spreadsheet) and that that database governs what belongs in the drawing. We cull the list down to the essentials. Now, as we draw, we associate in-progress geometry to that database item, by name, count, coordinates, etc. It could be a built-in progress tracker. Any supervisor looking at the file locally or across the LAN/WAN/VPN could determine productivity, scheduling or resource burden or underutilization. Revisions of drawings could be made by seeing the parts or reviewing an SQL-based progress meter. If the catalog vendor specs or client say some part is to be of given material, size, and treatment, then the catalog or in-house design reference can help ensure that the drawn geometry (especially if it's 3D) is accurate or within agreed-upon tolerances as to shape, weight, centers of gravity and so on. No more looking at 2D geometry and trying to determine if it will fit, of if it's too heavy, or too light, and so on.
Just my (eye)deas...
