How to get points from pathSeg ?

Hi

When working with objects in a selected set, the order of the objects is not always the same. This is what you have found out. So we need to look at this from a different perspective. Before that I need to cover a little bit about the objects we are working with here as it is important we are using the same terminology. This maybe redundent or trival to experienced developers but it does not hurt to establish a common base line.

1) Path is a database shape object. This is created by VLS' Create Shape command. It is described by a list of points, width and end point style.

2) PathSeg is a database shape object. This is created by VLS' Create Wire command (or router command for creating connections). The Create Wire command gives user the impression a 'path' is created but it is not. The implementation is actually presented by a series of two pointed pathSeg figure objects.

3) Route is a database object but it is not a shape (it is connFig object). It has a bounding box but not the points describing the its contour. Route can be viewed as a container for the pathSeg objects used to form the 'route' from point A to point B.

 Now back to your questions...

Q1) You can't rely on the selected set information when dealing with pathSeg for the reason you have mentioned. You need to always use the route~>objects to get all the pathSeg objects and you will always get them in the exact same order, ie. from point A to point B regardless where the selection is made. 

You can get all the routes from a cellview by accessing the routes attribute on a cellview, e.g. geGetEditCellView()~>routes. 

Q2)  I have already answered earlier that to work with pathSeg/route, you can not rely on the selection set only. Especially css() which always only return the first element of the selected set. If your command is expected to only work with the selected set, then you can maintain a list of 'processed routes',  and while your code process each shape from the selected set and when the shape is a pathSeg, you check is the route of that pathSeg already in the list or not. If yes, skip over the shape; if not, process the route and get its pathSegs from route~>objects.

Q3) I think this is covered by Q1 and Q2 above.

Cheers,

Li 

Hi

When working with objects in a selected set, the order of the objects is not always the same. This is what you have found out. So we need to look at this from a different perspective. Before that I need to cover a little bit about the objects we are working with here as it is important we are using the same terminology. This maybe redundent or trival to experienced developers but it does not hurt to establish a common base line.

1) Path is a database shape object. This is created by VLS' Create Shape command. It is described by a list of points, width and end point style.

2) PathSeg is a database shape object. This is created by VLS' Create Wire command (or router command for creating connections). The Create Wire command gives user the impression a 'path' is created but it is not. The implementation is actually presented by a series of two pointed pathSeg figure objects.

3) Route is a database object but it is not a shape (it is connFig object). It has a bounding box but not the points describing the its contour. Route can be viewed as a container for the pathSeg objects used to form the 'route' from point A to point B.

 Now back to your questions...

Q1) You can't rely on the selected set information when dealing with pathSeg for the reason you have mentioned. You need to always use the route~>objects to get all the pathSeg objects and you will always get them in the exact same order, ie. from point A to point B regardless where the selection is made. 

You can get all the routes from a cellview by accessing the routes attribute on a cellview, e.g. geGetEditCellView()~>routes. 

Q2)  I have already answered earlier that to work with pathSeg/route, you can not rely on the selection set only. Especially css() which always only return the first element of the selected set. If your command is expected to only work with the selected set, then you can maintain a list of 'processed routes',  and while your code process each shape from the selected set and when the shape is a pathSeg, you check is the route of that pathSeg already in the list or not. If yes, skip over the shape; if not, process the route and get its pathSegs from route~>objects.

Q3) I think this is covered by Q1 and Q2 above.

Cheers,

Li