Ohnoto Posted June 17, 2011 Share Posted June 17, 2011 I'm having an issue lately where when our template is copied into another drawing, wipeouts inside of blocks are being brought to the front of the objects. The wipeouts are embedded inside the block. As part of some code we have, I wrote: (if (setq ss1 (ssget "_X" (list (cons 0 "WIPEOUT")))) (progn (command ".draworder" ss1 "" "back") )) Which works just fine, except for that it doesn't work for wipeouts inside of blocks, just those on the outside. How would I get this to work for wipeouts inside the block? Thanks Quote Link to comment Share on other sites More sharing options...
Lee Mac Posted June 17, 2011 Share Posted June 17, 2011 (edited) Give this a try: (defun c:test ( / acblk acdoc acsel name obj processed ) ;; Lee Mac 17.06.11 (setq acdoc (vla-get-activedocument (vlax-get-acad-object)) acblk (vla-get-blocks acdoc) ) (if (ssget '((0 . "INSERT"))) (progn (vlax-for block (setq acsel (vla-get-activeselectionset acdoc)) (if (not (member (setq name (vla-get-name block)) processed)) ( (lambda ( / lst ) (vlax-for obj (vla-item acblk name) (if (eq "AcDbWipeout" (vla-get-objectname obj)) (setq lst (cons obj lst)) ) ) (if lst (vla-movetobottom (LM:SortentsTable (vla-item acblk name)) (vlax-make-variant (vlax-safearray-fill (vlax-make-safearray vlax-vbobject (cons 0 (1- (length lst)))) lst ) ) ) ) (setq processed (cons name processed)) ) ) ) ) (vla-delete acsel) (vla-regen acdoc acallviewports) ) ) (princ) ) (defun LM:SortentsTable ( space / dict result ) (cond ( (not (vl-catch-all-error-p (setq result (vl-catch-all-apply 'vla-item (list (setq dict (vla-GetExtensionDictionary space)) "ACAD_SORTENTS") ) ) ) ) result ) ( (vla-AddObject dict "ACAD_SORTENTS" "AcDbSortentsTable") ) ) ) (vl-load-com) (princ) Edited June 20, 2011 by Lee Mac Error in code Quote Link to comment Share on other sites More sharing options...
irneb Posted June 17, 2011 Share Posted June 17, 2011 I've also done something, using lee's code: http://forums.augi.com/showthread.php?t=130229 But maybe Lee's version (using his own code) is more succinct:wink: Quote Link to comment Share on other sites More sharing options...
Organic Posted June 18, 2011 Share Posted June 18, 2011 I wouldn't use wipeouts at all. I prefer to use a solid hatch instead as a mask if it is needed. Quote Link to comment Share on other sites More sharing options...
irneb Posted June 18, 2011 Share Posted June 18, 2011 Yes, they have less hassles than wipeouts (especially when plotting to PDF). A whipeout is nothing more than a clipped blank image without transparency, so you get all the hiccups which images come with. Hatches on the other hand also have some glitches with PDF (e.g. an acad hatch actually consist of many 2dSolid triangles, which in most instances do show up in PDFs). And to get the hatch to work correctly you need to have it plotted as pure white - usually this then displays wierd in acad (if you have a black background). Yet still you need to use draworder to have the hatch work correctly. Not sure if the OP would have the same issue when copying a block between DWGs though. I have seen this exact problem happen with wipeouts, but only on some blocks ... after someone's refedited them. Though I've never seen it with hatches. Quote Link to comment Share on other sites More sharing options...
BlackBox Posted June 18, 2011 Share Posted June 18, 2011 I wouldn't use wipeouts at all. I prefer to use a solid hatch instead as a mask if it is needed. 1+ I use a solid hatch, color 255,255,255. Quote Link to comment Share on other sites More sharing options...
BlackBox Posted June 18, 2011 Share Posted June 18, 2011 And to get the hatch to work correctly you need to have it plotted as pure white - usually this then displays wierd in acad (if you have a black background). I worked with WinXP 32-Bit, and am now on Win7 64-Bit, and I have never experienced this problem. Quote Link to comment Share on other sites More sharing options...
irneb Posted June 18, 2011 Share Posted June 18, 2011 What I mean is it displays White - as if it's a filled area (uhhmmm which it is!) With a wipeout it's always the same colour as your background, so it just "looks" like a blank, as you actually wanted it. If you don't mind this, then you don't have a problem when using hatches - unfortunately for me a lot of our drawings also include grey solid hatching: which starts to appear much the same as these white hatches, and thus makes for confusion on screen. So I'd say it's dependent on your situation. If you change your background to white, then of course the white hatch would look correct on the screen as well. But then you'll have to get used to a white background and not using colours like yellow (which would be hard to see). For me, as long as you're on the lookout for wipeout's problems - they're not insurmountable. And with some lisp code like this, they're "automatically" fixable. The hatch idea causes human error on the screen as it becomes easy to confuse a white hatch with a 254 colour hatch - which you then only pick up after a plot. This type of "error" is not automatically fixable though, since a program can't "understand" that this portion needs a grey hatch, but that one should actually look blank. If you don't use hatches which could be easily confused with these white "blankouts", then obviously you don't have this problem. Quote Link to comment Share on other sites More sharing options...
Ohnoto Posted June 20, 2011 Author Share Posted June 20, 2011 (edited) To respond to all the reply's... I will say that I never thought of using a hatching background. We've been using wipeouts in all of our blocks for a couple years now, but lately, within the last two weeks the wipeouts started moving to the front of objects within blocks. Up until now we hadn't had any issues with them, and everything looks correct in our template. @Lee, Thanks, it works great. My only request is that I would like it to select all of the blocks automatically. I tried various modifications to the ssget with "_X" that I know and all of them gave me an error. Edit: I'm also getting this error when selecting a block that doesn't have a wipeout in it. To counter this, I have added a list of the blocks that do have a wipeout in them, and using the following code to reference them. (ssget (list '(0 . "INSERT") (66 . 1) (cons 2 (apply 'strcat (cons "`*U*" (mapcar '(lambda ( s ) (strcat "," s)) wipeblocks))) ) ) It still works in that sends the wipeouts to the back, but still does it for all of the blocks, not just the ones on the list. Edited June 20, 2011 by Ohnoto Quote Link to comment Share on other sites More sharing options...
Lee Mac Posted June 20, 2011 Share Posted June 20, 2011 Thanks, it works great. My only request is that I would like it to select all of the blocks automatically. I tried various modifications to the ssget with "_X" that I know and all of them gave me an error. Excellent, glad it works. Note that since the code modifies the block definitions (not the block references), the selection using ssget is only required so that the user can determine which block definitions to process. The program only processes the block definition once for each different block reference selected, and this change will be reflected throughout all references. So if there are multiple references of the same definition selected, only the first reference will be used to determine the definition to be processed and the rest will be ignored. In this way, if you wish to process all blocks, the ssget selection may be removed completely and the code can just iterate through the block collection: ([color=BLUE]defun[/color] c:test ( [color=BLUE]/[/color] acdoc ) [color=GREEN];; Lee Mac 20.06.11[/color] ([color=BLUE]setq[/color] acdoc ([color=BLUE]vla-get-activedocument[/color] ([color=BLUE]vlax-get-acad-object[/color]))) ([color=BLUE]vlax-for[/color] block ([color=BLUE]vla-get-blocks[/color] acdoc) ([color=BLUE]if[/color] ([color=BLUE]and[/color] ([color=BLUE]eq[/color] [color=BLUE]:vlax-false[/color] ([color=BLUE]vla-get-islayout[/color] block)) ([color=BLUE]eq[/color] [color=BLUE]:vlax-false[/color] ([color=BLUE]vla-get-isxref[/color] block)) ) ( ([color=BLUE]lambda[/color] ( [color=BLUE]/[/color] lst ) ([color=BLUE]vlax-for[/color] obj block ([color=BLUE]if[/color] ([color=BLUE]eq[/color] [color=MAROON]"AcDbWipeout"[/color] ([color=BLUE]vla-get-objectname[/color] obj)) ([color=BLUE]setq[/color] lst ([color=BLUE]cons[/color] obj lst)) ) ) ([color=BLUE]if[/color] lst ([color=BLUE]vla-movetobottom[/color] (LM:SortentsTable block) ([color=BLUE]vlax-make-variant[/color] ([color=BLUE]vlax-safearray-fill[/color] ([color=BLUE]vlax-make-safearray[/color] [color=BLUE]vlax-vbobject[/color] ([color=BLUE]cons[/color] 0 ([color=BLUE]1-[/color] ([color=BLUE]length[/color] lst)))) lst ) ) ) ) ) ) ) ) ([color=BLUE]vla-regen[/color] acdoc [color=BLUE]acallviewports[/color]) ([color=BLUE]princ[/color]) ) ([color=BLUE]defun[/color] LM:SortentsTable ( space [color=BLUE]/[/color] dict result ) ([color=BLUE]cond[/color] ( ([color=BLUE]not[/color] ([color=BLUE]vl-catch-all-error-p[/color] ([color=BLUE]setq[/color] result ([color=BLUE]vl-catch-all-apply[/color] '[color=BLUE]vla-item[/color] ([color=BLUE]list[/color] ([color=BLUE]setq[/color] dict ([color=BLUE]vla-GetExtensionDictionary[/color] space)) [color=MAROON]"ACAD_SORTENTS"[/color]) ) ) ) ) result ) ( ([color=BLUE]vla-AddObject[/color] dict [color=MAROON]"ACAD_SORTENTS"[/color] [color=MAROON]"AcDbSortentsTable"[/color]) ) ) ) ([color=BLUE]vl-load-com[/color]) ([color=BLUE]princ[/color]) Quote Link to comment Share on other sites More sharing options...
irneb Posted June 20, 2011 Share Posted June 20, 2011 To respond to all the reply's... I will say that I never thought of using a hatching background. We've been using wipeouts in all of our blocks for a couple years now, but lately, within the last two weeks the wipeouts started moving to the front of objects within blocks. Up until now we hadn't had any issues with them, and everything looks correct in our template.I've found this happening about 50% of the time if someone's RefEdited the block or the XRef in which it resides. It seems to be more prone to happen if the block is also dynamic. Quote Link to comment Share on other sites More sharing options...
Lee Mac Posted June 20, 2011 Share Posted June 20, 2011 Edit: I'm also getting this error when selecting a block that doesn't have a wipeout in it. To counter this, I have added a list of the blocks that do have a wipeout in them, and using the following code to reference them. Yes, I realised that mistake too when writing the code to process all blocks, I had forgotten to check whether the list of wipeout objects was non-nil before creating the safearray. I have since updated my earlier code Quote Link to comment Share on other sites More sharing options...
Ohnoto Posted June 20, 2011 Author Share Posted June 20, 2011 Perfecto! Thanks Lee, just ignore that edit I posted a bit before. Greatly appreciated. Quote Link to comment Share on other sites More sharing options...
Lee Mac Posted June 20, 2011 Share Posted June 20, 2011 No worries Quote Link to comment Share on other sites More sharing options...
Moonjm Posted December 12, 2022 Share Posted December 12, 2022 Good afternoon, I have a problem, related to the wipeout. In a dwg I have many blocks and now at the last minute, I needed to put a wipeout in almost all of them, and the fastest way I had was to make a block with a wipeout (only the wipeout inside) and with a script I made the insert inside of each of those almost 80 blocks, and it went well... but now I had to update the blocks, with blocks from the outside to the inside of the dwg and the wipeout was in front when it should be at the bottom. Could you help me in all the blocks, look for a block inside each one, the name of said block is (wipe_ind) and in all of them send the said block down. Is it possible to adapt a routine that you shared but with the filter only for wipeout, in order to do what I need? Thanks Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.