> > I have had this problem in 98, 99, 99SE and I am using 99SE SP5 right
> > now...
> > (because Service pack 6 has some unacceptable bugs).
> >
> > Problem: Polygon Fills - Somehow... a change happens in the design file
> > where the old regeneration for the polygon fill gets visibly stuck in
the
> > file somehow and cannot be deleted or manipulated in any way shape or
> > form.
> > In other words... I cant get rid of the old polygon fill.
> >
> > Regeneration of the existing polygon fill, or deleting the polygon fill
> > does
> > not get rid of the ghost. Copying the entire design by turning on all
the
> > layers and selecting all, and crtl-C copying to clipboard and pasting
> > special (with same nets and duplicating the designators ) results in a
> > copy
> > of the ghost in the new file... still can't get rid of it...
> >
> > Does anyone know how to get rid of this bug?
> >
> > Bill Brooks
>
> Something similar happened too me a year or so ago. Maybe it'll give you a
> hint?
> It appeared to be caused by repouring a polygon unintentionally on a
> different layer to that which it was assigned.
> The result was a polygon which the viewer thought was on one layer but you
> actually had to select it by another layer.
> It had a lot more side effects than this but again it may give you another
> angle of attack?
>
> Shane Edwards
This rings a bell. If you move one or more polygons, you will be asked if
you want these repoured. Regardless of which option you select, the
polygon(s) will be moved as required; the difference between these options
is whether it/they are also repoured at the same time or not.
BIG gotcha though! (Warning, Will Robinson!) If you then UNDO this move of
the polygon(s), you will *again* be asked if you want this/these repoured.
*If* you say "No" at that time, the boundary of each polygon being "unmoved"
will be restored to its previous location. *However*, the primitive objects
that make up each such polygon (arcs, fills, and tracks) are *not* restored
to their previous locations; they remain where they currently are.
As such, you can have a situation where a polygon's *boundaries* are in one
location, while its *contents* (arcs, fills, and tracks) are in *another*
location. If you double-click in the location where its *contents* are,
Protel won't know what you are on about, as you have to double-click in a
location within its *boundaries*.
A bug? I think so. This aspect was one reason (but not the only one) why Ian
Wilson and I decided not to support Undo for the (Pcb) Inverting Server that
we are currently working on.
I have said this before, but this thread warrants my repeating it. I believe
that when one or more polygons have been moved, and that move command is
then undone, Protel *should* have (also) recorded which option the user
previously selected, as far as repouring that/those polygon(s) was
concerned. If the user did *not* select repour, the polygon(s) should be
restored to its/their previous location(s) (boundaries and contents), with
no re-calculation of the associated contents. And when the user *did* select
repour, each polygon should be "unrepoured". And regardless of which
(repour) option was selected previously, Protel should *not* be asking the
user *again*, during the Undo command, as to whether the polygon(s) should
be repoured (during the Undo feature), as it should have recorded which
option was selected previously (when the polygon(s) were first being moved).
However, I appreciate that supporting "unrepour" of polygons would be
something of a big ask, because of the amount of data that could have to be
stored in some cases. That said, non-repoured polygons could still be
restored without too much bother, while polygons which had been repoured
could be handled (with less pain) by the user being prompted as to whether
(the moved) polygons be "unmoved" without repouring, or "unmoved" with
repouring. As such, polygons which had been repoured previously would not be
"unrepoured" during the Undo command (with either of those options), but at
least the suggested implementation would still be a very welcome improvement
upon the current buggy situation.
(Note that the user would *not* be prompted for a repour of the polygon(s)
during the Undo command if the polygon(s) had *not* been repoured when
it/they were first moved; such a prompt would occur *only* if this/these
polygon(s) *had* been repoured previously. Then again, if "unrepour" was not
supported, it could be argued that repouring the polygon(s) *again* during
the Undo command would/could typically make this/these even less similar to
the polygon(s) prior to the initial move command. As such, perhaps polygons
should *always* be "unmoved", but *otherwise* unchanged, during the Undo
command. And if that was the case, then the user would/should *never* be
prompted as to whether the polygon(s) should be repoured during the Undo
command. What do others think?)
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 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]
*
* Browse or Search previous postings:
* http://www.mail-archive.com/[email protected]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
