The component list shown in the listbox on the left side of Schematic is often unwieldy, because of DipTrace's binding of circuits to patterns as part of the definition of components. This premature binding is doubtless very deep in the architecture of DipTrace, it has bobbed up in these forums from time to time, and I don't mean to beat that dead horse here.

Here is a feature that should be easy to implement, and that might nicely decouple schematic design from PCB design, without affecting the deep architecture.

• In the description of each component, add bits NeedsValue and Representative.
• The idea of the NeedsValue bit is that a component may be unspecified without a value (e.g., a resistor). The NeedsValue setting in the library would be copied to the initial NeedsValue setting of a placed component, setting a value would reset the placed component's NeedsValue to false, and a menu option could cause all of the placed components with NeedsValue=true to be highlighted.
• Similarly, a menu item could cause highlighting of placed components that had no associated patterns.
• Finally, the idea of the Representative bit is that of many components with the same circuit but different patterns and values, only one might be identified in their library as Representative, and then a menu item could choose to have only the Representative components be shown in the listbox.

With this infrastructure, I might (for example) structure a Discrete library to have just a few Representative components, all patternless and without values (one 2-wire resistor, one 4-wire resistor, one nonpolarized capacitor, one polarized capacitor, and so on). Then, I would

• Arrange through the menu that only Representative components were listed;
• draw a schematic, choosing components from the temporarily abbreviated list;
• use the menu to highlight components that needed values;
• specify values that I hadn't put in earlier;
• use the menu to identify components whose patterns had not been specified;
• use the menu to open up the component listbox to show non-Representative components;
• replace patternless components with pattern-bearing ones; and finally
• move on the PCB design.

Sooo, basically you are asking for components with different patterns...
Its been asked before, its the proper way, but devs said it requires overhauling the whole patterns/components thing, so no, at least in foreseeable future.

No, I guess I didn't explain my proposal very well. It entails only the most trivial changes to the system, changes that would (making some assumptions about the code and DB structure) take less than a week of programmer time. In an ugly way, most of it can be done with no new programming at all, and I am doing something like it with my existing libraries, but support from the system would make it smoother.

For example, suppose an existing library were devoted entirely to 2-lead resistors and polarized capacitors. It would include scores of different components (much more than a column's worth), with SMD resistors in all of the different form factors, SMD polarized capacitors in all of the different form factors & technologies, TH resistors in different sizes laid flat, and TH polarized capacitors in all of the different form factors, technologies, and configurations. I could add two new components to that library, give them funny names (say, "AAA_resistor" & "AAA_PolarCap") so that they would sort first, and then use them in designing schematics. They would have the same schematic appearances as any other resistors & polarized caps, but no attached patterns.

These new components

• are easy to find in the library when designing a schematic
• are adequately specific (except for having no values) when one needs only a schematic
• are fairly easy to find (by their funny names) in the parts list when it comes time to replace them with pattern-bearing components on the way to designing a PCB

The system support that I proposed

• would make it unnecessary to give the new, patternless components distinguished names [they would each have a NeedsPattern (earlier called Representative) bit turned on (one could even do without such a bit, and just consider any component without a pattern to have NeedsPattern = true, but the design seems cleaner with a special bit, and it's nice to be able to have components (notes, say) that never need patterns, but still don't get flagged)],
• would let the system run in a mode in which distracting pattern-related detail, unrelated to the schematic-creating task at hand, was suppressed [the menu option would be the trivially-implemented "in the component list in the left-hand column, limit the display to components with NeedsPattern = true"],
• would let any pattern-needing components be quickly identified for replacement at PCB-design time [the menu option would be the trivially-implemented "on the displayed schematic, select all the components with NeedsPattern = true]"

Analogously, my proposal also included a per-component NeedsValue bit, so that one could sketch a schematic and then painlessly find the components that, with or without patterns, needed values. Some components are incomplete without values, but some aren't, so the argument for the NeedsValue bit is like that for NeedsPattern. The supporting code would be almost the same; the corresponding menu item would be "on the displayed schematic, select all the components with no value but NeedsValue = true."

Fenichel.. Dude.. you should check out Cadence Allegro or PCB Editor, you could do your thing in this software... it has scripting capability..

Thanks for the reference. I had not heard of the Cadence system before; from a hasty Web search, it seems to be limited to PCB design, without schematic-capture tools.

In any event, I'm pretty well satisfied with DipTrace. Its features are logically organized, and its conventions -- in dramatic contrast to those of Eagle, for example -- are consistent with general Windows conventions. That's important for someone for whom electronics is a much-less-than-full-time activity. DipTrace's premature binding of components to patterns (probably reflecting a flat-file implementation where a relational DB was called for) is an annoyance, but only a modest one, as these things go.


As I understand from developer comments here, scripting is coming for DipTrace, albeit possibly not right away.

Cadence is actually a high-end professional system and can do much more than just schematic and layout. The price tag is also high end, somewhere around 100x of what Diptrace sells for, so not really targeting private users...

As for Windows conventions, Diptrace has its own quirks, too - right-clicks to open properties where one (or at least I would expect a double-click, and quite a few default behaviors are the opposite of what one would expect. But it is excellent value at a very reasonable cost nevertheless, and I like that the developers really listen to input from users.