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 
>error file.
>This would mean that you could modify parts on the schematic directly from 
>spreadsheet data from some outside source, presumably linking based on 
>reference designator.
>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,
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:
* 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