Kuba,
>> Just to be clear: To select a wire and attempt to parameterize its
>> position as a whole is probably an undefined procedure and I have no
>> idea what the consequences might be. If you want to parameterize the
>> position of a wire, edit it and parameterize the position of a point.
> How do you parametrize the position of a point? I presume it could only
> be cleanly done with keyboard shortcuts -- after all, when you edit a polygon
> mouse motion immediately changes the position of the current point,
> so just moving the mouse to the menu or toolbar will disturb it.
The 'p' key binding while editing a point on a polygon is supposed to
parameterize both X and Y values simultaneously. You *can* pull the
point offscreen and parameterize from the toolbar. This will of
course stick the point in the "wrong" place, but then again, the point
position is parameterized, so there is no "wrong" place, just a position
defined differently for each instance. You can go reposition the
point in the library object instance (by descending into the object
from the library page). I'm not suggesting that this is an efficient
system, and there really should be a pop-up menu of options for what
you can do while in the middle of editing a polygon or other element.
Note that while playing around with this method just now, I found two
separate bugs, one of them a nuisance (changes the cycle after
parameterizing the point, without warping the cursor to that point),
and the other fatal (seems to be in version 3.7 only). There is also
a handful of annoying "features" related to the ability to modify the
library master object (and therefore all instances) at the same time
you're trying to change the parameterized point of a single instance
(for example, you parameterize the X-position only of a point; then
if you move that point in both X and Y, the change in X applies only
to that instance, but the change in Y applies to every instance). As
I mentioned before, I need to implement a "lock-out" flag that one can
set to prevent editing anything other than the parameterized parts of
an element. This seems easier said than done, though.
> So then, since your drawing routines are destructive due to parameter
> substitution, whatever is done in the drag() function is promptly
> undone as soon as the area gets repainted. That's probably what you
> meant by "extra" refreshes.
Yes. I don't have a working version of your code, so I'm sometimes
guessing at what your doing (fortunately your descriptions are thorough).
> Is it OK to call pwriteback(areawin->topinstance) willy-nilly? Perhaps
> simply putting it at the end of each and every event handler is a
> temporary workaround?
I can't think of any reason this shouldn't work, but then again, that's
what I always say just before I break my program. I'd call it "brute
force" rather than "willy-nilly". I expect that would be a more
permanent rather than temporary solution. The procedure could be
optimized by writing back only the parameters for the element invoking
the event handler. There is no such routine at present, and the
pwriteback() routine just goes through every single part of an object
instance. Normally there are very few parameterized elements, so the
brute-force search is quick, and probably not noticeable even when
called from a fairly compute-intensive event like drag().
---Tim
+--------------------------------+-------------------------------------+
| Dr. R. Timothy Edwards (Tim) | email: [email protected] |
| Open Circuit Design, Inc. | web: http://opencircuitdesign.com |
| 22815 Timber Creek Lane | phone: (301) 528-5030 |
| Clarksburg, MD 20871-4001 | cell: (240) 401-0616 |
+--------------------------------+-------------------------------------+
_______________________________________________
Xcircuit-dev mailing list
[email protected]
http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev
