On 09:17 PM 30/01/2002 -0500, Abd ul-Rahman Lomax said:
>A note first: this could be getting fairly abstruse. We are discussing the
>fact that to use the spreadsheet to edit data on a schematic requires that
>the schematic and spreadsheet remain open from creation until update,
>otherwise it fails because internal links between the spreadsheet records
>and schematic primitives have been lost. One can see these links if one
>copies the spreadsheet data into Excel.
>We'd like to be able to update schematics with spreadsheet data where the
>links have been lost, perhaps because the files were closed, or perhaps,
>even, because the links never existed since the spreadsheet data came from
>outside. To do this, the new spreadsheet data must be linked, somehow, to
>appropriate schematic primitives.
**My reality check **
"..where the links have been lost,.." means to me - the links are broken
or non-existent, as opposed to the desirable condition of persistent
links/handles/GUIDs where closing the Sch session does not loose the links.
>At 08:24 AM 1/31/2002 +1100, Ian Wilson wrote:
>>>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?
>*** Reality Check ***
>What is being proposed is the *addition* of facilities, not limitations.
This is news to me - my reading of this thread is that we were discussing
the limitation of the current system that requires the schematic(s) to
remain open while undertaking spreadsheet editing. The addition of a
facility that allows automatic or semi-automatic matching of an external
spreadsheet with an existing design (no matching handles) is a relatively
recent addition to the discussion (unless I have missed something - which
is not too unusual, as I do not really like reading computer screens and
tend to skim emails).
My discussion was *purely* based on solving the limitation on having to
keep the Schematic session open. It is not designed to address any other
possible requirement. I think we need to keep the two requirements quite
separate to prevent any confusion (mine).
>Right now, if designators are changed, we are stuffed.
Well, not in the case of an exported spreadsheet we are not. Designator
changes can be updated from the spread - since the matching is not done by
designator. In the case of an external (not exported) spreadsheet then the
situation is different....
>Physical location is not directly usable to recover links. So what is
>being proposed is the addition of facilities. If designator is changed but
>location remains, linkage can be restored. If location is changed but
>designator remains, linkage can be restored. If both are changed, yes, no
>method has been proposed to restore linkage. It starts to get difficult.
>But the difficulty has not been created by the proposed facility, it
>pre-exists. It might be possible to link on connectivity. I can't think of
>much else that could work.
>An unstated assumption was that part types did not change. "location" in
>what I wrote meant that a particular part type (library reference) was at
>a particular location.
>There would be a relink command that would link a spreadsheet to
>Schematic; it would make the linkages for parts based on (a) reference
>designator or (b) type/location.
or (c) by matching the GUID allocated to each component (in my proposed
solution) which would of course be a readable but not changeable attribute
of a Sch component. It would be like a read only Part field (in that it is
component specific, not allocated by the library editor, but not
changeable). An external spreadsheet could have the GUIDs added
(manually/macros/whatever) to "force" a reliable match.
(Actually there could be two GUIDs - one for the library part and one for
the Schematic instance. This may help overcome some of the issues we have
with poor library management - but this is an issue for another thread...)
>Whatever cannot be recovered by these means would be ignored. In other
>words, if you have a spreadsheet with ten parts in it and nine of them can
>be relinked to parts on the schematic, nine would be linked, the tenth
>would be ignored. A message would presumably be issued giving some
>information about the ignored part, ideally its data would be dumped to an
>This would mean that you could modify parts on the schematic directly from
>spreadsheet data from some outside source, presumably linking based on
>The facility to link based on schematic sheet coordinates would allow
>recovery from reannotated schematics. It wouldn't have much other use.
>>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.)
>Handles could themselves be restrictive, because they would need to be
>supplied for data import.
Not really. They could be used if available - just as your solutions are
only as useful as the information that pre-exists. On external data
persistent handles become another option when doing the synchronisation
between external spreadsheet data and the Sch.
As far as I can see it:
1) Improving the existing limitation on editing Sch in a spreadsheet
requires persistent handles. A GUID is one option.
2) Others dealing with external data (often) have some use for additional
tools that would work somewhat like the current Sch<->PCB synchroniser but
with spreadsheet data. Useful match methods include: Designator, Location,
GUID and ....
Do we agree on anything?
Hopefully Protel are watching this thread and taking on the requirements
and thinking how they could be satisfied.
Bye for now,
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
* To leave this list visit:
* Contact the list manager:
* mailto:[EMAIL PROTECTED]
* Forum Guidelines Rules:
* Browse or Search previous postings:
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *