basically you are asking for components with different patterns...
It's been asked before, it's 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