I've looked through this newsgroup hoping to find a solution, but wasn't able to make any of the previous answers work for me. I've got an Xref, and am trying to select a block within the Xref. it seems that all that nentselp returns is the farthest nested object clicked (in my case, a line within the block), and a couple references to the xref. How can I step out of the Line to the containing block? the 330 owner of the line object returned nil when i tried to entget it, so I'm officially lost. much thanks for any help. --Jeremiah
Command: (setq test (nentsel)) Select object: (<Entity name: 40752338> (518.35 -6783.97 0.0) ((19.9999 -0.064868 0.0) (0.064868 19.9999 0.0) (0.0 0.0 20.0) (517.86 -6784.42 0.0)) (<Entity name: 40752408> <Entity name: 4060f8e8>)) Command: (entget (car test)) ;;;;THIS IS THE SELECTED ENTITY IN THE BLOCK ((-1 . <Entity name: 40752338>) (0 . "CIRCLE") (330 . <Entity name: 40752328>) (5 . "73C7") (100 . "AcDbEntity") (67 . 0) (8 . "0") (100 . "AcDbCircle") (10 0.0 0.0 0.0) (40 . 0.0323421) (210 0.0 0.0 1.0)) Command: (entget (car (last test))) ;;;;THIS IS THE BLOCK THAT THE CIRCLE IS IN ((-1 . <Entity name: 40752408>) (0 . "INSERT") (330 . <Entity name: 40730c10>) (5 . "73D9") (100 . "AcDbEntity") (67 . 0) (410 . "Model") (8 . "Stone2-ip|STST") (100 . "AcDbBlockReference") (2 . "Stone2-ip|STLT") (10 1.77971e+006 288825.0 0.0) (41 . 20.0) (42 . 20.0) (43 . 20.0) (50 . 6.27994) (70 . 0) (71 . 0) (44 . 0.0) (45 . 0.0) (210 0.0 0.0 1.0)) Command: (entget (cadr (last test)));;;;THIS IS THE XREF THE BLOCK IS IN ((-1 . <Entity name: 4060f8e8>) (0 . "INSERT") (330 . <Entity name: 40613cb8>) (5 . "11BD5") (100 . "AcDbEntity") (67 . 0) (410 . "Model") (8 . "0") (100 . "AcDbBlockReference") (2 . "Stone2-ip") (10 -1.77919e+006 -295610.0 0.0) (41 .. 1.0) (42 . 1.0) (43 . 1.0) (50 . 0.0) (70 . 0) (71 . 0) (44 . 0.0) (45 . 0.0) (210 0.0 0.0 1.0)) HTH,
AutoCad help said,this below Return Values When the selected object is not complex (i.e., not a 3D polyline or block), nentsel returns the same information as entsel. However, if the selected object is a 3D polyline, nentsel returns a list containing the name of the subentity (vertex) and the pick point. This is similar to the list returned by entsel, except that the name of the selected vertex is returned instead of the polyline header. The nentsel function always returns the starting vertex of the selected 3D polyline segment. Picking the third segment of the polyline, for example, returns the third vertex. The Seqend subentity is never returned by nentsel for a 3D polyline. NOTE A lightweight polyline (lwpolyline entity) is defined in the drawing database as a single entity; it does not contain subentities. Selecting an attribute within a block reference returns the name of the attribute and the pick point. When the selected object is a component of a block reference other than an attribute, nentsel returns a list containing four elements. The first element of the list returned from picking an object within a block is the selected entity's name. The second element is a list containing the coordinates of the point used to pick the object. The third element is called the Model to World Transformation Matrix. It is a list consisting of four sublists, each of which contains a set of coordinates. This matrix can be used to transform the entity definition data points from an internal coordinate system called the Model Coordinate System (MCS), to the World Coordinate System (WCS). The insertion point of the block that contains the selected entity defines the origin of the MCS. The orientation of the UCS when the block is created determines the direction of the MCS axes. NOTE nentsel is the only AutoLISP function that uses a matrix of this type; the nentselp function returns a matrix similar to those used by other AutoLISP and ObjectARX functions. The fourth element is a list containing the entity name of the block that contains the selected object. If the selected object is in a nested block (a block within a block), the list additionally contains the entity names of all blocks in which the selected object is nested, starting with the innermost block and continuing outward until the name of the block that was inserted in the drawing is reported. Examples Draw a 3Dpolyline with multiple line segments, then load and run the following function and select different segments of the line. Pick off of the line and then pick the same segments again to see the subentity handle. Try it with a lightweight polyline to see the difference. (defun c:subent () (while (setq Ent (entsel "\nPick an entity: ")) (print (strcat "Entity handle is: " (cdr (assoc 5 (entget (car Ent)))))) ) (while (setq Ent (nentsel "\nPick an entity or subEntity: ")) (print (strcat "Entity or subEntity handle is: " (cdr (assoc 5 (entget (car Ent)))))) ) (prompt "\nDone.") (princ) ) In autocad help,yes I understood,but in application I am still confusing.
oh i see. i got all weired out when i saw the block name, but it's just respecting the xref, with "<xref>|<blockname>". cool, thanks. --Jeremiah
ah, okay, well now i've really dug myself into a pit, let's see if you can get me out of this one! okay, so i've selected a block within an xref. i've used nentselp to get the blocks information. now, the user wants to select a window or polygon, to select similar blocks within the xref. normally, of course, a simple ssget would do the trick. how can i pull this off within the xref? --Jeremiah
Jeremiah, I think you need to tell us what you are trying to do in general sense, rather than focusing on selection methods. I say that because the short answer to your question below is no way. Joe Burke
the short answer to anything is "there is a way".... unless of course you want to be chronically unemployed... i'm trying to label an xref. so i've got this large xref, it has the master design. now they xref that to 7 or 8 different dwgs, so that the draftsmen can label it. so the custom tool allows the user to click on an object, nentselp provides me the block reference within the xref they clicked on, it looks up in the database what information to put into the label, and all is hunky-dory. but need to label by a group! so the user draws a window, and need to grab all matching blocks within that area. no way you say?! how about this, take the window coordinates the user clicked, now step through the objects in the xref, translate their insertion point, and if their insertion point is within that window, then add them to the selection set. must be why i make the big bucks.... --Jeremiah
I'm sorry Ade, but I'm not understanding your question. I opened the Excel file and it is showing the (entget) data as I showed in my post, what is it you want to do with this?
Jeremiah, Why ask the question, given you already know how to do it? As if it has any relevance, I'm self-employed. Joe Burke
Joe, I've cut my responses way back on this NG because of posters like this one, who are apparently getting paid to do programming and want someone to write their apps for free. The text of the original post sounded like someone who'd never programmed before or who couldn't even read the help files. The last post by the same poster makes it sound like he's a master lisp programmer. Thanks for your contributions. I enjoy reading them when I get the time. Regards, Doug
Hi Doug, We'll have to try to be more entertaining in the future. We need you around here. I miss John's input. Hardly ever see him here these days. BTW, do you think my initial reaction, it can't be done, was wrong? I played with the xref database object a bit this evening. I haven't paid much attention to it in the past. Now I think it could be done as Jeremiah suggested in his last post. Though it might not be easy, I think I can see solutions for the potential rough spots. Revisiting the "is point inside" thing for one. My other thought regarding Jeremiah's posts. It sounds to me like a lack of work flow management is dictating the parameters of the programming effort. IOW, the users are telling the programmer how it should work. Which usually isn't a good approach, IMO. Regards Joe Burke
Hi Joe, You can access the modelspace of the xrefdatabase of the xref. The xref can be accessed with the item method of the block collection using the name property of the "AcDbBlockReference" You could then iterate the xref's modelspace looking for the objects within the translated window but IMO you would need to use the bounding box of each blockref rather than the insert point of each blockref for a window selection. For my own in-house work (given the delicate balance between programming cost/benefits)it would be much easier to temporarily edit the source drawings (open xref), using standard drawing selection capabilities and then export the results to the host drawing. Either that or use refedit capabilities. During a refedit, selection set capabilities are focused on the xref in question. The only diference is the named object prefixes that refedit adds. Neither an external edit nor refedit would be an acceptable solution for a canned program to be used by others. I agree that someone wanting a solution to a problem should try to avoid limiting the methods to achieve a result. Exception: methods that lead to negative side effects (like leveling Falujia to kill 100 terrorists). Would putting the whole city to sleep be better? Probably. So let's draft 1000 anesthesiologists and send them to Iraq.;-) Your initial response was to Jerimiah's statement: You can't use ssget on an xref without being in refedit so your response was reasonable. And creating an ssget substitute for xrefs would be going far above and beyond the call of duty.
Regardless of whether I am following good design practices, it still makes a fun programming challenge, does it not? Select a window, and have code find all matching blocks within a Xref in that window. I mean, that just sounds fun to even try to do. Anyway, yes, it is totally possible to just skip through the objects in the Xref, grab insertion points of blocks, translate the point back into true WCS, and finally see if the point is inside the selected window. You're right, in that the most challenging part is finding some simple code on checking whether the point is inside of the selected window. I don't know why every example mentioned on this newsgroup needed to strive for some record on the most pages of useless code, but they do. I was finally able to dramatically clean up the INOUT.LSP from autocode.com, which seems to work fine, and I'll accept the possibility that if a block's insertion point is directly on one of the bounding lines of the window selected, it will behave erratically. As for proper design processes... well, nobody tells me what to do, you should have realized that with my snippiness when you told me this wasn't possible. But if you want to take a stab at providing a better solution, then have at: the design is a single very large DWG, which is then Xref'ed into ~10 different drawings so that draftsmen can label and complete the different sheets. The nature of the design is very complicated, and very dense, and also as the design evolves, it necessitates retaining it in a single piece. My first thought, was that I wished AutoCAD allowed multiple users to edit a drawing at the same time, just like any true multi-user database system. But I had to end up agreeing with the way the folks were doing it, that Xref'ing it made the most sense. cheers, --Jeremiah
Hi Doug, What you said was my thought process. In particular with regard to using the bounding box of a block ref, rather than its insertion point. That would more closely mimic what happens at a standard select objects prompt, in terms of selecting a block. I guess Jeremiah is willing to throw caution to wind, in favor of simplistic solutions. That would not be my approach. Seems to me this is one those programming exercises where the effort involved would be pointless, if the program fails for some known reason. Obviously that's true for any program, but more so as the level of complexity increases. Joe Burke
