At 09:23 AM 29/01/02 -0500, you wrote:

>>When a spreadsheet from the database is created by schematic, it is by 
>>default locked. I'd say that 99% of the time we'd rather have it not 
>>locked. Or at least it would be nice to have a single button "unlock all."
>Actually, there is such a button, as I found when I was verifying the 
>process. I gave it later on in my article  Until then I was using 
>Format/Protection/uncheck Locked, which seemed to work on the entire 
>database if it is selected when the box is unchecked, at least one can 
>then paste into A1.
>But what is weird is that you can manually edit individual fields without 
>unchecking Locked or turning off protection. I think. But I get nervous 
>even trying. I don't like seeing Exceptions that advise me to reboot, even 
>if I seem to be able to get away with ignoring them.
>The requirement that the spreadsheet editor and schematic file remain open 
>is tedious if nothing else. What if I'm doing a large amount of work, do I 
>have to stay up all night to complete it? Now, in fact, I can get around 
>this. I can save my data in Excel and remerge it, with some care, with new 
>data from a spreadsheet created the next day. The links will be different, 
>care must be taken.

Yes I agree that it is tedious - but the only robust alternative that I can 
see would be using a GUID - that is a Globally Unique ID.  You may have 
seen some of these if you ever browse through your registry (eg one form is 
like F3CA5749-C5DA-11CF-8F28-00AA0060FD48).  These are numbers that are 
basically guaranteed to be unique, around the world, forever.  They are 
typically based on network adapter MAC, hard disk s/n, bios, time and date 
etc.  Assigning a GUID whenever a component is created would allow a 
permanent mapping to that unique instance of the component. This may bear 
some thought, Protel.

Currently, though, the unique handle is created when the Sch is loaded or a 
new component added to the Sch.  The handles are not persistent between 
sessions and hence the current requirement of keeping the Protel session 
and the Sch sheets open while editing in the spreadsheet.

Working with handles will be faster than working with a GUID, btw, as the 
GUID link would involve a potentially slow search - although a map data 
structure that maps GUID to handle could be added to Protel - at the 
expense of yet more memory (which is cheap).

>I can see why Update from spreadsheet has this problem. There is no unique 
>identifying field for schematic primitives. If you have two identical 
>primitives at the same location, the only thing distinguishing them, I 
>think, is their sequence in the file and in memory, the links refer to 
>memory location, which is why both files must remain open (and I'd guess 
>that there might be problems if you edit the schematic directly while in 
>the middle of working with the spreadsheet).

The links are not actually memory locations but rather handles.  A handle 
does not need to be a pointer to fixed memory.  The terminology is a little 
confused these days and I do not know the internals of how the handles are 
used in Protel - that is, what nomenclature is Protel using when they use 
the word 'Handle'.

In not atypical Protel fashion - there used not to be very defensive 
programming associated with the update.  The handle was believed rather 
than validated first.  Hence the spectacular crashes when you try to run 
across a session.  Some Try/Except exception processing would be worthwhile 
(maybe it has been added) even at the expense of some update speed.

>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 

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.

>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.

>Once this is possible, one could theoretically create an entire schematic 
>by import of primitives through spreadsheet. And this would make it easier 
>to write schematic translators....
>Likewise PCB spreadsheet should export *every* primitive in the file, 
>including rules, classes, etc. Many times we have wished for this or that 
>primitive to be available. If there is an option in the Spreadsheet Wizard 
>"complete export" it would be enough, it would not be necessary to add 
>every detail to the export option list.

This is what the flat file ASCII format is for.  The spread export is 
really more suitable for data where the column data is similar.  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.

That said I would like the ability to export all the attributes of an 
object I am interested in - no hidden attributes that can't be exported.

>For example, we should be able to edit selection status in the PCB 
>spreadsheet; selection is not exported, unlike the situation in Schematic.

This is just another sign of the lack of consistency between Sch and PCB.

Ian Wilson

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
* To leave this list visit:
* Contact the list manager:
* Forum Guidelines Rules:
* Browse or Search previous postings:
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to