boy, that's a pretty good analysis Geoff, thanks
Dennis Saputelli
Geoff Harland wrote:
> 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.
--
___________________________________________________________________________
www.integratedcontrolsinc.com Integrated Controls, Inc.
tel: 415-647-0480 2851 21st Street
fax: 415-647-3003 San Francisco, CA 94110
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
