Rather long post; please read carefully if you want to respond...

> For a number of reasons I have been playing about with moving selections
> and flipping them ('X' and 'Y' keys) and swapping layers ('L' hot key).
>
> I have found that it is possible to make tracks and surface pads
> disappear.  They look like they are no longer there (deleted) yet their
> (invisible) vertices are still netlist targets - they are just invisible.
I
> have not plumbed the depths of the effect (I just found a new effect
> whereby not only do the tracks disappear but components are way off the
> intended area).
>
> Symptom:
> ----------------
> When flipping layers of a moderate to large selection, tracks and surface
> pads can disappear and, sometimes components get placed in a wildly
> incorrect positions.  Through hole pads do not seem to be affected.

<snip>

> Protel have been informed and can replicate the issue.  Hopefully this
will
> be a SP7 fix.
>
> Ian Wilson

I tried what was suggested: I took a "real world" PCB file, selected
*everything* in this, and then pressed the L key after invoking the Move
Selection command.

The outcome (without even attempting to then invoke the "Undo" command) was
a proverbial pig's breakfast. I was previously aware that use of the L key,
while using the Move Selection command, typically produces an undesirable
outcome, but when I tried it this time, with an *entire* PCB file, I was
blown away...

But wait, there's more. Before the release of the Power Print Server, I used
to *mirror* the entrire contents of PCB files whenever I wanted to produce
Composite Mode printouts of items on bottom side layers, to wit, when
creating ("real world" view) Bottom side Assembly printouts.

Theoretically, this is no longer necessary when using the Power Print
Server, as this supports the generation of printouts of a mirrored nature.
However, I have been requested by fellow employees to create Acrobat files
in which the pages of Assembly printouts (also) contain searchable text.
("There are umpteen hundred components installed on this PCB. Now, exactly
where on the PCB is component R104 installed? ...") To achieve this, I
select the option (provided by the Power Print Server) of using *Windows*
fonts rather than *Protel* fonts. However, as I have reported previously,
both to this forum and directly to Protel, text strings can be displaced
(from their actual locations) within the resulting *actual* printouts,
*unless* the printout is of a mirrored nature. This means mirroring the
entire PCB file to produce (acceptable) Top side Assembly printouts.
(Arrrgh!!) :(

I've explained the background. Typically, I create the Bottom side Assembly
printout (usually, a one page Acrobat file). I then mirror the entire PCB
file, create the Top side Assembly printout (another one page Acrobat file,
which, with the Acrobat file created just previously, and yet another
Acrobat file created from the PCB's associated Schematic file(s), then get
assembled into one single new Acrobat file, this being created and used to
document the PCB in question), and then close the PCB file *without saving
it first*. As such, the PCB file which is saved (to disk) is in an
*un*-mirrored state.

However, after reading Ian's post, I investigated what happens when I
*mirrored* an *entire* PCB file, and then invoked the "Undo" command. The
mirroring proceedure itself runs without problems (with SP6, you are now
warned that "Warning: you are attempting to flip a component to the same
side of the board. ... Do you wish to continue?"), in that the outcome of
this matches what is expected. (Qualification: Dimension and Co-ordinate
objects are not without problems (the text strings within these can not be
mirrored), but I don't tend to use these within PCB files that I design.) If
the PCB contains polygons, you are prompted as to whether you want these
repoured; in these circumstances, I do *not* select that option (as I just
want to mirror the PCB file, *without* repouring any integral polygons as
well).

When I then invoke the "Undo" command, I am once again prompted if I want
the polygons repoured. I did not want these repoured when I moved the
selected items in the first instance, so as far as I am concerned, I do not
want them to be repoured when I then proceed to undo that command; in fact,
I consider that a genuine "undo" procedure would have recorded my response
as to whether I wanted polygons repoured or not (when I moved the selected
items), so avoiding the requirement to ask me the same question again during
any consequent "undo" procedure.

If I select the option of *not* repouring the polygons, the polygons within
the PCB file are *not* restored to their previous location (or orientation,
mirror-wise). As far as I am concerned, the "undo" procedure has not undone
everything; the PCB file now differs from what it was like previously! (If
you select the option of repouring the polygons instead, the polygons *are*
restored to their former locations. However, they have now been repoured,
and as such, the PCB *can* still differ from what it was like before
invoking the Move Selection command and then undoing it.)

Further discovery: even if you *don't* mirror the selected items (using the
X key or Y key) while moving these, the locations of any non-repoured
polygons are again *not* restored if the "undo" procedure is subsequently
invoked.

I suspect that Protel envisaged that users would use the L key *only* while
moving a *single* component (or a *single* primitive item occupying a layer
of a "paired" nature). The outcome of using the L key while moving selected
items (instead) is definitely defective, as Ian has reported. But my
subsequent investigations have revealed that polygons are definitely
problematic as far as the "undo" procedure is concerned.

It is not unreasonable to observe that recording the "before" and "after"
locations (and other properties) of each constituent primitive object within
each polygon object could involve "logging" no small amount of associated
data, in the event that an user *does* select the option of repouring
polygons while moving selected items; this "logging" would be necessary to
support a totally kosher "undo" procedure in the event that polygons (for
which repouring has been selected) are amongst items being moved by a Move
command. (An argument could be advanced that future versions of Protel
should *not* support polygons being repoured while *any* Move command is
occurring. However, a counter-argument is that a genuine "undo" procedure
should (still) be capable of "undoing" a specific polygon repour command; as
such, any polygons that do get repoured (as a consequence of the user
selecting that option) during a Move command should (also/then/similarly) be
"un-repoured" if the user then "undoes" that Move command.)

For all that, in the event that the user does not select the option of
repouring polygons during a Move command, and once again does not select
that when subsequently undoing that Move command, then the polygons should
be restored *exactly* to where they were previously. The polygons have
merely been *moved* (and perhaps mirrored); they have *not* *also* been
*repoured*. As such, it is much, much, easier to *just* "unmove" a polygon
than it is to "un-repour" it (as well).

As far as I am concerned, the ideal outcome is for SP7 to support
"un-repouring" of polygons during "undo" procedures. That said, I would
place greater value on non-repoured polygons being restored to their former
locations by "undo" procedures, as I appreciate that "un-repouring" polygons
would not necessarily be straight forward to implement.

As far as usage of the L key is concerned, it is now known that there are
problems (and of a distinct nature) associated with its usage. Again, the
ideal would be to "fix" the L key. However, there are many associated
issues: would it perform a "deep" inversion, a "standard" inversion, or
otherwise? Would it invert around a horizontal axis or a vertical axis?
(Maybe the L key would invert around a horizontal axis, while the K key gets
to be assigned to inverting around a vertical axis; that would have
similarities to the X key mirroring about a vertical axis, while the Y key
mirrors about a horizontal axis.) Such issues are of themselves worthy of
further discussion. For the time being though, it is quite clear that the L
key should be used with due care.

I could say more, but I have said quite a bit already. Like I said before,
please read carefully if you want to respond to this message.

Regards,
Geoff Harland.
-----------------------------
E-Mail Disclaimer
The Information in this e-mail is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
e-mail by anyone else is unauthorised. If you are not the intended
recipient, any disclosure, copying, distribution or any action taken
or omitted to be taken in reliance on it, is prohibited and may be
unlawful. Any opinions or advice contained in this e-mail are
confidential and not for public display.



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
*
* To join or leave this list visit:
* http://www.techservinc.com/protelusers/subscrib.html
*                      - or email -
* mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum
*
* Contact the list manager:
* mailto:[EMAIL PROTECTED]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to