It seems like sch parts already have a persistent handle -- this is used by
the synchronizer to match to the PCB, right?

Further comments embedded...

> -----Original Message-----
> From: Abd ul-Rahman Lomax [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 30, 2002 10:22 PM
<snip>
> Sure, GUIDs would make for reliable matches, but at the cost of severe
> inflexibility, in my view. If I have a schematic with a 10K resistor R25
on
> it, and I delete that resistors. Then I think better and replace it. The
> GUID is now different, isn't it? But *I would want any spreadsheet update
> to be able to work on R25 across this process*.

This would only be a problem if you want (a) to update this modified sch
from some file that was exported before the change was made; or (b) to
update/synchronize the exported file (instead of just re-exporting).  I
don't want that level of complexity added to the product.

<snip>
> But handles, if they exist, could be useful, just as they could produce
> incorrect results (like any of the other methods). For example, I have two
> resistors, 1K and 10K. The engineer says, swap them. So I pick them up and
> move them. Then the engineer says, oops, swap them back. So I edit the 10K
> to 1K and the 1K to 10K. Connectivity linking would be unconfused. GUID
> linking would get it wrong,
> presuming that a part retains its GUID when moved and when its value is
> changed....

Again, not a problem unless you're trying to re-synch with an outside file.

<snip>
> Persistent handles would be useful for the single problem of
> how to allow closing the files in the middle of the process. Persistent
> handles would thus be useful, but they would not increase the flexibility
> of spreadsheet editing for import of outside data.

Let's not confuse two different requirements:

(1) An enhancement to simplify the use of spreadsheet-style editing of an
existing schematic.  All that's needed is a reliable (persistent) way of
matching incoming data to the sch.  A wizard (similar to the sch-PCB
synchronizer) would do nicely.  It would use a persistent handle for primary
match, refDes for secondary match, and allow the user to adjust those
matches.  Unmatched sch components could be (optionally) deleted.  This
enhancement would NOT support connectivity changes.  I think this would
address many of the complaints & wishes expressed on this list over the
years regarding export-to- and update-from- spread.

(2) Other enhancements that would allow an external file (that may or may
not have originated from the sch) to be used to update the sch, including
updating connectivity and adding new components.  I think this is a much
larger project, and not as widely beneficial.

I wouldn't want Altium to not do (1) because they thought they had to do
(2).

Dwight.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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://www.mail-archive.com/proteledaforum@techservinc.com
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to