The original question was basically why can't sheet entries be moved in groups.
On 12:31 AM 27/06/2003, Pat Nystrom said:
Ian Wilson wrote:
IW> To help the developers along maybe we should discuss how we would like the
IW> system to behave when moving groups of sheet entries (within a sheet
IW> symbol, both sides, top and bottom etc) and when sheet entries are selected
IW> on multiple sheet symbols and when sheet entries are part of some wild
IW> mixed-up ad-hoc selection.
OK, my preferences would be:
1. Detach the sheet entries from the sheet symbol. When creating a sheet symbol,
have the user select a sheet symbol (this allows for (3), below), but then let
the user dump it anywhere he chooses, on or off the symbol.
I think you mean "When creating a sheet entry, have the user select a ..."
If I select sheet
entries on multiple sheet symbols by accident, and move some of them off of
their sheet symbols, that's OK - this frequently happens in Protel when a
selection is too broad, and is the perfect time to use Undo.]
A warning maybe - "This move will force sheet entries off owning sheet" or similar.
If I move a sheet entry from one sheet symbol to another the system should presumably do what is needed to make the new sheet symbol the owner of the moved sheet entry. In other words, moving a sheet entry (or more than one) from one sheet symbol to another should be allowed. Again, the above warning or similar may be useful.
2. Make the compiler issue a message for sheet entries not on sheet symbol edges,
such as it does now for many objects which aren't in the 'right' place (off-grid,
net label not touching wire, etc.)
Should sheet entries be restricted to the edge of sheet symbols? I guess there is no big push for this restriction to be relaxed.
3. When placing a sheet entry, after the user has selected a sheet symbol, when
TAB is hit and the parameter dialog shows, the text for the sheet entry should
be a drop-down list containing port names from the referenced sheet which aren't
yet represented by sheet entries in the selected sheet symbol.
I think a process that would auto-create the sheet entries from the underlying sheet (and ports on the sheet from the overlying (?) sheet symbol) may be enough. In either case it should be possible to create a sheet entry for a non-existing port. So your drop list, if implemented, should be a combo box rather than a simple drop list to allow the user to manually type in a new port name.
4. Add a 'Remove un-referenced sheet entries' process.
5. Add an "Add update from sheet" process that would add new sheet entries and remove unused sheet entries from the sheet symbol based on the underlying sheet.
As discussed previously there are some complexities that possibly could be managed by a process much like the Parameter Manager (Sheet Entry/Port Manager or Hierarchy Manager maybe) that would allow detailed control of re-synchronising sheet entries to underlying ports. Things like how should sheet entry/port direction or I/O type mismatches be resolved.
Do you see any difficulties or conflicts in these suggestions?
Why would Altium do this in DXP when users have coped with this behavior
See PEDA for my comments.
One big reason is that to use the multi-channel capability which has
been added in DXP, the designer has no choice but to use the full hierarchical
schematic model. The main reason I have seldom used this model in the past was
the sheet entry editing made maintenance difficult. Now I have no choice; if I
want multi channel capabilities, I have to use this model and put up these
I agree that there is a bigger need these days for this issue to be looked at. P99SE was a pain in editing sheet entries and managing the hierarchy.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To leave this list visit: * http://www.techservinc.com/protelusers/leave.html * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * Forum Guidelines Rules: * http://www.techservinc.com/protelusers/forumrules.html * * Browse or Search previous postings: * http://www.mail-archive.com/[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *