Hello Philip,
> I tried sending this to the list, but it seems to have not gone
> through. I'm sending it again and also CC'ing you directly
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> I just compiled version 3.7 to upgrade from my 3.6.39.
>
> The change in libraries caused me a bit of grief. I think I
> have worked through most of the changes (I can get to my
> library objects!) - but I'm still not sure how to put a newly
> created (m) object into an existing library. Clues would be
> appreciated, but I imagine I'll figure it out. *smiles*
I switched from thinking about libraries as equivalent to files,
to thinking about libraries as groups of associated objects
that may or may not come from the same file. So now objects
are grouped by technology, which is a prefix given to the
object name, like
analog::capacitor
This allows one to create other files with more objects that
belong to the "analog::" grouping, and so forth. In the
startup file, library pages are made like:
library make Generic
followed by loading zero or more files onto that page:
library 1 load generic.lps
library 1 load analog.lps
...
Now if you want to make a new object and have it saved with,
say, the generic.lps file (assuming you have write permission
to it), then when you do "m" to make the new object, and get
a pop-up window asking for a name, then you can give it the
name
generic::myobject
If you don't supply the prefix, you'll get a blank prefix,
which (I could be wrong about this) can't be saved as a
library file but will be saved along with the drawing.
On a library page, you can edit the name of each object and
change the prefix, which will move it from one file to another
(if you do this, both files should be marked as changed, and
you should get a request to save both of them before exiting
the program). The library page will hide the prefix for the
sake of a cleaner display, but will show the prefix if you
edit the name.
> However, there are other problems.
>
> In 3.6.39, when moving either one object or a selected group
> of objects, the objects became un-selected as soon as they
> were set down. With 3.7.27 a single objects still works this
> way - but a selected group stays selected after moving. Is
> this a feature? If so, is there a way to get the former
> behavior back?
It's definitely a feature. I had a very poorly-defined set of
responses to different actions which sometimes left things
selected and sometimes didn't. That sloppiness began to play
havoc with the "undo" function, particularly when grouping
actions together into a single "undo" record. Since the area
selection, for example, is a single action in and of itself,
it works better to treat it as a monolithic action with its own
"undo" record, then treat the move as another monolithic action.
Well, I'm trying here to justify a largely arbitrary change.
I can tell you that I have never quite gotten used to the new
method myself, which is probably as good an indication as any
that it should be put back the way it was. . .
> Finally, I found a real bug - probably. Anytime I try to
> insert a point on an existing line (using "i") xcircuit
> crashes. The terminal I ran it from simply reports
>
> Segmentation fault
>
> The keys "d" and "e" work normally. "p" doesn't cause a crash,
> but I don't normally use it so I don't know if it is behaving or
> not.
Yes, I can duplicate the crash condition in both versions 3.7 and
3.8, and I will look into it.
---Tim
+--------------------------------+-------------------------------------+
| Dr. R. Timothy Edwards (Tim) | email: [email protected] |
| MultiGiG, Inc. | web: http://www.multigig.com |
| 2645 Zanker Road, Suite 101 | phone: (408) 514-1375 |
| San Jose, CA 95134 | cell: (240) 401-0616 |
+--------------------------------+-------------------------------------+
_______________________________________________
Xcircuit-dev mailing list
[email protected]
http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev
