On 03:54 PM 30/01/2002 -0500, Abd ul-Rahman Lomax said: >At 12:40 PM 1/30/2002 +1100, Ian Wilson wrote: >>>So there is no way to restore all the links properly, I suspect the >>>programmer thought. Except that if two primitives are identical, it >>>really doesn't matter much which one of them gets updated with which >>>copy. Given this understanding, it should be possible to reconnect a >>>spreadsheet and schematic. >> >>I could make massive changes, wholesale changes, inside the spreadsheet, >>including, I suspect, but have not tried, library reference >>changes. Certainly I can change the coordinates of a component, its >>designator etc etc. So without the unique handle how do you deal with >>the mess? If you have all the possible info exported then I guess it >>would not matter, in fact you could simply delete all the components and >>add new ones containing all the required attributes. But what happens >>when I export only a subset of component attributes, but then go and make >>wholesale changes to that subset? I would not support a solution that >>*only* worked if you export all attributes of all components. It make it >>needlessly hard to find/change the data you want and manipulation macros >>can (in some cases) become more complex. > >Yes, it is necessary to be able to identify the original primitive when >making changes through spreadsheet. My comment was regarding two >*originally* identical primitives. Same location, same everything. >Essentially, preserving the *was* information in the spreadsheet would >accomplish this. To make changes one might add change fields to the >spreadsheet, the exact scheme would take some thought.
So now we go back to the old ways of back-annotation style programming where if you miss one update between change sets you are stuffed. I like the idea of getting rid of the keep-the-session active limitation on spread-export and import but I do not want *any* limitation on how I deal with the external data. I will have to accept that there is a unique identifier that must remain unchanged with each spreadsheet record (row) - but wouldn't it be desirable to minimise the info that needs to be kept unchanged? As I read your proposal you are requiring that the sheet reference, the component coord, type, and attributes are all stored repeated in the spreadsheet - one special set of which we are not supposed to edit. And wouldn't we need to be careful with maintaining the update regime just like the bad old days of back annotation with the was-is file? I prefer the concept of the existing system of a unique ID but make it a persistent ID, something like a GUID. >>>So if an Update is attempted and the links are missing, Protel should >>>recreate them, just as it can create links between Schematic and PCB. >> >>But it does this via designators (on the first pass of the Synch). I may >>have made big changes to the designators in my spreadsheet and so now >>what are you going to map on? I would *not* support any change that >>relied on designators as an identifier. > >Well, having the facility to create the links based on designator would be >useful. That way one could use the spreadsheet to manipulate all other >aspects. The other way to recreate links would be through physical >location. In other words, if one had a spreadsheet where designators had >been changed, one could still restore links through physical location. >This would be *very* useful to recover schematic-PCB correspondence where >someone had reannotated the schematic. And when we have changed designator and location we are broken. Why add the limitation on how we are to operate? >I once had a client do that, with a Tango Schematic, after editing it with >many changes for a very complex PCB. I had the original schematic files, >fortunately, so I was able to establish the physical location of each part >-- from the ASCII file -- and I used that to recover the original >reference designators. New parts that could not be clearly identified were >given ? designators. Because Tango supported WAS-IS reannotation files, it >was relatively easy to take this data back into the schematic database. > >>And anyway the ASCII format data can be imported into Excel - using '|' >>as a separator. So we have this - it is just called Save-As rather than >>export. > >Yes, we can do it now. However, this must be done with closed and exported >files, which must then be reimported, and the process is cumbersome. > >First of all, Schematic ASCII is not, unlike PCB, self-documenting. It's >moderately easy to read, but it is not readily separated into records nd >fields, rather records are hierarchical. On the PCB side, however, the >database has labelled records and is field-delimited with "|". That does make a difference. I have not looked as a Sch ASCII file for ages so I am embarrassed by my forgetfulness - seems to be happening more often these days :-( So yes the ability to export all to the spreadsheet (all meaning all attributes) is certainly useful. My fundamental issue with the sorts of solutions you are proposing is that they tend to be adding restrictions that we do not have in order to remove a restriction we do currently have. I would like a solution that removes the current limitation without adding another. Making the handles persistent would allow this (though the persistent part can't be a real OS handle of course.) Ian Wilson * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To leave this list visit: * http://www.techservinc.com/protelusers/leave.html * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * Forum Guidelines Rules: * http://www.techservinc.com/protelusers/forumrules.html * * Browse or Search previous postings: * http://email@example.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *