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