<snip>
> 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?)
>
> Geoff Harland.
Having thought about this a bit more since the time I posted the above
message, I consider that there would be times when users *would* prefer any
polygon(s) being "unmoved" to be repoured at the same time (*if*
"unrepouring" of polygons being "unmoved" was *not* supported). (A polygon
could be on a copper layer, and assigned to a particular net. If it was not
repoured during the "unmove" command, DRC errors would typically be
produced, as a consequence of primitive items within the polygon coming in
contact with items assigned to *other* nets.)
As such, I now think that the user *should* be prompted as to whether the
polygon(s) should be repoured during an "unmove" command. (But this prompt
still should *not* occur if the polygon(s) had *not* been repoured during
the previous move command.) And there is probably something to be said for
the query box informing the user that "unrepour" is not supported, and as
such, the user is currently being asked whether repour should occur during
the (current) "unmove" command.
Although I have not changed my mind about the perceived difficulty and data
requirements of supporting "unrepour" of polygons, I have since come to the
view that it is not out of the question that it could in fact be
implemented. At present, it is possible to select everything in a Pcb file,
and then invoke the command of deleting all selected items. This combination
of commands will remove everything from the Pcb file. If the Undo command is
then invoked, everything which had previously been removed from the Pcb file
will now be restored to this. The associated data requirements for a complex
Pcb are not trivial, but as this is supported, it is not out of the question
to further support "unrepouring" of polygons.
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]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
